Thread (10 messages) flat view 10 messages, 4 authors, 2017-09-20

Re: [PATCH,net-next,0/2] Improve code coverage of syzkaller

From: David Miller <davem@davemloft.net>
Date: 2017-09-19 23:01:35

From: Petar Penkov <redacted>
Date: Tue, 19 Sep 2017 00:34:00 -0700
The following patches address this by providing the user(syzkaller)
with the ability to send via napi_gro_receive() and napi_gro_frags().
Additionally, syzkaller can specify how many fragments there are and
how much data per fragment there is. This is done by exploiting the
convenient structure of iovecs. Finally, this patch series adds
support for exercising the flow dissector during fuzzing.

The code path including napi_gro_receive() can be enabled via the
CONFIG_TUN_NAPI compile-time flag, and can be used by users other than
syzkaller. The remainder of the changes in this patch series give the
user significantly more control over packets entering the kernel. To
avoid potential security vulnerabilities, hide the ability to send
custom skbs and the flow dissector code paths behind a run-time flag
IFF_NAPI_FRAGS that is advertised and accepted only if CONFIG_TUN_NAPI
is enabled.

The patch series will be followed with changes to packetdrill, where
these additions to the TUN driver are exercised and demonstrated.
This will give the ability to write regression tests for specific
parts of the early networking stack.

Patch 1/ Add NAPI struct per receive queue, enable NAPI, and use
	 napi_gro_receive() 
Patch 2/ Use NAPI skb and napi_gro_frags(), exercise flow
	 dissector, and allow custom skbs.
I'm happy with everything except the TUN_NAPI Kconfig knob
requirement.

Rebuilding something just to test things isn't going to fly very well.

Please make it secure somehow, enable this stuff by default.

Thanks.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help