[GSOC] Introduction and Microproject

[Dmitry V. Levin]

Hi,

On Fri, Mar 26, 2021 at 12:14:34PM -0400, Srikavin Ramkumar wrote:
> Hi,
> 
> I'm currently drafting a GSoC proposal and had a few questions about the
> implementation of the parser/code generator:
> 
> 1. Is using Python 3 to parse and generate decoders/tests from syzkaller
> descriptions at build time OK? Alternatively, the script could be run when the
> underlying syzkaller descriptions change and the generated code could be
> committed so Python wouldn't be needed to build strace. 

I think such generators do not have to be run at build time.
We have a few scripts in maint directory that are run manually as a part
of maintenance, and the new script would fit into that pattern.

> 2. The syzkaller description language (syzlang) doesn't differentiate between
> (enum-like) mutually exclusive flags and OR-able bit flags [1]. Consider the
> prctl option PR_FP_MODE. It has two flags PR_FP_MODE_FR=1, PR_FP_MODE_FRE=2. If
> we decode the value 3 assuming it is enum-like we would decode it as
> PR_FP_MODE_???, while if we (correctly) treated it as bit flags, we would decode
> it as PR_FP_MODE_FR|PR_FP_MODE_FRE.
> 
> I'd prefer to stick with syzlang since a large number of syscalls/ioctls are
> already defined. Would it be a good idea to extend the syslang language with a
> new type to differentiate between these cases? Or should we keep the original
> syslang description files, but maintain a separate categorization of which flags
> should be treated as bit-wise vs mutually exclusive?
> 
> [1]: https://github.com/google/syzkaller/blob/master/docs/syscall_descriptions.md#flagsenums

This documentation also says that "The fuzzer has logic to distinguish
enums and bit flags".  I don't know how do they do it, but strace
certainly doesn't have anything like that, we have dedicated functions for
printing enums and flags instead.  The idea to extend syzlang to describe
enums, flags, and their hybrids sounds good to me.


-- 
ldv