sys/netbsd: Improvements for syscalls in NetBSD

[R3x]

Syscalls and their arguments need to be verified. Also, need to find syscalls that are missing and add support for them.

[R3x]

@dvyukov I have parsed the syscalls definitions from the sys/netbsd/*.txt files and I have listed existing syscalls and the ones missing here - https://gist.github.com/R3x/cf6f70839104519ef43631aebf1d0b91

What I am not sure is of how to improve the same. Do I need to improve the code that does the parsing and try for better results or shall I manually add the syscalls definitions? Some of the files seem to be automatically generated.

[dvyukov]

The *.txt files are manually written. The *.const and *.go files are auto-generated. See https://github.com/google/syzkaller/blob/master/docs/syscall_descriptions.md for details.

If you want to improve descriptions, you need to manually improve the *.txt files. We do not have any automatic way to generate them at the moment.

[krytarowski]

I think such things have to be done manually. with some semiautomatic draft scripts to speedup the work. It is mostly one-time work and adding new entries happen infrequently.

We have introduced a new syscall for the last time 1 year ago.

In an ideal world we would generate such things, but we certainly need more than matching between the syscall name, its number, number of arguments and their type.. and handling special cases in the syzkaller logic.

[R3x]

@dvyukov A doubt regarding the syscall descriptions.

exit(code intptr) <- Here the type is intptr which inturn is converted to &IntType{IntTypeCommon: IntTypeCommon{TypeCommon: TypeCommon{TypeName: "intptr", FldName: "code", TypeSize: 8}}},
here the size is 8 where as int is supposed to be 4 bytes.

I saw the same in Linux as well. Is there a specific reason for not using int32?

[dvyukov]

It does not matter much. Technically all arguments of all syscalls are intptr. The declared type is int32. But on linux the logical type is actually uint8 because 0xff mask is applied. So probably the most precise way for future would be:

exit(res int32[0:0xff])

[krytarowski]

I would go for exit(res int32), because int is the argument passed to real exit(2).

[krytarowski]

https://storage.googleapis.com/syzkaller/cover/ci2-netbsd.html

This link doesn't work. Why? Can we get it to work?

[krytarowski]

http://blog.netbsd.org/tnf/entry/enhancing_syzkaller_support_for_netbsd

[dvyukov]

This link doesn't work. Why? Can we get it to work?

https://github.com/google/syzkaller/issues/1265 for this