Add declare feature to syzlang for declaring C/C++ code inline #2274
Conversation
|
Thanks for your pull request. It looks like this may be your first contribution to a Google open source project (if not, look below for help). Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA). 📝 Please visit https://cla.developers.google.com/ to sign. Once you've signed (or fixed any issues), please reply here with What to do if you already signed the CLAIndividual signers
Corporate signers
ℹ️ Googlers: Go here for more info. |
|
Hi Kevin, Interesting. Thanks. I agree that supporting this in C reproducers should be doable. If we are adding this new way to specifying pseudo-syscalls I would like to move most (all?) of the existing pseudo-syscalls to this new way later. syzkaller/executor/common_linux.h Lines 2057 to 2071 in 1a1f4bd but some are huge and ugly (and some of these will need to be added to pretty huge descriptions files): syzkaller/executor/common_linux.h Lines 1868 to 2054 in 1a1f4bd Have you considered putting these fragments into separate files? Or what do you think about it? |
|
I am also thinking about verifying correctness of descriptions now. And, yes, we will need a signed CLA to accept any of the code. |
|
We need these wrappers to properly generate C reproducers: (if these are not right we will get either compilation errors at a bad time, or lots of unused code, or wrong code) I am thinking how these can be ensured to be correct by design... If we make each syscall go into separate file, i.e. |
|
Yes, we have encountered the problem of larger pseudo-syscalls as well. In our fork, I have almost completely rewritten the top-level Makefile, and it now allows targets to contain their own .c/.cpp source files that will be built when you run |
|
Oh, and would you (or someone else) be willing to make the required pkg/csource changes? I haven't touched that part of the codebase before and won't be able to spend much time on syzkaller work for a while. |
Well, we can use separate *.h files today, it will work effectively roughly the same way. |
Yes, I can do this. This can be done separately. |
I imagine that all future pseudo-syscalls would use the new method, as it only involves adding a section to some syzkaller definitions file as opposed to editing multiple files in the core executor code. Even for long functions, they can still be copy/pasted directly into a declare block. That being said, I do think it would be cleaner to allow .c/.cpp files in the target directory to automatically be compiled in with the executor (as separate compilation units rather than being #included as header files). Even in that case, however, declare would still be useful to provide the declaration for C functions. Alternatively, we could look for a |
|
I think we could generate function declarations automatically. |
Add an empty common_ext.h which is included into executor and C reproducers and can be used to add non-mainline pseudo-syscalls w/o changing any other files (by replacing common_ext.h file). It would be good to finish google#2274 which allows to add pseudo-syscalls along with *.txt descriptions, but google#2274 is large and there are several open design questions. So add this simple extension point for now.
Add an empty common_ext.h which is included into executor and C reproducers and can be used to add non-mainline pseudo-syscalls w/o changing any other files (by replacing common_ext.h file). It would be good to finish #2274 which allows to add pseudo-syscalls along with *.txt descriptions, but #2274 is large and there are several open design questions. So add this simple extension point for now.
This feature adds a new keyword
declarewhich is very useful for defining pseudo-syscalls. A major benefit over the standard method is that as this is part of the syzkaller description files, declare statements with custom C++ code can easily be part of autogenerated syzkaller definitions.For an explanation and example of this feature and its usefulness, refer to the docs: Declare Statements.
Note that in the current iteration, the contents of declare statements aren't automatically added to C repros. I would assume this would be easy. I just haven't used or tested the C repros feature so far, so it wasn't a priority to support it.