VIVID/VIMC and media fuzzing

VIVID/VIMC and media fuzzing

[Dmitry Vyukov]

Hello Helen and linux-media,

I've attended your talk "Shifting Media App Development into High
Gear" on OSS Summit last week and approached you with some questions
if/how this can be used for kernel testing. Thanks, turn out to be a
very useful talk!

I am working on syzkaller/syzbot, continuous kernel fuzzing system:
https://github.com/google/syzkaller
https://github.com/google/syzkaller/blob/master/docs/syzbot.md
https://syzkaller.appspot.com

After simply enabling CONFIG_VIDEO_VIMC, CONFIG_VIDEO_VIM2M,
CONFIG_VIDEO_VIVID, CONFIG_VIDEO_VICODEC syzbot has found 8 bugs in
media subsystem in just 24 hours:

KASAN: use-after-free Read in vb2_mmap
https://groups.google.com/forum/#!msg/syzkaller-bugs/XGGH69jMWQ0/S8vfxgEmCgAJ

KASAN: use-after-free Write in __vb2_cleanup_fileio
https://groups.google.com/forum/#!msg/syzkaller-bugs/qKKhsZVPo3o/P6AB2of2CQAJ

WARNING in __vb2_queue_cancel
https://groups.google.com/forum/#!msg/syzkaller-bugs/S29GU_NtfPY/ZvAz8UDtCQAJ

divide error in vivid_vid_cap_s_dv_timings
https://groups.google.com/forum/#!msg/syzkaller-bugs/GwF5zGBCfyg/wnuWmW_sCQAJ

KASAN: use-after-free Read in wake_up_if_idle
https://groups.google.com/forum/#!msg/syzkaller-bugs/aBWb_yV1kiI/sWQO63fkCQAJ

KASAN: use-after-free Read in __vb2_perform_fileio
https://groups.google.com/forum/#!msg/syzkaller-bugs/MdFCZHz0LUQ/qSK_bFbcCQAJ

INFO: task hung in vivid_stop_generating_vid_cap
https://groups.google.com/forum/#!msg/syzkaller-bugs/F_KFW6PVyTA/wTBeHLfTCQAJ

KASAN: null-ptr-deref Write in kthread_stop
https://groups.google.com/forum/#!msg/syzkaller-bugs/u0AGnYvSlf4/fUiyfA_TCQAJ

Based on this I think if we put more effort into media fuzzing, it
will be able to find dozens more.

syzkaller needs descriptions of kernel interfaces to efficiently cover
a subsystem. For example, see:
https://github.com/google/syzkaller/blob/master/sys/linux/uinput.txt
Hopefully you can read it without much explanation, it basically
states that there is that node in /dev and here are ioctls and other
syscalls that are relevant for this device and here are types of
arguments and layout of involved data structures.

Turned we actually have such descriptions for /dev/video* and /dev/v4l-subdev*:
https://github.com/google/syzkaller/blob/master/sys/linux/video4linux.txt
But we don't have anything for /dev/media*, fuzzer merely knows that
it can open the device:
https://github.com/google/syzkaller/blob/12b38f22c18c6109a5cc1c0238d015eef121b9b7/sys/linux/sys.txt#L479
and then it will just blindly execute completely random workload on
it, e.g. most likely it won't be able to come up with a proper complex
structure layout for some ioctls. And I am actually not completely
sure about completeness and coverage of video4linux.txt descriptions
too as they were contributed by somebody interested in android
testing.

I wonder if somebody knowledgeable in /dev/media interface be willing
to contribute additional descriptions?

We also have code coverage reports with the coverage fuzzer achieved
so far. Here in the Cover column:
https://syzkaller.appspot.com/#managers
e.g. this one (but note this is a ~80MB html file):
https://storage.googleapis.com/syzkaller/cover/ci-upstream-kasan-gce-root.html
This can be used to assess e.g. v4l coverage. But I don't know what's
coverable in general from syscalls and what's coverable via the stub
drivers in particular. So some expertise from media developers would
be helpful too.

Do I understand it correctly that when a process opens /dev/video* or
/dev/media* it gets a private instance of the device? In particular,
if several processes test this in parallel, will they collide? Or they
will stress separate objects?

You also mentioned that one of the devices requires some complex setup
via configfs. Is this interface described somewhere? Do you think it's
more profitable to pre-setup some fixed configuration for each test
process? Or just give the setup interface to fuzzer and let it do
random setup? Or both?

Thanks in advance

Re: VIVID/VIMC and media fuzzing

[Hans Verkuil]

On 10/30/2018 03:02 PM, Dmitry Vyukov wrote:
> Hello Helen and linux-media,
> 
> I've attended your talk "Shifting Media App Development into High
> Gear" on OSS Summit last week and approached you with some questions
> if/how this can be used for kernel testing. Thanks, turn out to be a
> very useful talk!
> 
> I am working on syzkaller/syzbot, continuous kernel fuzzing system:
> https://github.com/google/syzkaller
> https://github.com/google/syzkaller/blob/master/docs/syzbot.md
> https://syzkaller.appspot.com
> 
> After simply enabling CONFIG_VIDEO_VIMC, CONFIG_VIDEO_VIM2M,
> CONFIG_VIDEO_VIVID, CONFIG_VIDEO_VICODEC syzbot has found 8 bugs in
> media subsystem in just 24 hours:
> 
> KASAN: use-after-free Read in vb2_mmap
> https://groups.google.com/forum/#!msg/syzkaller-bugs/XGGH69jMWQ0/S8vfxgEmCgAJ
> 
> KASAN: use-after-free Write in __vb2_cleanup_fileio
> https://groups.google.com/forum/#!msg/syzkaller-bugs/qKKhsZVPo3o/P6AB2of2CQAJ
> 
> WARNING in __vb2_queue_cancel
> https://groups.google.com/forum/#!msg/syzkaller-bugs/S29GU_NtfPY/ZvAz8UDtCQAJ
> 
> divide error in vivid_vid_cap_s_dv_timings
> https://groups.google.com/forum/#!msg/syzkaller-bugs/GwF5zGBCfyg/wnuWmW_sCQAJ

Should be fixed by https://patchwork.linuxtv.org/patch/52641/

> 
> KASAN: use-after-free Read in wake_up_if_idle
> https://groups.google.com/forum/#!msg/syzkaller-bugs/aBWb_yV1kiI/sWQO63fkCQAJ
> 
> KASAN: use-after-free Read in __vb2_perform_fileio
> https://groups.google.com/forum/#!msg/syzkaller-bugs/MdFCZHz0LUQ/qSK_bFbcCQAJ
> 
> INFO: task hung in vivid_stop_generating_vid_cap
> https://groups.google.com/forum/#!msg/syzkaller-bugs/F_KFW6PVyTA/wTBeHLfTCQAJ
> 
> KASAN: null-ptr-deref Write in kthread_stop
> https://groups.google.com/forum/#!msg/syzkaller-bugs/u0AGnYvSlf4/fUiyfA_TCQAJ

These last two should be fixed by https://patchwork.linuxtv.org/patch/52640/

Haven't figured out the others yet (hope to get back to that next week).

> 
> Based on this I think if we put more effort into media fuzzing, it
> will be able to find dozens more.

Yeah, this is good stuff. Thank you for setting this up.

> 
> syzkaller needs descriptions of kernel interfaces to efficiently cover
> a subsystem. For example, see:
> https://github.com/google/syzkaller/blob/master/sys/linux/uinput.txt
> Hopefully you can read it without much explanation, it basically
> states that there is that node in /dev and here are ioctls and other
> syscalls that are relevant for this device and here are types of
> arguments and layout of involved data structures.
> 
> Turned we actually have such descriptions for /dev/video* and /dev/v4l-subdev*:
> https://github.com/google/syzkaller/blob/master/sys/linux/video4linux.txt
> But we don't have anything for /dev/media*, fuzzer merely knows that
> it can open the device:
> https://github.com/google/syzkaller/blob/12b38f22c18c6109a5cc1c0238d015eef121b9b7/sys/linux/sys.txt#L479
> and then it will just blindly execute completely random workload on
> it, e.g. most likely it won't be able to come up with a proper complex
> structure layout for some ioctls. And I am actually not completely
> sure about completeness and coverage of video4linux.txt descriptions
> too as they were contributed by somebody interested in android
> testing.

A quick look suggests that it is based on the 4.9 videodev2.h, which ain't
too bad. There are some differences between the 4.20 videodev2.h and the
4.9, but not too many.

> 
> I wonder if somebody knowledgeable in /dev/media interface be willing
> to contribute additional descriptions?

We'll have to wait for 4.20-rc1 to be released since there are important
additions to the media API. I can probably come up with something, I'm
just not sure when I get around to it. Ping me in three weeks time if you
haven't heard from me.

> 
> We also have code coverage reports with the coverage fuzzer achieved
> so far. Here in the Cover column:
> https://syzkaller.appspot.com/#managers
> e.g. this one (but note this is a ~80MB html file):
> https://storage.googleapis.com/syzkaller/cover/ci-upstream-kasan-gce-root.html
> This can be used to assess e.g. v4l coverage. But I don't know what's
> coverable in general from syscalls and what's coverable via the stub
> drivers in particular. So some expertise from media developers would
> be helpful too.

The four virtual drivers should give pretty decent coverage of the core
code. Are you able to test with a 32-bit syzkaller application on a 64-bit
kernel as well? That way the compat32 code is tested.

> 
> Do I understand it correctly that when a process opens /dev/video* or
> /dev/media* it gets a private instance of the device? In particular,
> if several processes test this in parallel, will they collide? Or they
> will stress separate objects?

It actually depends on the driver. M2M devices will give you a private
instance whenever you open it. Others do not, but you can call most ioctls
in parallel. But after calling REQBUFS or CREATE_BUFS the filehandle that
called those ioctls becomes owner of the device until the buffers are
released. So other filehandles cannot do any streaming operations (EBUSY
will be returned).

> You also mentioned that one of the devices requires some complex setup
> via configfs. Is this interface described somewhere? Do you think it's
> more profitable to pre-setup some fixed configuration for each test
> process? Or just give the setup interface to fuzzer and let it do
> random setup? Or both?

That's the vimc driver, but the configfs code isn't in yet.

Regards,

	Hans

> 
> Thanks in advance
> 

Re: VIVID/VIMC and media fuzzing

[Hans Verkuil]

CC-ing Sean Young: please see question at the end.

On 10/31/2018 10:46 AM, Hans Verkuil wrote:
> On 10/30/2018 03:02 PM, Dmitry Vyukov wrote:
>> Hello Helen and linux-media,
>>
>> I've attended your talk "Shifting Media App Development into High
>> Gear" on OSS Summit last week and approached you with some questions
>> if/how this can be used for kernel testing. Thanks, turn out to be a
>> very useful talk!
>>
>> I am working on syzkaller/syzbot, continuous kernel fuzzing system:
>> https://github.com/google/syzkaller
>> https://github.com/google/syzkaller/blob/master/docs/syzbot.md
>> https://syzkaller.appspot.com
>>
>> After simply enabling CONFIG_VIDEO_VIMC, CONFIG_VIDEO_VIM2M,
>> CONFIG_VIDEO_VIVID, CONFIG_VIDEO_VICODEC syzbot has found 8 bugs in
>> media subsystem in just 24 hours:
>>
>> KASAN: use-after-free Read in vb2_mmap
>> https://groups.google.com/forum/#!msg/syzkaller-bugs/XGGH69jMWQ0/S8vfxgEmCgAJ
>>
>> KASAN: use-after-free Write in __vb2_cleanup_fileio
>> https://groups.google.com/forum/#!msg/syzkaller-bugs/qKKhsZVPo3o/P6AB2of2CQAJ
>>
>> WARNING in __vb2_queue_cancel
>> https://groups.google.com/forum/#!msg/syzkaller-bugs/S29GU_NtfPY/ZvAz8UDtCQAJ
>>
>> divide error in vivid_vid_cap_s_dv_timings
>> https://groups.google.com/forum/#!msg/syzkaller-bugs/GwF5zGBCfyg/wnuWmW_sCQAJ
> 
> Should be fixed by https://patchwork.linuxtv.org/patch/52641/
> 
>>
>> KASAN: use-after-free Read in wake_up_if_idle
>> https://groups.google.com/forum/#!msg/syzkaller-bugs/aBWb_yV1kiI/sWQO63fkCQAJ
>>
>> KASAN: use-after-free Read in __vb2_perform_fileio
>> https://groups.google.com/forum/#!msg/syzkaller-bugs/MdFCZHz0LUQ/qSK_bFbcCQAJ
>>
>> INFO: task hung in vivid_stop_generating_vid_cap
>> https://groups.google.com/forum/#!msg/syzkaller-bugs/F_KFW6PVyTA/wTBeHLfTCQAJ
>>
>> KASAN: null-ptr-deref Write in kthread_stop
>> https://groups.google.com/forum/#!msg/syzkaller-bugs/u0AGnYvSlf4/fUiyfA_TCQAJ
> 
> These last two should be fixed by https://patchwork.linuxtv.org/patch/52640/
> 
> Haven't figured out the others yet (hope to get back to that next week).
> 
>>
>> Based on this I think if we put more effort into media fuzzing, it
>> will be able to find dozens more.
> 
> Yeah, this is good stuff. Thank you for setting this up.
> 
>>
>> syzkaller needs descriptions of kernel interfaces to efficiently cover
>> a subsystem. For example, see:
>> https://github.com/google/syzkaller/blob/master/sys/linux/uinput.txt
>> Hopefully you can read it without much explanation, it basically
>> states that there is that node in /dev and here are ioctls and other
>> syscalls that are relevant for this device and here are types of
>> arguments and layout of involved data structures.
>>
>> Turned we actually have such descriptions for /dev/video* and /dev/v4l-subdev*:
>> https://github.com/google/syzkaller/blob/master/sys/linux/video4linux.txt
>> But we don't have anything for /dev/media*, fuzzer merely knows that
>> it can open the device:
>> https://github.com/google/syzkaller/blob/12b38f22c18c6109a5cc1c0238d015eef121b9b7/sys/linux/sys.txt#L479
>> and then it will just blindly execute completely random workload on
>> it, e.g. most likely it won't be able to come up with a proper complex
>> structure layout for some ioctls. And I am actually not completely
>> sure about completeness and coverage of video4linux.txt descriptions
>> too as they were contributed by somebody interested in android
>> testing.
> 
> A quick look suggests that it is based on the 4.9 videodev2.h, which ain't
> too bad. There are some differences between the 4.20 videodev2.h and the
> 4.9, but not too many.
> 
>>
>> I wonder if somebody knowledgeable in /dev/media interface be willing
>> to contribute additional descriptions?
> 
> We'll have to wait for 4.20-rc1 to be released since there are important
> additions to the media API. I can probably come up with something, I'm
> just not sure when I get around to it. Ping me in three weeks time if you
> haven't heard from me.

While adding support for the media API I should also add support for the CEC
API, since vivid can emulate a CEC device as well.

It would be really neat to have similar support for DVB and RC as well, but we
don't have virtual drivers for those. Although CEC can expose an RC input device
if enabled by the kernel config.

Sean, would that be a good starting point for fuzzing the RC API? Or do you think
we really need proper RC emulation in vivid as we discussed last week?

Regards,

	Hans

Re: VIVID/VIMC and media fuzzing

[Sean Young]

On Wed, Oct 31, 2018 at 11:05:10AM +0100, Hans Verkuil wrote:
> CC-ing Sean Young: please see question at the end.
> 
> On 10/31/2018 10:46 AM, Hans Verkuil wrote:
> > On 10/30/2018 03:02 PM, Dmitry Vyukov wrote:
> >> Hello Helen and linux-media,
> >>
> >> I've attended your talk "Shifting Media App Development into High
> >> Gear" on OSS Summit last week and approached you with some questions
> >> if/how this can be used for kernel testing. Thanks, turn out to be a
> >> very useful talk!
> >>
> >> I am working on syzkaller/syzbot, continuous kernel fuzzing system:
> >> https://github.com/google/syzkaller
> >> https://github.com/google/syzkaller/blob/master/docs/syzbot.md
> >> https://syzkaller.appspot.com
> >>
> >> After simply enabling CONFIG_VIDEO_VIMC, CONFIG_VIDEO_VIM2M,
> >> CONFIG_VIDEO_VIVID, CONFIG_VIDEO_VICODEC syzbot has found 8 bugs in
> >> media subsystem in just 24 hours:
> >>
> >> KASAN: use-after-free Read in vb2_mmap
> >> https://groups.google.com/forum/#!msg/syzkaller-bugs/XGGH69jMWQ0/S8vfxgEmCgAJ
> >>
> >> KASAN: use-after-free Write in __vb2_cleanup_fileio
> >> https://groups.google.com/forum/#!msg/syzkaller-bugs/qKKhsZVPo3o/P6AB2of2CQAJ
> >>
> >> WARNING in __vb2_queue_cancel
> >> https://groups.google.com/forum/#!msg/syzkaller-bugs/S29GU_NtfPY/ZvAz8UDtCQAJ
> >>
> >> divide error in vivid_vid_cap_s_dv_timings
> >> https://groups.google.com/forum/#!msg/syzkaller-bugs/GwF5zGBCfyg/wnuWmW_sCQAJ
> > 
> > Should be fixed by https://patchwork.linuxtv.org/patch/52641/
> > 
> >>
> >> KASAN: use-after-free Read in wake_up_if_idle
> >> https://groups.google.com/forum/#!msg/syzkaller-bugs/aBWb_yV1kiI/sWQO63fkCQAJ
> >>
> >> KASAN: use-after-free Read in __vb2_perform_fileio
> >> https://groups.google.com/forum/#!msg/syzkaller-bugs/MdFCZHz0LUQ/qSK_bFbcCQAJ
> >>
> >> INFO: task hung in vivid_stop_generating_vid_cap
> >> https://groups.google.com/forum/#!msg/syzkaller-bugs/F_KFW6PVyTA/wTBeHLfTCQAJ
> >>
> >> KASAN: null-ptr-deref Write in kthread_stop
> >> https://groups.google.com/forum/#!msg/syzkaller-bugs/u0AGnYvSlf4/fUiyfA_TCQAJ
> > 
> > These last two should be fixed by https://patchwork.linuxtv.org/patch/52640/
> > 
> > Haven't figured out the others yet (hope to get back to that next week).
> > 
> >>
> >> Based on this I think if we put more effort into media fuzzing, it
> >> will be able to find dozens more.
> > 
> > Yeah, this is good stuff. Thank you for setting this up.
> > 
> >>
> >> syzkaller needs descriptions of kernel interfaces to efficiently cover
> >> a subsystem. For example, see:
> >> https://github.com/google/syzkaller/blob/master/sys/linux/uinput.txt
> >> Hopefully you can read it without much explanation, it basically
> >> states that there is that node in /dev and here are ioctls and other
> >> syscalls that are relevant for this device and here are types of
> >> arguments and layout of involved data structures.
> >>
> >> Turned we actually have such descriptions for /dev/video* and /dev/v4l-subdev*:
> >> https://github.com/google/syzkaller/blob/master/sys/linux/video4linux.txt
> >> But we don't have anything for /dev/media*, fuzzer merely knows that
> >> it can open the device:
> >> https://github.com/google/syzkaller/blob/12b38f22c18c6109a5cc1c0238d015eef121b9b7/sys/linux/sys.txt#L479
> >> and then it will just blindly execute completely random workload on
> >> it, e.g. most likely it won't be able to come up with a proper complex
> >> structure layout for some ioctls. And I am actually not completely
> >> sure about completeness and coverage of video4linux.txt descriptions
> >> too as they were contributed by somebody interested in android
> >> testing.
> > 
> > A quick look suggests that it is based on the 4.9 videodev2.h, which ain't
> > too bad. There are some differences between the 4.20 videodev2.h and the
> > 4.9, but not too many.
> > 
> >>
> >> I wonder if somebody knowledgeable in /dev/media interface be willing
> >> to contribute additional descriptions?
> > 
> > We'll have to wait for 4.20-rc1 to be released since there are important
> > additions to the media API. I can probably come up with something, I'm
> > just not sure when I get around to it. Ping me in three weeks time if you
> > haven't heard from me.
> 
> While adding support for the media API I should also add support for the CEC
> API, since vivid can emulate a CEC device as well.
> 
> It would be really neat to have similar support for DVB and RC as well, but we
> don't have virtual drivers for those. Although CEC can expose an RC input device
> if enabled by the kernel config.

I've been looking at this (adding DVB and RC) as we discussed. I like this
idea, as it also helps me with getting started with DVB.

> Sean, would that be a good starting point for fuzzing the RC API? Or do you think
> we really need proper RC emulation in vivid as we discussed last week?

So if we have an RC device which his not CEC, then we can do much more
testing with raw IR for example.

I'll make a start this weekend.


Sean

Re: VIVID/VIMC and media fuzzing

[Helen Koike]

Hi Dmitry,

On 10/31/18 7:46 AM, Hans Verkuil wrote:
> On 10/30/2018 03:02 PM, Dmitry Vyukov wrote:
>> Hello Helen and linux-media,
>>
>> I've attended your talk "Shifting Media App Development into High
>> Gear" on OSS Summit last week and approached you with some questions
>> if/how this can be used for kernel testing. Thanks, turn out to be a
>> very useful talk!

Great, I am  glad it was useful :)

>>
>> I am working on syzkaller/syzbot, continuous kernel fuzzing system:
>> https://github.com/google/syzkaller
>> https://github.com/google/syzkaller/blob/master/docs/syzbot.md
>> https://syzkaller.appspot.com
>>
>> After simply enabling CONFIG_VIDEO_VIMC, CONFIG_VIDEO_VIM2M,
>> CONFIG_VIDEO_VIVID, CONFIG_VIDEO_VICODEC syzbot has found 8 bugs in
>> media subsystem in just 24 hours:
>>
>> KASAN: use-after-free Read in vb2_mmap
>> https://groups.google.com/forum/#!msg/syzkaller-bugs/XGGH69jMWQ0/S8vfxgEmCgAJ
>>
>> KASAN: use-after-free Write in __vb2_cleanup_fileio
>> https://groups.google.com/forum/#!msg/syzkaller-bugs/qKKhsZVPo3o/P6AB2of2CQAJ
>>
>> WARNING in __vb2_queue_cancel
>> https://groups.google.com/forum/#!msg/syzkaller-bugs/S29GU_NtfPY/ZvAz8UDtCQAJ
>>
>> divide error in vivid_vid_cap_s_dv_timings
>> https://groups.google.com/forum/#!msg/syzkaller-bugs/GwF5zGBCfyg/wnuWmW_sCQAJ
> 
> Should be fixed by https://patchwork.linuxtv.org/patch/52641/
> 
>>
>> KASAN: use-after-free Read in wake_up_if_idle
>> https://groups.google.com/forum/#!msg/syzkaller-bugs/aBWb_yV1kiI/sWQO63fkCQAJ
>>
>> KASAN: use-after-free Read in __vb2_perform_fileio
>> https://groups.google.com/forum/#!msg/syzkaller-bugs/MdFCZHz0LUQ/qSK_bFbcCQAJ
>>
>> INFO: task hung in vivid_stop_generating_vid_cap
>> https://groups.google.com/forum/#!msg/syzkaller-bugs/F_KFW6PVyTA/wTBeHLfTCQAJ
>>
>> KASAN: null-ptr-deref Write in kthread_stop
>> https://groups.google.com/forum/#!msg/syzkaller-bugs/u0AGnYvSlf4/fUiyfA_TCQAJ
> 
> These last two should be fixed by https://patchwork.linuxtv.org/patch/52640/
> 
> Haven't figured out the others yet (hope to get back to that next week).
> 
>>
>> Based on this I think if we put more effort into media fuzzing, it
>> will be able to find dozens more.
> 
> Yeah, this is good stuff. Thank you for setting this up.

Agreed, Dmitry thank you for doing this.

> 
>>
>> syzkaller needs descriptions of kernel interfaces to efficiently cover
>> a subsystem. For example, see:
>> https://github.com/google/syzkaller/blob/master/sys/linux/uinput.txt
>> Hopefully you can read it without much explanation, it basically
>> states that there is that node in /dev and here are ioctls and other
>> syscalls that are relevant for this device and here are types of
>> arguments and layout of involved data structures.
>>
>> Turned we actually have such descriptions for /dev/video* and /dev/v4l-subdev*:
>> https://github.com/google/syzkaller/blob/master/sys/linux/video4linux.txt
>> But we don't have anything for /dev/media*, fuzzer merely knows that
>> it can open the device:
>> https://github.com/google/syzkaller/blob/12b38f22c18c6109a5cc1c0238d015eef121b9b7/sys/linux/sys.txt#L479
>> and then it will just blindly execute completely random workload on
>> it, e.g. most likely it won't be able to come up with a proper complex
>> structure layout for some ioctls. And I am actually not completely
>> sure about completeness and coverage of video4linux.txt descriptions
>> too as they were contributed by somebody interested in android
>> testing.
> 
> A quick look suggests that it is based on the 4.9 videodev2.h, which ain't
> too bad. There are some differences between the 4.20 videodev2.h and the
> 4.9, but not too many.
> 
>>
>> I wonder if somebody knowledgeable in /dev/media interface be willing
>> to contribute additional descriptions?
> 
> We'll have to wait for 4.20-rc1 to be released since there are important
> additions to the media API. I can probably come up with something, I'm
> just not sure when I get around to it. Ping me in three weeks time if you
> haven't heard from me.
> 
>>
>> We also have code coverage reports with the coverage fuzzer achieved
>> so far. Here in the Cover column:
>> https://syzkaller.appspot.com/#managers
>> e.g. this one (but note this is a ~80MB html file):
>> https://storage.googleapis.com/syzkaller/cover/ci-upstream-kasan-gce-root.html
>> This can be used to assess e.g. v4l coverage. But I don't know what's
>> coverable in general from syscalls and what's coverable via the stub
>> drivers in particular. So some expertise from media developers would
>> be helpful too.
> 
> The four virtual drivers should give pretty decent coverage of the core
> code. Are you able to test with a 32-bit syzkaller application on a 64-bit
> kernel as well? That way the compat32 code is tested.
> 
>>
>> Do I understand it correctly that when a process opens /dev/video* or
>> /dev/media* it gets a private instance of the device? In particular,
>> if several processes test this in parallel, will they collide? Or they
>> will stress separate objects?
> 
> It actually depends on the driver. M2M devices will give you a private
> instance whenever you open it. Others do not, but you can call most ioctls
> in parallel. But after calling REQBUFS or CREATE_BUFS the filehandle that
> called those ioctls becomes owner of the device until the buffers are
> released. So other filehandles cannot do any streaming operations (EBUSY
> will be returned).
> 
>> You also mentioned that one of the devices requires some complex setup
>> via configfs. Is this interface described somewhere? Do you think it's
>> more profitable to pre-setup some fixed configuration for each test
>> process? Or just give the setup interface to fuzzer and let it do
>> random setup? Or both?
> 
> That's the vimc driver, but the configfs code isn't in yet.

I'll try to submit it later this week (with documentation) :)

> 
> Regards,
> 
> 	Hans
> 
>>
>> Thanks in advance
>>
> 


Thanks
Helen

Re: VIVID/VIMC and media fuzzing

[Tomasz Figa]

Hi Dmitry,

On Wed, Oct 31, 2018 at 6:46 PM Hans Verkuil <hverkuil@xs4all.nl> wrote:
>
> On 10/30/2018 03:02 PM, Dmitry Vyukov wrote:
[snip]
> >
> > Do I understand it correctly that when a process opens /dev/video* or
> > /dev/media* it gets a private instance of the device? In particular,
> > if several processes test this in parallel, will they collide? Or they
> > will stress separate objects?
>
> It actually depends on the driver. M2M devices will give you a private
> instance whenever you open it. Others do not, but you can call most ioctls
> in parallel. But after calling REQBUFS or CREATE_BUFS the filehandle that
> called those ioctls becomes owner of the device until the buffers are
> released. So other filehandles cannot do any streaming operations (EBUSY
> will be returned).

FWIW, you can query whether the device is M2M or not by
VIDIOC_QUERYCAP [1]. The capabilities field would have
V4L2_CAP_VIDEO_M2M or V4L2_CAP_VIDEO_M2M_MPLANE set for M2M devices.

[1] https://www.kernel.org/doc/html/latest/media/uapi/v4l/vidioc-querycap.html

Best regards,
Tomasz

Re: VIVID/VIMC and media fuzzing

[Dmitry Vyukov]

On Wed, Oct 31, 2018 at 10:46 AM, Hans Verkuil <hverkuil@xs4all.nl> wrote:
> On 10/30/2018 03:02 PM, Dmitry Vyukov wrote:
>> Hello Helen and linux-media,
>>
>> I've attended your talk "Shifting Media App Development into High
>> Gear" on OSS Summit last week and approached you with some questions
>> if/how this can be used for kernel testing. Thanks, turn out to be a
>> very useful talk!
>>
>> I am working on syzkaller/syzbot, continuous kernel fuzzing system:
>> https://github.com/google/syzkaller
>> https://github.com/google/syzkaller/blob/master/docs/syzbot.md
>> https://syzkaller.appspot.com
>>
>> After simply enabling CONFIG_VIDEO_VIMC, CONFIG_VIDEO_VIM2M,
>> CONFIG_VIDEO_VIVID, CONFIG_VIDEO_VICODEC syzbot has found 8 bugs in
>> media subsystem in just 24 hours:
>>
>> KASAN: use-after-free Read in vb2_mmap
>> https://groups.google.com/forum/#!msg/syzkaller-bugs/XGGH69jMWQ0/S8vfxgEmCgAJ
>>
>> KASAN: use-after-free Write in __vb2_cleanup_fileio
>> https://groups.google.com/forum/#!msg/syzkaller-bugs/qKKhsZVPo3o/P6AB2of2CQAJ
>>
>> WARNING in __vb2_queue_cancel
>> https://groups.google.com/forum/#!msg/syzkaller-bugs/S29GU_NtfPY/ZvAz8UDtCQAJ
>>
>> divide error in vivid_vid_cap_s_dv_timings
>> https://groups.google.com/forum/#!msg/syzkaller-bugs/GwF5zGBCfyg/wnuWmW_sCQAJ
>
> Should be fixed by https://patchwork.linuxtv.org/patch/52641/
>
>>
>> KASAN: use-after-free Read in wake_up_if_idle
>> https://groups.google.com/forum/#!msg/syzkaller-bugs/aBWb_yV1kiI/sWQO63fkCQAJ
>>
>> KASAN: use-after-free Read in __vb2_perform_fileio
>> https://groups.google.com/forum/#!msg/syzkaller-bugs/MdFCZHz0LUQ/qSK_bFbcCQAJ
>>
>> INFO: task hung in vivid_stop_generating_vid_cap
>> https://groups.google.com/forum/#!msg/syzkaller-bugs/F_KFW6PVyTA/wTBeHLfTCQAJ
>>
>> KASAN: null-ptr-deref Write in kthread_stop
>> https://groups.google.com/forum/#!msg/syzkaller-bugs/u0AGnYvSlf4/fUiyfA_TCQAJ
>
> These last two should be fixed by https://patchwork.linuxtv.org/patch/52640/

This is great!
This last one happens super frequently, so harms ability to find other bugs.

> Haven't figured out the others yet (hope to get back to that next week).

But note that syzbot added few more too! :)

And there will be more, when I run syzkaller locally aimed only at
these devices I got:

general protection fault in vma_interval_tree_subtree_search
WARNING in dev_watchdog
BUG: unable to handle kernel paging request in tpg_print_str_6
kernel BUG at arch/x86/mm/physaddr.c:LINE!
BUG: unable to handle kernel NULL pointer dereference in qlist_free_all
INFO: rcu detected stall in corrupted
general protection fault in debug_check_no_obj_freed
KASAN: use-after-free Write in __vb2_cleanup_fileio
INFO: task hung in vivid_stop_generating_vid_cap
general protection fault in __bfs
divide error in vivid_thread_vid_out
KASAN: null-ptr-deref Write in kthread_stop
lost connection to test machine
general protection fault in __neigh_notify
BUG: unable to handle kernel paging request in tpg_print_str_2
BUG: unable to handle kernel NULL pointer dereference in corrupted
INFO: trying to register non-static key in corrupted
divide error in vivid_vid_cap_s_dv_timings
KASAN: null-ptr-deref Read in refcount_sub_and_test_checked
KASAN: use-after-free Read in v4l2_ctrl_grab
INFO: rcu detected stall in v4l2_ioctl
kernel panic: stack-protector: Kernel stack is corrupted in: do_vfs_ioctl
INFO: rcu detected stall in e1000_watchdog
BUG: unable to handle kernel paging request in corrupted
KASAN: use-after-free Read in vb2_mmap
BUG: unable to handle kernel paging request in tpg_print_str_4
BUG: unable to handle kernel paging request in tpg_print_str_8
kernel BUG at mm/vmalloc.c:LINE!
kernel panic: corrupted stack end detected inside scheduler
KASAN: stack-out-of-bounds Read in __schedule
WARNING in __vb2_queue_cancel
general protection fault in corrupted
KASAN: use-after-free Read in __vb2_perform_fileio
BUG: unable to handle kernel NULL pointer dereference in kthread_stop
general protection fault in fib_sync_down_dev
BUG: pagefault on kernel address ADDR in non-whitelisted uaccess
general protection fault in __vb2_queue_free
INFO: rcu detected stall in do_signal
INFO: task hung in corrupted
kernel BUG at include/linux/mm.h:LINE!
no output from test machine
BUG: workqueue lockup
KASAN: null-ptr-deref in kthread_stop
INFO: rcu detected stall in tcp_keepalive_timer



>> Based on this I think if we put more effort into media fuzzing, it
>> will be able to find dozens more.
>
> Yeah, this is good stuff. Thank you for setting this up.
>
>>
>> syzkaller needs descriptions of kernel interfaces to efficiently cover
>> a subsystem. For example, see:
>> https://github.com/google/syzkaller/blob/master/sys/linux/uinput.txt
>> Hopefully you can read it without much explanation, it basically
>> states that there is that node in /dev and here are ioctls and other
>> syscalls that are relevant for this device and here are types of
>> arguments and layout of involved data structures.
>>
>> Turned we actually have such descriptions for /dev/video* and /dev/v4l-subdev*:
>> https://github.com/google/syzkaller/blob/master/sys/linux/video4linux.txt
>> But we don't have anything for /dev/media*, fuzzer merely knows that
>> it can open the device:
>> https://github.com/google/syzkaller/blob/12b38f22c18c6109a5cc1c0238d015eef121b9b7/sys/linux/sys.txt#L479
>> and then it will just blindly execute completely random workload on
>> it, e.g. most likely it won't be able to come up with a proper complex
>> structure layout for some ioctls. And I am actually not completely
>> sure about completeness and coverage of video4linux.txt descriptions
>> too as they were contributed by somebody interested in android
>> testing.
>
> A quick look suggests that it is based on the 4.9 videodev2.h, which ain't
> too bad. There are some differences between the 4.20 videodev2.h and the
> 4.9, but not too many.


Makes sense because the latest android use 4.9.
Looking at the diff with 4.9 it seems that the APIs were mostly just
extended, so we just need to extend syzkaller descriptions
correspondingly.

>> I wonder if somebody knowledgeable in /dev/media interface be willing
>> to contribute additional descriptions?
>
> We'll have to wait for 4.20-rc1 to be released since there are important
> additions to the media API.

Additions are fine. We can extend syzkaller descriptions later too.
But if they are already in, say, linux-next, then syzbot tests it too.


> I can probably come up with something, I'm
> just not sure when I get around to it. Ping me in three weeks time if you
> haven't heard from me.
>
>>
>> We also have code coverage reports with the coverage fuzzer achieved
>> so far. Here in the Cover column:
>> https://syzkaller.appspot.com/#managers
>> e.g. this one (but note this is a ~80MB html file):
>> https://storage.googleapis.com/syzkaller/cover/ci-upstream-kasan-gce-root.html
>> This can be used to assess e.g. v4l coverage. But I don't know what's
>> coverable in general from syscalls and what's coverable via the stub
>> drivers in particular. So some expertise from media developers would
>> be helpful too.
>
> The four virtual drivers should give pretty decent coverage of the core
> code. Are you able to test with a 32-bit syzkaller application on a 64-bit
> kernel as well? That way the compat32 code is tested.

This is coverage from 32-bit instance:
https://storage.googleapis.com/syzkaller/cover/ci-upstream-kasan-gce-386.html
There is some coverage in drivers/media, but I don't know where to
look specifically. E.g. drivers/media/v4l2-core/v4l2-ioctl.c does not
mention "compat".


>> Do I understand it correctly that when a process opens /dev/video* or
>> /dev/media* it gets a private instance of the device? In particular,
>> if several processes test this in parallel, will they collide? Or they
>> will stress separate objects?
>
> It actually depends on the driver. M2M devices will give you a private
> instance whenever you open it. Others do not, but you can call most ioctls
> in parallel. But after calling REQBUFS or CREATE_BUFS the filehandle that
> called those ioctls becomes owner of the device until the buffers are
> released. So other filehandles cannot do any streaming operations (EBUSY
> will be returned).

Are the devices created by VIMC, VIM2M, VIVID, VICODEC M2M or not?
I guess VIM2M is M2M, but what about others?

CREATE_BUFS privatization is somewhat unfortunate, but I guess we can
live with it for now.
I assume that when the process dies it will release everything at
least, because fuzzer will sure not pair create with release all the
time.


>> You also mentioned that one of the devices requires some complex setup
>> via configfs. Is this interface described somewhere? Do you think it's
>> more profitable to pre-setup some fixed configuration for each test
>> process? Or just give the setup interface to fuzzer and let it do
>> random setup? Or both?
>
> That's the vimc driver, but the configfs code isn't in yet.
>
> Regards,
>
>         Hans
>

Re: VIVID/VIMC and media fuzzing

[Dmitry Vyukov]

On Wed, Oct 31, 2018 at 12:01 PM, Sean Young <sean@mess.org> wrote:
> On Wed, Oct 31, 2018 at 11:05:10AM +0100, Hans Verkuil wrote:
>> CC-ing Sean Young: please see question at the end.
>>
>> On 10/31/2018 10:46 AM, Hans Verkuil wrote:
>> > On 10/30/2018 03:02 PM, Dmitry Vyukov wrote:
>> >> Hello Helen and linux-media,
>> >>
>> >> I've attended your talk "Shifting Media App Development into High
>> >> Gear" on OSS Summit last week and approached you with some questions
>> >> if/how this can be used for kernel testing. Thanks, turn out to be a
>> >> very useful talk!
>> >>
>> >> I am working on syzkaller/syzbot, continuous kernel fuzzing system:
>> >> https://github.com/google/syzkaller
>> >> https://github.com/google/syzkaller/blob/master/docs/syzbot.md
>> >> https://syzkaller.appspot.com
>> >>
>> >> After simply enabling CONFIG_VIDEO_VIMC, CONFIG_VIDEO_VIM2M,
>> >> CONFIG_VIDEO_VIVID, CONFIG_VIDEO_VICODEC syzbot has found 8 bugs in
>> >> media subsystem in just 24 hours:
>> >>
>> >> KASAN: use-after-free Read in vb2_mmap
>> >> https://groups.google.com/forum/#!msg/syzkaller-bugs/XGGH69jMWQ0/S8vfxgEmCgAJ
>> >>
>> >> KASAN: use-after-free Write in __vb2_cleanup_fileio
>> >> https://groups.google.com/forum/#!msg/syzkaller-bugs/qKKhsZVPo3o/P6AB2of2CQAJ
>> >>
>> >> WARNING in __vb2_queue_cancel
>> >> https://groups.google.com/forum/#!msg/syzkaller-bugs/S29GU_NtfPY/ZvAz8UDtCQAJ
>> >>
>> >> divide error in vivid_vid_cap_s_dv_timings
>> >> https://groups.google.com/forum/#!msg/syzkaller-bugs/GwF5zGBCfyg/wnuWmW_sCQAJ
>> >
>> > Should be fixed by https://patchwork.linuxtv.org/patch/52641/
>> >
>> >>
>> >> KASAN: use-after-free Read in wake_up_if_idle
>> >> https://groups.google.com/forum/#!msg/syzkaller-bugs/aBWb_yV1kiI/sWQO63fkCQAJ
>> >>
>> >> KASAN: use-after-free Read in __vb2_perform_fileio
>> >> https://groups.google.com/forum/#!msg/syzkaller-bugs/MdFCZHz0LUQ/qSK_bFbcCQAJ
>> >>
>> >> INFO: task hung in vivid_stop_generating_vid_cap
>> >> https://groups.google.com/forum/#!msg/syzkaller-bugs/F_KFW6PVyTA/wTBeHLfTCQAJ
>> >>
>> >> KASAN: null-ptr-deref Write in kthread_stop
>> >> https://groups.google.com/forum/#!msg/syzkaller-bugs/u0AGnYvSlf4/fUiyfA_TCQAJ
>> >
>> > These last two should be fixed by https://patchwork.linuxtv.org/patch/52640/
>> >
>> > Haven't figured out the others yet (hope to get back to that next week).
>> >
>> >>
>> >> Based on this I think if we put more effort into media fuzzing, it
>> >> will be able to find dozens more.
>> >
>> > Yeah, this is good stuff. Thank you for setting this up.
>> >
>> >>
>> >> syzkaller needs descriptions of kernel interfaces to efficiently cover
>> >> a subsystem. For example, see:
>> >> https://github.com/google/syzkaller/blob/master/sys/linux/uinput.txt
>> >> Hopefully you can read it without much explanation, it basically
>> >> states that there is that node in /dev and here are ioctls and other
>> >> syscalls that are relevant for this device and here are types of
>> >> arguments and layout of involved data structures.
>> >>
>> >> Turned we actually have such descriptions for /dev/video* and /dev/v4l-subdev*:
>> >> https://github.com/google/syzkaller/blob/master/sys/linux/video4linux.txt
>> >> But we don't have anything for /dev/media*, fuzzer merely knows that
>> >> it can open the device:
>> >> https://github.com/google/syzkaller/blob/12b38f22c18c6109a5cc1c0238d015eef121b9b7/sys/linux/sys.txt#L479
>> >> and then it will just blindly execute completely random workload on
>> >> it, e.g. most likely it won't be able to come up with a proper complex
>> >> structure layout for some ioctls. And I am actually not completely
>> >> sure about completeness and coverage of video4linux.txt descriptions
>> >> too as they were contributed by somebody interested in android
>> >> testing.
>> >
>> > A quick look suggests that it is based on the 4.9 videodev2.h, which ain't
>> > too bad. There are some differences between the 4.20 videodev2.h and the
>> > 4.9, but not too many.
>> >
>> >>
>> >> I wonder if somebody knowledgeable in /dev/media interface be willing
>> >> to contribute additional descriptions?
>> >
>> > We'll have to wait for 4.20-rc1 to be released since there are important
>> > additions to the media API. I can probably come up with something, I'm
>> > just not sure when I get around to it. Ping me in three weeks time if you
>> > haven't heard from me.
>>
>> While adding support for the media API I should also add support for the CEC
>> API, since vivid can emulate a CEC device as well.
>>
>> It would be really neat to have similar support for DVB and RC as well, but we
>> don't have virtual drivers for those. Although CEC can expose an RC input device
>> if enabled by the kernel config.
>
> I've been looking at this (adding DVB and RC) as we discussed. I like this
> idea, as it also helps me with getting started with DVB.
>
>> Sean, would that be a good starting point for fuzzing the RC API? Or do you think
>> we really need proper RC emulation in vivid as we discussed last week?
>
> So if we have an RC device which his not CEC, then we can do much more
> testing with raw IR for example.
>
> I'll make a start this weekend.

I don't understand any of this, but adding more virtual devices sounds
good to me :)
Not just fuzzing, but also unit-testing.

Re: VIVID/VIMC and media fuzzing

[Hans Verkuil]

Hi Dmitry,

On 11/02/18 18:15, Dmitry Vyukov wrote:
> On Wed, Oct 31, 2018 at 10:46 AM, Hans Verkuil <hverkuil@xs4all.nl> wrote:
>> On 10/30/2018 03:02 PM, Dmitry Vyukov wrote:
>>> Hello Helen and linux-media,
>>>
>>> I've attended your talk "Shifting Media App Development into High
>>> Gear" on OSS Summit last week and approached you with some questions
>>> if/how this can be used for kernel testing. Thanks, turn out to be a
>>> very useful talk!
>>>
>>> I am working on syzkaller/syzbot, continuous kernel fuzzing system:
>>> https://github.com/google/syzkaller
>>> https://github.com/google/syzkaller/blob/master/docs/syzbot.md
>>> https://syzkaller.appspot.com
>>>
>>> After simply enabling CONFIG_VIDEO_VIMC, CONFIG_VIDEO_VIM2M,
>>> CONFIG_VIDEO_VIVID, CONFIG_VIDEO_VICODEC syzbot has found 8 bugs in
>>> media subsystem in just 24 hours:
>>>
>>> KASAN: use-after-free Read in vb2_mmap
>>> https://groups.google.com/forum/#!msg/syzkaller-bugs/XGGH69jMWQ0/S8vfxgEmCgAJ
>>>
>>> KASAN: use-after-free Write in __vb2_cleanup_fileio
>>> https://groups.google.com/forum/#!msg/syzkaller-bugs/qKKhsZVPo3o/P6AB2of2CQAJ
>>>
>>> WARNING in __vb2_queue_cancel
>>> https://groups.google.com/forum/#!msg/syzkaller-bugs/S29GU_NtfPY/ZvAz8UDtCQAJ
>>>
>>> divide error in vivid_vid_cap_s_dv_timings
>>> https://groups.google.com/forum/#!msg/syzkaller-bugs/GwF5zGBCfyg/wnuWmW_sCQAJ
>>
>> Should be fixed by https://patchwork.linuxtv.org/patch/52641/
>>
>>>
>>> KASAN: use-after-free Read in wake_up_if_idle
>>> https://groups.google.com/forum/#!msg/syzkaller-bugs/aBWb_yV1kiI/sWQO63fkCQAJ
>>>
>>> KASAN: use-after-free Read in __vb2_perform_fileio
>>> https://groups.google.com/forum/#!msg/syzkaller-bugs/MdFCZHz0LUQ/qSK_bFbcCQAJ
>>>
>>> INFO: task hung in vivid_stop_generating_vid_cap
>>> https://groups.google.com/forum/#!msg/syzkaller-bugs/F_KFW6PVyTA/wTBeHLfTCQAJ
>>>
>>> KASAN: null-ptr-deref Write in kthread_stop
>>> https://groups.google.com/forum/#!msg/syzkaller-bugs/u0AGnYvSlf4/fUiyfA_TCQAJ
>>
>> These last two should be fixed by https://patchwork.linuxtv.org/patch/52640/
> 
> This is great!
> This last one happens super frequently, so harms ability to find other bugs.
> 
>> Haven't figured out the others yet (hope to get back to that next week).
> 
> But note that syzbot added few more too! :)

As of now (Fri Nov  9 14:47:31 CET 2018) I fixed all media-related syzbot
issues with the exception of https://syzkaller.appspot.com/bug?extid=f9966a25169b6d66d61f

There is no reproducer for that one and I couldn't figure out how it could
happen.

I've posted patches for all issues except for two that deal with reproducers
using dup2(). I need to think about my fixes a bit more. dup2() is very nasty :-)

What would be a good improvement is if you add this to the kernel command options:
"vivid.n_devs=2 vivid.multiplanar=1,2"

This will create two vivid instances, one using the single planar API and one using
the multiplanar API. That will improve the test coverage.

I also noticed that you appear to test only video devices. But vivid also creates
vbi, radio and swradio devices. It would be nice to have those tested as well.

>>> Based on this I think if we put more effort into media fuzzing, it
>>> will be able to find dozens more.
>>
>> Yeah, this is good stuff. Thank you for setting this up.
>>
>>>
>>> syzkaller needs descriptions of kernel interfaces to efficiently cover
>>> a subsystem. For example, see:
>>> https://github.com/google/syzkaller/blob/master/sys/linux/uinput.txt
>>> Hopefully you can read it without much explanation, it basically
>>> states that there is that node in /dev and here are ioctls and other
>>> syscalls that are relevant for this device and here are types of
>>> arguments and layout of involved data structures.
>>>
>>> Turned we actually have such descriptions for /dev/video* and /dev/v4l-subdev*:
>>> https://github.com/google/syzkaller/blob/master/sys/linux/video4linux.txt
>>> But we don't have anything for /dev/media*, fuzzer merely knows that
>>> it can open the device:
>>> https://github.com/google/syzkaller/blob/12b38f22c18c6109a5cc1c0238d015eef121b9b7/sys/linux/sys.txt#L479
>>> and then it will just blindly execute completely random workload on
>>> it, e.g. most likely it won't be able to come up with a proper complex
>>> structure layout for some ioctls. And I am actually not completely
>>> sure about completeness and coverage of video4linux.txt descriptions
>>> too as they were contributed by somebody interested in android
>>> testing.
>>
>> A quick look suggests that it is based on the 4.9 videodev2.h, which ain't
>> too bad. There are some differences between the 4.20 videodev2.h and the
>> 4.9, but not too many.
> 
> 
> Makes sense because the latest android use 4.9.
> Looking at the diff with 4.9 it seems that the APIs were mostly just
> extended, so we just need to extend syzkaller descriptions
> correspondingly.
> 
>>> I wonder if somebody knowledgeable in /dev/media interface be willing
>>> to contribute additional descriptions?
>>
>> We'll have to wait for 4.20-rc1 to be released since there are important
>> additions to the media API.
> 
> Additions are fine. We can extend syzkaller descriptions later too.
> But if they are already in, say, linux-next, then syzbot tests it too.
> 
> 
>> I can probably come up with something, I'm
>> just not sure when I get around to it. Ping me in three weeks time if you
>> haven't heard from me.
>>
>>>
>>> We also have code coverage reports with the coverage fuzzer achieved
>>> so far. Here in the Cover column:
>>> https://syzkaller.appspot.com/#managers
>>> e.g. this one (but note this is a ~80MB html file):
>>> https://storage.googleapis.com/syzkaller/cover/ci-upstream-kasan-gce-root.html
>>> This can be used to assess e.g. v4l coverage. But I don't know what's
>>> coverable in general from syscalls and what's coverable via the stub
>>> drivers in particular. So some expertise from media developers would
>>> be helpful too.
>>
>> The four virtual drivers should give pretty decent coverage of the core
>> code. Are you able to test with a 32-bit syzkaller application on a 64-bit
>> kernel as well? That way the compat32 code is tested.
> 
> This is coverage from 32-bit instance:
> https://storage.googleapis.com/syzkaller/cover/ci-upstream-kasan-gce-386.html
> There is some coverage in drivers/media, but I don't know where to
> look specifically. E.g. drivers/media/v4l2-core/v4l2-ioctl.c does not
> mention "compat".

It's in drivers/media/v4l2-core/v4l2-compat-ioctl32.c

BTW, is ci-upstream-kasan-gce-386.html a 64 bit kernel with 32 bit apps? Or
is it a 32-bit kernel? The latter is not very interesting.

> 
> 
>>> Do I understand it correctly that when a process opens /dev/video* or
>>> /dev/media* it gets a private instance of the device? In particular,
>>> if several processes test this in parallel, will they collide? Or they
>>> will stress separate objects?
>>
>> It actually depends on the driver. M2M devices will give you a private
>> instance whenever you open it. Others do not, but you can call most ioctls
>> in parallel. But after calling REQBUFS or CREATE_BUFS the filehandle that
>> called those ioctls becomes owner of the device until the buffers are
>> released. So other filehandles cannot do any streaming operations (EBUSY
>> will be returned).
> 
> Are the devices created by VIMC, VIM2M, VIVID, VICODEC M2M or not?
> I guess VIM2M is M2M, but what about others?

vim2m and vicodec are memory-to-memory devices. But vivid and vimc are not.

Easy to check: v4l2-ctl -D -d /dev/videoX will report Video Memory-to-Memory
capabilities.

> 
> CREATE_BUFS privatization is somewhat unfortunate, but I guess we can
> live with it for now.

Sorry, I'm not sure what you mean.

> I assume that when the process dies it will release everything at
> least, because fuzzer will sure not pair create with release all the
> time.

Correct.

Regards,

	Hans

Re: VIVID/VIMC and media fuzzing

[Dmitry Vyukov]

On Fri, Nov 9, 2018 at 6:16 AM, Hans Verkuil <hverkuil@xs4all.nl> wrote:
> Hi Dmitry,
>
> On 11/02/18 18:15, Dmitry Vyukov wrote:
>> On Wed, Oct 31, 2018 at 10:46 AM, Hans Verkuil <hverkuil@xs4all.nl> wrote:
>>> On 10/30/2018 03:02 PM, Dmitry Vyukov wrote:
>>>> Hello Helen and linux-media,
>>>>
>>>> I've attended your talk "Shifting Media App Development into High
>>>> Gear" on OSS Summit last week and approached you with some questions
>>>> if/how this can be used for kernel testing. Thanks, turn out to be a
>>>> very useful talk!
>>>>
>>>> I am working on syzkaller/syzbot, continuous kernel fuzzing system:
>>>> https://github.com/google/syzkaller
>>>> https://github.com/google/syzkaller/blob/master/docs/syzbot.md
>>>> https://syzkaller.appspot.com
>>>>
>>>> After simply enabling CONFIG_VIDEO_VIMC, CONFIG_VIDEO_VIM2M,
>>>> CONFIG_VIDEO_VIVID, CONFIG_VIDEO_VICODEC syzbot has found 8 bugs in
>>>> media subsystem in just 24 hours:
>>>>
>>>> KASAN: use-after-free Read in vb2_mmap
>>>> https://groups.google.com/forum/#!msg/syzkaller-bugs/XGGH69jMWQ0/S8vfxgEmCgAJ
>>>>
>>>> KASAN: use-after-free Write in __vb2_cleanup_fileio
>>>> https://groups.google.com/forum/#!msg/syzkaller-bugs/qKKhsZVPo3o/P6AB2of2CQAJ
>>>>
>>>> WARNING in __vb2_queue_cancel
>>>> https://groups.google.com/forum/#!msg/syzkaller-bugs/S29GU_NtfPY/ZvAz8UDtCQAJ
>>>>
>>>> divide error in vivid_vid_cap_s_dv_timings
>>>> https://groups.google.com/forum/#!msg/syzkaller-bugs/GwF5zGBCfyg/wnuWmW_sCQAJ
>>>
>>> Should be fixed by https://patchwork.linuxtv.org/patch/52641/
>>>
>>>>
>>>> KASAN: use-after-free Read in wake_up_if_idle
>>>> https://groups.google.com/forum/#!msg/syzkaller-bugs/aBWb_yV1kiI/sWQO63fkCQAJ
>>>>
>>>> KASAN: use-after-free Read in __vb2_perform_fileio
>>>> https://groups.google.com/forum/#!msg/syzkaller-bugs/MdFCZHz0LUQ/qSK_bFbcCQAJ
>>>>
>>>> INFO: task hung in vivid_stop_generating_vid_cap
>>>> https://groups.google.com/forum/#!msg/syzkaller-bugs/F_KFW6PVyTA/wTBeHLfTCQAJ
>>>>
>>>> KASAN: null-ptr-deref Write in kthread_stop
>>>> https://groups.google.com/forum/#!msg/syzkaller-bugs/u0AGnYvSlf4/fUiyfA_TCQAJ
>>>
>>> These last two should be fixed by https://patchwork.linuxtv.org/patch/52640/
>>
>> This is great!
>> This last one happens super frequently, so harms ability to find other bugs.
>>
>>> Haven't figured out the others yet (hope to get back to that next week).
>>
>> But note that syzbot added few more too! :)
>
> As of now (Fri Nov  9 14:47:31 CET 2018) I fixed all media-related syzbot
> issues with the exception of https://syzkaller.appspot.com/bug?extid=f9966a25169b6d66d61f

This is great!
I will look into that one, or maybe syzbot will come up with a repro
later. But since it happened only 2 times, it's probably either a
subtle race, or requires interaction between several test processes
(we generally try to keep them isolated, but since this is a global
device collisions are possible).

> There is no reproducer for that one and I couldn't figure out how it could
> happen.
>
> I've posted patches for all issues except for two that deal with reproducers
> using dup2(). I need to think about my fixes a bit more. dup2() is very nasty :-)
>
> What would be a good improvement is if you add this to the kernel command options:
> "vivid.n_devs=2 vivid.multiplanar=1,2"
>
> This will create two vivid instances, one using the single planar API and one using
> the multiplanar API. That will improve the test coverage.

Re this and collisions between multiple test processes. We actually
would like to have moar devices and partition them between test
processes. Say if we need need devices for 8 test processes, will it
work to specify something like "vivid.n_devs=16
vivid.multiplanar=1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2" and then use
devices 0/1 in the first test process, 2/3 in the second and so on?

Without giving any flags, I see 8 /dev/video* devices, does
vivid.n_devs defaults to 8?

> I also noticed that you appear to test only video devices. But vivid also creates
> vbi, radio and swradio devices. It would be nice to have those tested as well.

Will do.
FTR, this is these devices:

# ls -l /dev/{vbi,radio,swradio}*
crw-rw---- 1 root video 81, 14 Nov  9 21:07 /dev/radio0
crw-rw---- 1 root video 81, 15 Nov  9 21:07 /dev/radio1
crw-rw---- 1 root video 81, 13 Nov  9 21:07 /dev/swradio0
crw-rw---- 1 root video 81, 11 Nov  9 21:07 /dev/vbi0
crw-rw---- 1 root video 81, 12 Nov  9 21:07 /dev/vbi1

Why are there 2 radio and vbi? Are they different? Is it possible to
also create more of them? Are there any other useful command line args
for them?


>>>> Based on this I think if we put more effort into media fuzzing, it
>>>> will be able to find dozens more.
>>>
>>> Yeah, this is good stuff. Thank you for setting this up.
>>>
>>>>
>>>> syzkaller needs descriptions of kernel interfaces to efficiently cover
>>>> a subsystem. For example, see:
>>>> https://github.com/google/syzkaller/blob/master/sys/linux/uinput.txt
>>>> Hopefully you can read it without much explanation, it basically
>>>> states that there is that node in /dev and here are ioctls and other
>>>> syscalls that are relevant for this device and here are types of
>>>> arguments and layout of involved data structures.
>>>>
>>>> Turned we actually have such descriptions for /dev/video* and /dev/v4l-subdev*:
>>>> https://github.com/google/syzkaller/blob/master/sys/linux/video4linux.txt
>>>> But we don't have anything for /dev/media*, fuzzer merely knows that
>>>> it can open the device:
>>>> https://github.com/google/syzkaller/blob/12b38f22c18c6109a5cc1c0238d015eef121b9b7/sys/linux/sys.txt#L479
>>>> and then it will just blindly execute completely random workload on
>>>> it, e.g. most likely it won't be able to come up with a proper complex
>>>> structure layout for some ioctls. And I am actually not completely
>>>> sure about completeness and coverage of video4linux.txt descriptions
>>>> too as they were contributed by somebody interested in android
>>>> testing.
>>>
>>> A quick look suggests that it is based on the 4.9 videodev2.h, which ain't
>>> too bad. There are some differences between the 4.20 videodev2.h and the
>>> 4.9, but not too many.
>>
>>
>> Makes sense because the latest android use 4.9.
>> Looking at the diff with 4.9 it seems that the APIs were mostly just
>> extended, so we just need to extend syzkaller descriptions
>> correspondingly.
>>
>>>> I wonder if somebody knowledgeable in /dev/media interface be willing
>>>> to contribute additional descriptions?
>>>
>>> We'll have to wait for 4.20-rc1 to be released since there are important
>>> additions to the media API.
>>
>> Additions are fine. We can extend syzkaller descriptions later too.
>> But if they are already in, say, linux-next, then syzbot tests it too.
>>
>>
>>> I can probably come up with something, I'm
>>> just not sure when I get around to it. Ping me in three weeks time if you
>>> haven't heard from me.
>>>
>>>>
>>>> We also have code coverage reports with the coverage fuzzer achieved
>>>> so far. Here in the Cover column:
>>>> https://syzkaller.appspot.com/#managers
>>>> e.g. this one (but note this is a ~80MB html file):
>>>> https://storage.googleapis.com/syzkaller/cover/ci-upstream-kasan-gce-root.html
>>>> This can be used to assess e.g. v4l coverage. But I don't know what's
>>>> coverable in general from syscalls and what's coverable via the stub
>>>> drivers in particular. So some expertise from media developers would
>>>> be helpful too.
>>>
>>> The four virtual drivers should give pretty decent coverage of the core
>>> code. Are you able to test with a 32-bit syzkaller application on a 64-bit
>>> kernel as well? That way the compat32 code is tested.
>>
>> This is coverage from 32-bit instance:
>> https://storage.googleapis.com/syzkaller/cover/ci-upstream-kasan-gce-386.html
>> There is some coverage in drivers/media, but I don't know where to
>> look specifically. E.g. drivers/media/v4l2-core/v4l2-ioctl.c does not
>> mention "compat".
>
> It's in drivers/media/v4l2-core/v4l2-compat-ioctl32.c
>
> BTW, is ci-upstream-kasan-gce-386.html a 64 bit kernel with 32 bit apps? Or
> is it a 32-bit kernel? The latter is not very interesting.

Yes, it's 64-bit kernel and 32-bit app. Yet to find anybody who would
be interested in 32-bit x86 kernel today :)


>>>> Do I understand it correctly that when a process opens /dev/video* or
>>>> /dev/media* it gets a private instance of the device? In particular,
>>>> if several processes test this in parallel, will they collide? Or they
>>>> will stress separate objects?
>>>
>>> It actually depends on the driver. M2M devices will give you a private
>>> instance whenever you open it. Others do not, but you can call most ioctls
>>> in parallel. But after calling REQBUFS or CREATE_BUFS the filehandle that
>>> called those ioctls becomes owner of the device until the buffers are
>>> released. So other filehandles cannot do any streaming operations (EBUSY
>>> will be returned).
>>
>> Are the devices created by VIMC, VIM2M, VIVID, VICODEC M2M or not?
>> I guess VIM2M is M2M, but what about others?
>
> vim2m and vicodec are memory-to-memory devices. But vivid and vimc are not.
>
> Easy to check: v4l2-ctl -D -d /dev/videoX will report Video Memory-to-Memory
> capabilities.
>
>>
>> CREATE_BUFS privatization is somewhat unfortunate, but I guess we can
>> live with it for now.
>
> Sorry, I'm not sure what you mean.

You said:

>> But after calling REQBUFS or CREATE_BUFS the filehandle that
>> called those ioctls becomes owner of the device until the buffers are
>> released. So other filehandles cannot do any streaming operations (EBUSY
>> will be returned).

This semantics are somewhat unfortunate for syzkaller because one test
process will affect/block other test processes, and we try to make
them as independent as possible. E.g. If this can affect syzkaller
ability to create reproducers, because in one run of a test if was
affected by an unrelated test and crashed, but if we try to reproduce
the crash on the same test it won't crash again because now it's not
affected by the unrelated test.

But if we create more devices and partition them across test
processes, it will resolve this problem?


>> I assume that when the process dies it will release everything at
>> least, because fuzzer will sure not pair create with release all the
>> time.

Re: VIVID/VIMC and media fuzzing

[Dmitry Vyukov]

On Fri, Nov 9, 2018 at 1:17 PM, Dmitry Vyukov <dvyukov@google.com> wrote:
> On Fri, Nov 9, 2018 at 6:16 AM, Hans Verkuil <hverkuil@xs4all.nl> wrote:
>> Hi Dmitry,
>>
>> On 11/02/18 18:15, Dmitry Vyukov wrote:
>>> On Wed, Oct 31, 2018 at 10:46 AM, Hans Verkuil <hverkuil@xs4all.nl> wrote:
>>>> On 10/30/2018 03:02 PM, Dmitry Vyukov wrote:
>>>>> Hello Helen and linux-media,
>>>>>
>>>>> I've attended your talk "Shifting Media App Development into High
>>>>> Gear" on OSS Summit last week and approached you with some questions
>>>>> if/how this can be used for kernel testing. Thanks, turn out to be a
>>>>> very useful talk!
>>>>>
>>>>> I am working on syzkaller/syzbot, continuous kernel fuzzing system:
>>>>> https://github.com/google/syzkaller
>>>>> https://github.com/google/syzkaller/blob/master/docs/syzbot.md
>>>>> https://syzkaller.appspot.com
>>>>>
>>>>> After simply enabling CONFIG_VIDEO_VIMC, CONFIG_VIDEO_VIM2M,
>>>>> CONFIG_VIDEO_VIVID, CONFIG_VIDEO_VICODEC syzbot has found 8 bugs in
>>>>> media subsystem in just 24 hours:
>>>>>
>>>>> KASAN: use-after-free Read in vb2_mmap
>>>>> https://groups.google.com/forum/#!msg/syzkaller-bugs/XGGH69jMWQ0/S8vfxgEmCgAJ
>>>>>
>>>>> KASAN: use-after-free Write in __vb2_cleanup_fileio
>>>>> https://groups.google.com/forum/#!msg/syzkaller-bugs/qKKhsZVPo3o/P6AB2of2CQAJ
>>>>>
>>>>> WARNING in __vb2_queue_cancel
>>>>> https://groups.google.com/forum/#!msg/syzkaller-bugs/S29GU_NtfPY/ZvAz8UDtCQAJ
>>>>>
>>>>> divide error in vivid_vid_cap_s_dv_timings
>>>>> https://groups.google.com/forum/#!msg/syzkaller-bugs/GwF5zGBCfyg/wnuWmW_sCQAJ
>>>>
>>>> Should be fixed by https://patchwork.linuxtv.org/patch/52641/
>>>>
>>>>>
>>>>> KASAN: use-after-free Read in wake_up_if_idle
>>>>> https://groups.google.com/forum/#!msg/syzkaller-bugs/aBWb_yV1kiI/sWQO63fkCQAJ
>>>>>
>>>>> KASAN: use-after-free Read in __vb2_perform_fileio
>>>>> https://groups.google.com/forum/#!msg/syzkaller-bugs/MdFCZHz0LUQ/qSK_bFbcCQAJ
>>>>>
>>>>> INFO: task hung in vivid_stop_generating_vid_cap
>>>>> https://groups.google.com/forum/#!msg/syzkaller-bugs/F_KFW6PVyTA/wTBeHLfTCQAJ
>>>>>
>>>>> KASAN: null-ptr-deref Write in kthread_stop
>>>>> https://groups.google.com/forum/#!msg/syzkaller-bugs/u0AGnYvSlf4/fUiyfA_TCQAJ
>>>>
>>>> These last two should be fixed by https://patchwork.linuxtv.org/patch/52640/
>>>
>>> This is great!
>>> This last one happens super frequently, so harms ability to find other bugs.
>>>
>>>> Haven't figured out the others yet (hope to get back to that next week).
>>>
>>> But note that syzbot added few more too! :)
>>
>> As of now (Fri Nov  9 14:47:31 CET 2018) I fixed all media-related syzbot
>> issues with the exception of https://syzkaller.appspot.com/bug?extid=f9966a25169b6d66d61f
>
> This is great!
> I will look into that one, or maybe syzbot will come up with a repro
> later. But since it happened only 2 times, it's probably either a
> subtle race, or requires interaction between several test processes
> (we generally try to keep them isolated, but since this is a global
> device collisions are possible).
>
>> There is no reproducer for that one and I couldn't figure out how it could
>> happen.
>>
>> I've posted patches for all issues except for two that deal with reproducers
>> using dup2(). I need to think about my fixes a bit more. dup2() is very nasty :-)
>>
>> What would be a good improvement is if you add this to the kernel command options:
>> "vivid.n_devs=2 vivid.multiplanar=1,2"
>>
>> This will create two vivid instances, one using the single planar API and one using
>> the multiplanar API. That will improve the test coverage.
>
> Re this and collisions between multiple test processes. We actually
> would like to have moar devices and partition them between test
> processes. Say if we need need devices for 8 test processes, will it
> work to specify something like "vivid.n_devs=16
> vivid.multiplanar=1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2" and then use
> devices 0/1 in the first test process, 2/3 in the second and so on?
>
> Without giving any flags, I see 8 /dev/video* devices, does
> vivid.n_devs defaults to 8?

I am a bit lost.

vivid.n_devs=16 vivid.multiplanar=1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2
creates 32 /dev/video* devices.

but vivid.n_devs=8 vivid.multiplanar=1,2,1,2,1,2,1,2 creates 24
/dev/video* devices.

These parameters also affect /dev/{vbi,radio,swradio} in strange ways

Also, by default there is /dev/radio0 and /dev/radio1, are these
different types of devices, e.g. "source" and "sink"? Or they are
identical? And the same question for other types of devices?

How can I create 8 independent partitions of devices? What devices
will belong to each partition?


>> I also noticed that you appear to test only video devices. But vivid also creates
>> vbi, radio and swradio devices. It would be nice to have those tested as well.
>
> Will do.
> FTR, this is these devices:
>
> # ls -l /dev/{vbi,radio,swradio}*
> crw-rw---- 1 root video 81, 14 Nov  9 21:07 /dev/radio0
> crw-rw---- 1 root video 81, 15 Nov  9 21:07 /dev/radio1
> crw-rw---- 1 root video 81, 13 Nov  9 21:07 /dev/swradio0
> crw-rw---- 1 root video 81, 11 Nov  9 21:07 /dev/vbi0
> crw-rw---- 1 root video 81, 12 Nov  9 21:07 /dev/vbi1
>
> Why are there 2 radio and vbi? Are they different? Is it possible to
> also create more of them? Are there any other useful command line args
> for them?
>
>
>>>>> Based on this I think if we put more effort into media fuzzing, it
>>>>> will be able to find dozens more.
>>>>
>>>> Yeah, this is good stuff. Thank you for setting this up.
>>>>
>>>>>
>>>>> syzkaller needs descriptions of kernel interfaces to efficiently cover
>>>>> a subsystem. For example, see:
>>>>> https://github.com/google/syzkaller/blob/master/sys/linux/uinput.txt
>>>>> Hopefully you can read it without much explanation, it basically
>>>>> states that there is that node in /dev and here are ioctls and other
>>>>> syscalls that are relevant for this device and here are types of
>>>>> arguments and layout of involved data structures.
>>>>>
>>>>> Turned we actually have such descriptions for /dev/video* and /dev/v4l-subdev*:
>>>>> https://github.com/google/syzkaller/blob/master/sys/linux/video4linux.txt
>>>>> But we don't have anything for /dev/media*, fuzzer merely knows that
>>>>> it can open the device:
>>>>> https://github.com/google/syzkaller/blob/12b38f22c18c6109a5cc1c0238d015eef121b9b7/sys/linux/sys.txt#L479
>>>>> and then it will just blindly execute completely random workload on
>>>>> it, e.g. most likely it won't be able to come up with a proper complex
>>>>> structure layout for some ioctls. And I am actually not completely
>>>>> sure about completeness and coverage of video4linux.txt descriptions
>>>>> too as they were contributed by somebody interested in android
>>>>> testing.
>>>>
>>>> A quick look suggests that it is based on the 4.9 videodev2.h, which ain't
>>>> too bad. There are some differences between the 4.20 videodev2.h and the
>>>> 4.9, but not too many.
>>>
>>>
>>> Makes sense because the latest android use 4.9.
>>> Looking at the diff with 4.9 it seems that the APIs were mostly just
>>> extended, so we just need to extend syzkaller descriptions
>>> correspondingly.
>>>
>>>>> I wonder if somebody knowledgeable in /dev/media interface be willing
>>>>> to contribute additional descriptions?
>>>>
>>>> We'll have to wait for 4.20-rc1 to be released since there are important
>>>> additions to the media API.
>>>
>>> Additions are fine. We can extend syzkaller descriptions later too.
>>> But if they are already in, say, linux-next, then syzbot tests it too.
>>>
>>>
>>>> I can probably come up with something, I'm
>>>> just not sure when I get around to it. Ping me in three weeks time if you
>>>> haven't heard from me.
>>>>
>>>>>
>>>>> We also have code coverage reports with the coverage fuzzer achieved
>>>>> so far. Here in the Cover column:
>>>>> https://syzkaller.appspot.com/#managers
>>>>> e.g. this one (but note this is a ~80MB html file):
>>>>> https://storage.googleapis.com/syzkaller/cover/ci-upstream-kasan-gce-root.html
>>>>> This can be used to assess e.g. v4l coverage. But I don't know what's
>>>>> coverable in general from syscalls and what's coverable via the stub
>>>>> drivers in particular. So some expertise from media developers would
>>>>> be helpful too.
>>>>
>>>> The four virtual drivers should give pretty decent coverage of the core
>>>> code. Are you able to test with a 32-bit syzkaller application on a 64-bit
>>>> kernel as well? That way the compat32 code is tested.
>>>
>>> This is coverage from 32-bit instance:
>>> https://storage.googleapis.com/syzkaller/cover/ci-upstream-kasan-gce-386.html
>>> There is some coverage in drivers/media, but I don't know where to
>>> look specifically. E.g. drivers/media/v4l2-core/v4l2-ioctl.c does not
>>> mention "compat".
>>
>> It's in drivers/media/v4l2-core/v4l2-compat-ioctl32.c
>>
>> BTW, is ci-upstream-kasan-gce-386.html a 64 bit kernel with 32 bit apps? Or
>> is it a 32-bit kernel? The latter is not very interesting.
>
> Yes, it's 64-bit kernel and 32-bit app. Yet to find anybody who would
> be interested in 32-bit x86 kernel today :)
>
>
>>>>> Do I understand it correctly that when a process opens /dev/video* or
>>>>> /dev/media* it gets a private instance of the device? In particular,
>>>>> if several processes test this in parallel, will they collide? Or they
>>>>> will stress separate objects?
>>>>
>>>> It actually depends on the driver. M2M devices will give you a private
>>>> instance whenever you open it. Others do not, but you can call most ioctls
>>>> in parallel. But after calling REQBUFS or CREATE_BUFS the filehandle that
>>>> called those ioctls becomes owner of the device until the buffers are
>>>> released. So other filehandles cannot do any streaming operations (EBUSY
>>>> will be returned).
>>>
>>> Are the devices created by VIMC, VIM2M, VIVID, VICODEC M2M or not?
>>> I guess VIM2M is M2M, but what about others?
>>
>> vim2m and vicodec are memory-to-memory devices. But vivid and vimc are not.
>>
>> Easy to check: v4l2-ctl -D -d /dev/videoX will report Video Memory-to-Memory
>> capabilities.
>>
>>>
>>> CREATE_BUFS privatization is somewhat unfortunate, but I guess we can
>>> live with it for now.
>>
>> Sorry, I'm not sure what you mean.
>
> You said:
>
>>> But after calling REQBUFS or CREATE_BUFS the filehandle that
>>> called those ioctls becomes owner of the device until the buffers are
>>> released. So other filehandles cannot do any streaming operations (EBUSY
>>> will be returned).
>
> This semantics are somewhat unfortunate for syzkaller because one test
> process will affect/block other test processes, and we try to make
> them as independent as possible. E.g. If this can affect syzkaller
> ability to create reproducers, because in one run of a test if was
> affected by an unrelated test and crashed, but if we try to reproduce
> the crash on the same test it won't crash again because now it's not
> affected by the unrelated test.
>
> But if we create more devices and partition them across test
> processes, it will resolve this problem?
>
>
>>> I assume that when the process dies it will release everything at
>>> least, because fuzzer will sure not pair create with release all the
>>> time.

Re: VIVID/VIMC and media fuzzing

[Hans Verkuil]

On 11/09/2018 10:34 PM, Dmitry Vyukov wrote:
>>> What would be a good improvement is if you add this to the kernel command options:
>>> "vivid.n_devs=2 vivid.multiplanar=1,2"
>>>
>>> This will create two vivid instances, one using the single planar API and one using
>>> the multiplanar API. That will improve the test coverage.
>>
>> Re this and collisions between multiple test processes. We actually
>> would like to have moar devices and partition them between test
>> processes. Say if we need need devices for 8 test processes, will it
>> work to specify something like "vivid.n_devs=16
>> vivid.multiplanar=1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2" and then use
>> devices 0/1 in the first test process, 2/3 in the second and so on?
>>
>> Without giving any flags, I see 8 /dev/video* devices, does
>> vivid.n_devs defaults to 8?
> 
> I am a bit lost.
> 
> vivid.n_devs=16 vivid.multiplanar=1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2
> creates 32 /dev/video* devices.

I see 38 /dev/video* devices: the first 3 are from vimc, then 2 * 16 = 32
vivid devices (2 video nodes for each instance), then a vim2m device and
finally two vicodec devices.

So you should always see 6 + n_devs * 2 video devices.

> 
> but vivid.n_devs=8 vivid.multiplanar=1,2,1,2,1,2,1,2 creates 24
> /dev/video* devices.
> 
> These parameters also affect /dev/{vbi,radio,swradio} in strange ways
> 
> Also, by default there is /dev/radio0 and /dev/radio1, are these
> different types of devices, e.g. "source" and "sink"? Or they are
> identical? And the same question for other types of devices?

vivid creates two radio devices per instance: one emulates a radio tuner,
one emulates a radio modulator (so yes, source and sink). Same for vbi
(one source, one sink) and one swradio device. It also creates two cec
devices (source and sink).

> 
> How can I create 8 independent partitions of devices? What devices
> will belong to each partition?

Exactly as you did above. Instance X (starting at 0) uses video nodes
3+2*X and 4+2*X.

> 
> 
>>> I also noticed that you appear to test only video devices. But vivid also creates
>>> vbi, radio and swradio devices. It would be nice to have those tested as well.
>>
>> Will do.
>> FTR, this is these devices:
>>
>> # ls -l /dev/{vbi,radio,swradio}*
>> crw-rw---- 1 root video 81, 14 Nov  9 21:07 /dev/radio0
>> crw-rw---- 1 root video 81, 15 Nov  9 21:07 /dev/radio1
>> crw-rw---- 1 root video 81, 13 Nov  9 21:07 /dev/swradio0
>> crw-rw---- 1 root video 81, 11 Nov  9 21:07 /dev/vbi0
>> crw-rw---- 1 root video 81, 12 Nov  9 21:07 /dev/vbi1
>>
>> Why are there 2 radio and vbi? Are they different? Is it possible to
>> also create more of them? Are there any other useful command line args
>> for them?

As mentioned: the first is capture, the second output. It's per vivid
instance.

<snip>

>>>> CREATE_BUFS privatization is somewhat unfortunate, but I guess we can
>>>> live with it for now.
>>>
>>> Sorry, I'm not sure what you mean.
>>
>> You said:
>>
>>>> But after calling REQBUFS or CREATE_BUFS the filehandle that
>>>> called those ioctls becomes owner of the device until the buffers are
>>>> released. So other filehandles cannot do any streaming operations (EBUSY
>>>> will be returned).
>>
>> This semantics are somewhat unfortunate for syzkaller because one test
>> process will affect/block other test processes, and we try to make
>> them as independent as possible. E.g. If this can affect syzkaller
>> ability to create reproducers, because in one run of a test if was
>> affected by an unrelated test and crashed, but if we try to reproduce
>> the crash on the same test it won't crash again because now it's not
>> affected by the unrelated test.
>>
>> But if we create more devices and partition them across test
>> processes, it will resolve this problem?

I think it will help, yes.

>>
>>
>>>> I assume that when the process dies it will release everything at
>>>> least, because fuzzer will sure not pair create with release all the
>>>> time.

Re: VIVID/VIMC and media fuzzing

[Dmitry Vyukov]

On Sat, Nov 10, 2018 at 2:01 AM, Hans Verkuil <hverkuil@xs4all.nl> wrote:
> On 11/09/2018 10:34 PM, Dmitry Vyukov wrote:
>>>> What would be a good improvement is if you add this to the kernel command options:
>>>> "vivid.n_devs=2 vivid.multiplanar=1,2"
>>>>
>>>> This will create two vivid instances, one using the single planar API and one using
>>>> the multiplanar API. That will improve the test coverage.
>>>
>>> Re this and collisions between multiple test processes. We actually
>>> would like to have moar devices and partition them between test
>>> processes. Say if we need need devices for 8 test processes, will it
>>> work to specify something like "vivid.n_devs=16
>>> vivid.multiplanar=1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2" and then use
>>> devices 0/1 in the first test process, 2/3 in the second and so on?
>>>
>>> Without giving any flags, I see 8 /dev/video* devices, does
>>> vivid.n_devs defaults to 8?
>>
>> I am a bit lost.
>>
>> vivid.n_devs=16 vivid.multiplanar=1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2
>> creates 32 /dev/video* devices.
>
> I see 38 /dev/video* devices: the first 3 are from vimc, then 2 * 16 = 32
> vivid devices (2 video nodes for each instance), then a vim2m device and
> finally two vicodec devices.
>
> So you should always see 6 + n_devs * 2 video devices.
>
>>
>> but vivid.n_devs=8 vivid.multiplanar=1,2,1,2,1,2,1,2 creates 24
>> /dev/video* devices.
>>
>> These parameters also affect /dev/{vbi,radio,swradio} in strange ways
>>
>> Also, by default there is /dev/radio0 and /dev/radio1, are these
>> different types of devices, e.g. "source" and "sink"? Or they are
>> identical? And the same question for other types of devices?
>
> vivid creates two radio devices per instance: one emulates a radio tuner,
> one emulates a radio modulator (so yes, source and sink). Same for vbi
> (one source, one sink) and one swradio device. It also creates two cec
> devices (source and sink).
>
>>
>> How can I create 8 independent partitions of devices? What devices
>> will belong to each partition?
>
> Exactly as you did above. Instance X (starting at 0) uses video nodes
> 3+2*X and 4+2*X.

Thanks! Now I got it.
I've extended syzkaller to create more devices, use planar/non-planar,
radio, swradio, cec, vbi:

https://github.com/google/syzkaller/commit/f3c4e6185953baea53d5651b84bd5897c02627f4#diff-a6fc2c4d3df5a6bcb42a628db614175f

https://github.com/google/syzkaller/commit/f3c4e6185953baea53d5651b84bd5897c02627f4#diff-c60ec5d4add9b876f5d28fdeeaf3b7b8


>>>> I also noticed that you appear to test only video devices. But vivid also creates
>>>> vbi, radio and swradio devices. It would be nice to have those tested as well.
>>>
>>> Will do.
>>> FTR, this is these devices:
>>>
>>> # ls -l /dev/{vbi,radio,swradio}*
>>> crw-rw---- 1 root video 81, 14 Nov  9 21:07 /dev/radio0
>>> crw-rw---- 1 root video 81, 15 Nov  9 21:07 /dev/radio1
>>> crw-rw---- 1 root video 81, 13 Nov  9 21:07 /dev/swradio0
>>> crw-rw---- 1 root video 81, 11 Nov  9 21:07 /dev/vbi0
>>> crw-rw---- 1 root video 81, 12 Nov  9 21:07 /dev/vbi1
>>>
>>> Why are there 2 radio and vbi? Are they different? Is it possible to
>>> also create more of them? Are there any other useful command line args
>>> for them?
>
> As mentioned: the first is capture, the second output. It's per vivid
> instance.
>
> <snip>
>
>>>>> CREATE_BUFS privatization is somewhat unfortunate, but I guess we can
>>>>> live with it for now.
>>>>
>>>> Sorry, I'm not sure what you mean.
>>>
>>> You said:
>>>
>>>>> But after calling REQBUFS or CREATE_BUFS the filehandle that
>>>>> called those ioctls becomes owner of the device until the buffers are
>>>>> released. So other filehandles cannot do any streaming operations (EBUSY
>>>>> will be returned).
>>>
>>> This semantics are somewhat unfortunate for syzkaller because one test
>>> process will affect/block other test processes, and we try to make
>>> them as independent as possible. E.g. If this can affect syzkaller
>>> ability to create reproducers, because in one run of a test if was
>>> affected by an unrelated test and crashed, but if we try to reproduce
>>> the crash on the same test it won't crash again because now it's not
>>> affected by the unrelated test.
>>>
>>> But if we create more devices and partition them across test
>>> processes, it will resolve this problem?
>
> I think it will help, yes.
>
>>>
>>>
>>>>> I assume that when the process dies it will release everything at
>>>>> least, because fuzzer will sure not pair create with release all the
>>>>> time.
>
> --
> You received this message because you are subscribed to the Google Groups "syzkaller" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to syzkaller+unsubscribe@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

Re: VIVID/VIMC and media fuzzing

[Hans Verkuil]

On 11/10/2018 08:28 PM, Dmitry Vyukov wrote:
> On Sat, Nov 10, 2018 at 2:01 AM, Hans Verkuil <hverkuil@xs4all.nl> wrote:
>> On 11/09/2018 10:34 PM, Dmitry Vyukov wrote:
>>>>> What would be a good improvement is if you add this to the kernel command options:
>>>>> "vivid.n_devs=2 vivid.multiplanar=1,2"
>>>>>
>>>>> This will create two vivid instances, one using the single planar API and one using
>>>>> the multiplanar API. That will improve the test coverage.
>>>>
>>>> Re this and collisions between multiple test processes. We actually
>>>> would like to have moar devices and partition them between test
>>>> processes. Say if we need need devices for 8 test processes, will it
>>>> work to specify something like "vivid.n_devs=16
>>>> vivid.multiplanar=1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2" and then use
>>>> devices 0/1 in the first test process, 2/3 in the second and so on?
>>>>
>>>> Without giving any flags, I see 8 /dev/video* devices, does
>>>> vivid.n_devs defaults to 8?
>>>
>>> I am a bit lost.
>>>
>>> vivid.n_devs=16 vivid.multiplanar=1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2
>>> creates 32 /dev/video* devices.
>>
>> I see 38 /dev/video* devices: the first 3 are from vimc, then 2 * 16 = 32
>> vivid devices (2 video nodes for each instance), then a vim2m device and
>> finally two vicodec devices.
>>
>> So you should always see 6 + n_devs * 2 video devices.
>>
>>>
>>> but vivid.n_devs=8 vivid.multiplanar=1,2,1,2,1,2,1,2 creates 24
>>> /dev/video* devices.
>>>
>>> These parameters also affect /dev/{vbi,radio,swradio} in strange ways
>>>
>>> Also, by default there is /dev/radio0 and /dev/radio1, are these
>>> different types of devices, e.g. "source" and "sink"? Or they are
>>> identical? And the same question for other types of devices?
>>
>> vivid creates two radio devices per instance: one emulates a radio tuner,
>> one emulates a radio modulator (so yes, source and sink). Same for vbi
>> (one source, one sink) and one swradio device. It also creates two cec
>> devices (source and sink).
>>
>>>
>>> How can I create 8 independent partitions of devices? What devices
>>> will belong to each partition?
>>
>> Exactly as you did above. Instance X (starting at 0) uses video nodes
>> 3+2*X and 4+2*X.
> 
> Thanks! Now I got it.
> I've extended syzkaller to create more devices, use planar/non-planar,
> radio, swradio, cec, vbi:
> 
> https://github.com/google/syzkaller/commit/f3c4e6185953baea53d5651b84bd5897c02627f4#diff-a6fc2c4d3df5a6bcb42a628db614175f
> 
> https://github.com/google/syzkaller/commit/f3c4e6185953baea53d5651b84bd5897c02627f4#diff-c60ec5d4add9b876f5d28fdeeaf3b7b8

The cec devices do not use the V4L2 API, so it might be premature to add those.

I plan on providing a patch for CEC in the near (?) future. Do you happen to
have a script or something that can convert an API header to something that
syzkaller needs? Or is it all manual?

Regards,

	Hans

> 
> 
>>>>> I also noticed that you appear to test only video devices. But vivid also creates
>>>>> vbi, radio and swradio devices. It would be nice to have those tested as well.
>>>>
>>>> Will do.
>>>> FTR, this is these devices:
>>>>
>>>> # ls -l /dev/{vbi,radio,swradio}*
>>>> crw-rw---- 1 root video 81, 14 Nov  9 21:07 /dev/radio0
>>>> crw-rw---- 1 root video 81, 15 Nov  9 21:07 /dev/radio1
>>>> crw-rw---- 1 root video 81, 13 Nov  9 21:07 /dev/swradio0
>>>> crw-rw---- 1 root video 81, 11 Nov  9 21:07 /dev/vbi0
>>>> crw-rw---- 1 root video 81, 12 Nov  9 21:07 /dev/vbi1
>>>>
>>>> Why are there 2 radio and vbi? Are they different? Is it possible to
>>>> also create more of them? Are there any other useful command line args
>>>> for them?
>>
>> As mentioned: the first is capture, the second output. It's per vivid
>> instance.
>>
>> <snip>
>>
>>>>>> CREATE_BUFS privatization is somewhat unfortunate, but I guess we can
>>>>>> live with it for now.
>>>>>
>>>>> Sorry, I'm not sure what you mean.
>>>>
>>>> You said:
>>>>
>>>>>> But after calling REQBUFS or CREATE_BUFS the filehandle that
>>>>>> called those ioctls becomes owner of the device until the buffers are
>>>>>> released. So other filehandles cannot do any streaming operations (EBUSY
>>>>>> will be returned).
>>>>
>>>> This semantics are somewhat unfortunate for syzkaller because one test
>>>> process will affect/block other test processes, and we try to make
>>>> them as independent as possible. E.g. If this can affect syzkaller
>>>> ability to create reproducers, because in one run of a test if was
>>>> affected by an unrelated test and crashed, but if we try to reproduce
>>>> the crash on the same test it won't crash again because now it's not
>>>> affected by the unrelated test.
>>>>
>>>> But if we create more devices and partition them across test
>>>> processes, it will resolve this problem?
>>
>> I think it will help, yes.
>>
>>>>
>>>>
>>>>>> I assume that when the process dies it will release everything at
>>>>>> least, because fuzzer will sure not pair create with release all the
>>>>>> time.
>>
>> --
>> You received this message because you are subscribed to the Google Groups "syzkaller" group.
>> To unsubscribe from this group and stop receiving emails from it, send an email to syzkaller+unsubscribe@googlegroups.com.
>> For more options, visit https://groups.google.com/d/optout.

Re: VIVID/VIMC and media fuzzing

[Dmitry Vyukov]

On Mon, Nov 12, 2018 at 7:11 AM, Hans Verkuil <hverkuil@xs4all.nl> wrote:
>>>>>> What would be a good improvement is if you add this to the kernel command options:
>>>>>> "vivid.n_devs=2 vivid.multiplanar=1,2"
>>>>>>
>>>>>> This will create two vivid instances, one using the single planar API and one using
>>>>>> the multiplanar API. That will improve the test coverage.
>>>>>
>>>>> Re this and collisions between multiple test processes. We actually
>>>>> would like to have moar devices and partition them between test
>>>>> processes. Say if we need need devices for 8 test processes, will it
>>>>> work to specify something like "vivid.n_devs=16
>>>>> vivid.multiplanar=1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2" and then use
>>>>> devices 0/1 in the first test process, 2/3 in the second and so on?
>>>>>
>>>>> Without giving any flags, I see 8 /dev/video* devices, does
>>>>> vivid.n_devs defaults to 8?
>>>>
>>>> I am a bit lost.
>>>>
>>>> vivid.n_devs=16 vivid.multiplanar=1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2
>>>> creates 32 /dev/video* devices.
>>>
>>> I see 38 /dev/video* devices: the first 3 are from vimc, then 2 * 16 = 32
>>> vivid devices (2 video nodes for each instance), then a vim2m device and
>>> finally two vicodec devices.
>>>
>>> So you should always see 6 + n_devs * 2 video devices.
>>>
>>>>
>>>> but vivid.n_devs=8 vivid.multiplanar=1,2,1,2,1,2,1,2 creates 24
>>>> /dev/video* devices.
>>>>
>>>> These parameters also affect /dev/{vbi,radio,swradio} in strange ways
>>>>
>>>> Also, by default there is /dev/radio0 and /dev/radio1, are these
>>>> different types of devices, e.g. "source" and "sink"? Or they are
>>>> identical? And the same question for other types of devices?
>>>
>>> vivid creates two radio devices per instance: one emulates a radio tuner,
>>> one emulates a radio modulator (so yes, source and sink). Same for vbi
>>> (one source, one sink) and one swradio device. It also creates two cec
>>> devices (source and sink).
>>>
>>>>
>>>> How can I create 8 independent partitions of devices? What devices
>>>> will belong to each partition?
>>>
>>> Exactly as you did above. Instance X (starting at 0) uses video nodes
>>> 3+2*X and 4+2*X.
>>
>> Thanks! Now I got it.
>> I've extended syzkaller to create more devices, use planar/non-planar,
>> radio, swradio, cec, vbi:
>>
>> https://github.com/google/syzkaller/commit/f3c4e6185953baea53d5651b84bd5897c02627f4#diff-a6fc2c4d3df5a6bcb42a628db614175f
>>
>> https://github.com/google/syzkaller/commit/f3c4e6185953baea53d5651b84bd5897c02627f4#diff-c60ec5d4add9b876f5d28fdeeaf3b7b8
>
> The cec devices do not use the V4L2 API, so it might be premature to add those.

It won't harm either. Fuzzer will still be able to call some
completely random stuff on them. It also serves as a reminded that
this is something we want to give to fuzzer, but don't have more
detailed descriptions.

> I plan on providing a patch for CEC in the near (?) future. Do you happen to
> have a script or something that can convert an API header to something that
> syzkaller needs? Or is it all manual?

It's manual at the moment.
We want to create some kind of helper thing that would at least
provide a skeleton. But in the end manual work is required anyway. For
example, there is an int field, is it just an int, or an fd, or some
set of flags, or something else? If there is a string, what are the
expected values? Etc. This information is simply not in the existing
kernel headers.

Re: VIVID/VIMC and media fuzzing

[Helen Koike]

Hi Dmitry,

On 10/31/18 9:49 AM, Helen Koike wrote:
> Hi Dmitry,
> 
> On 10/31/18 7:46 AM, Hans Verkuil wrote:
>> On 10/30/2018 03:02 PM, Dmitry Vyukov wrote:
>>> Hello Helen and linux-media,
>>>
>>> I've attended your talk "Shifting Media App Development into High
>>> Gear" on OSS Summit last week and approached you with some questions
>>> if/how this can be used for kernel testing. Thanks, turn out to be a
>>> very useful talk!
> 
> Great, I am  glad it was useful :)
> 
>>>
>>> I am working on syzkaller/syzbot, continuous kernel fuzzing system:
>>> https://github.com/google/syzkaller
>>> https://github.com/google/syzkaller/blob/master/docs/syzbot.md
>>> https://syzkaller.appspot.com
>>>
>>> After simply enabling CONFIG_VIDEO_VIMC, CONFIG_VIDEO_VIM2M,
>>> CONFIG_VIDEO_VIVID, CONFIG_VIDEO_VICODEC syzbot has found 8 bugs in
>>> media subsystem in just 24 hours:
>>>
>>> KASAN: use-after-free Read in vb2_mmap
>>> https://groups.google.com/forum/#!msg/syzkaller-bugs/XGGH69jMWQ0/S8vfxgEmCgAJ
>>>
>>> KASAN: use-after-free Write in __vb2_cleanup_fileio
>>> https://groups.google.com/forum/#!msg/syzkaller-bugs/qKKhsZVPo3o/P6AB2of2CQAJ
>>>
>>> WARNING in __vb2_queue_cancel
>>> https://groups.google.com/forum/#!msg/syzkaller-bugs/S29GU_NtfPY/ZvAz8UDtCQAJ
>>>
>>> divide error in vivid_vid_cap_s_dv_timings
>>> https://groups.google.com/forum/#!msg/syzkaller-bugs/GwF5zGBCfyg/wnuWmW_sCQAJ
>>
>> Should be fixed by https://patchwork.linuxtv.org/patch/52641/
>>
>>>
>>> KASAN: use-after-free Read in wake_up_if_idle
>>> https://groups.google.com/forum/#!msg/syzkaller-bugs/aBWb_yV1kiI/sWQO63fkCQAJ
>>>
>>> KASAN: use-after-free Read in __vb2_perform_fileio
>>> https://groups.google.com/forum/#!msg/syzkaller-bugs/MdFCZHz0LUQ/qSK_bFbcCQAJ
>>>
>>> INFO: task hung in vivid_stop_generating_vid_cap
>>> https://groups.google.com/forum/#!msg/syzkaller-bugs/F_KFW6PVyTA/wTBeHLfTCQAJ
>>>
>>> KASAN: null-ptr-deref Write in kthread_stop
>>> https://groups.google.com/forum/#!msg/syzkaller-bugs/u0AGnYvSlf4/fUiyfA_TCQAJ
>>
>> These last two should be fixed by https://patchwork.linuxtv.org/patch/52640/
>>
>> Haven't figured out the others yet (hope to get back to that next week).
>>
>>>
>>> Based on this I think if we put more effort into media fuzzing, it
>>> will be able to find dozens more.
>>
>> Yeah, this is good stuff. Thank you for setting this up.
> 
> Agreed, Dmitry thank you for doing this.
> 
>>
>>>
>>> syzkaller needs descriptions of kernel interfaces to efficiently cover
>>> a subsystem. For example, see:
>>> https://github.com/google/syzkaller/blob/master/sys/linux/uinput.txt
>>> Hopefully you can read it without much explanation, it basically
>>> states that there is that node in /dev and here are ioctls and other
>>> syscalls that are relevant for this device and here are types of
>>> arguments and layout of involved data structures.
>>>
>>> Turned we actually have such descriptions for /dev/video* and /dev/v4l-subdev*:
>>> https://github.com/google/syzkaller/blob/master/sys/linux/video4linux.txt
>>> But we don't have anything for /dev/media*, fuzzer merely knows that
>>> it can open the device:
>>> https://github.com/google/syzkaller/blob/12b38f22c18c6109a5cc1c0238d015eef121b9b7/sys/linux/sys.txt#L479
>>> and then it will just blindly execute completely random workload on
>>> it, e.g. most likely it won't be able to come up with a proper complex
>>> structure layout for some ioctls. And I am actually not completely
>>> sure about completeness and coverage of video4linux.txt descriptions
>>> too as they were contributed by somebody interested in android
>>> testing.
>>
>> A quick look suggests that it is based on the 4.9 videodev2.h, which ain't
>> too bad. There are some differences between the 4.20 videodev2.h and the
>> 4.9, but not too many.
>>
>>>
>>> I wonder if somebody knowledgeable in /dev/media interface be willing
>>> to contribute additional descriptions?
>>
>> We'll have to wait for 4.20-rc1 to be released since there are important
>> additions to the media API. I can probably come up with something, I'm
>> just not sure when I get around to it. Ping me in three weeks time if you
>> haven't heard from me.
>>
>>>
>>> We also have code coverage reports with the coverage fuzzer achieved
>>> so far. Here in the Cover column:
>>> https://syzkaller.appspot.com/#managers
>>> e.g. this one (but note this is a ~80MB html file):
>>> https://storage.googleapis.com/syzkaller/cover/ci-upstream-kasan-gce-root.html
>>> This can be used to assess e.g. v4l coverage. But I don't know what's
>>> coverable in general from syscalls and what's coverable via the stub
>>> drivers in particular. So some expertise from media developers would
>>> be helpful too.
>>
>> The four virtual drivers should give pretty decent coverage of the core
>> code. Are you able to test with a 32-bit syzkaller application on a 64-bit
>> kernel as well? That way the compat32 code is tested.
>>
>>>
>>> Do I understand it correctly that when a process opens /dev/video* or
>>> /dev/media* it gets a private instance of the device? In particular,
>>> if several processes test this in parallel, will they collide? Or they
>>> will stress separate objects?
>>
>> It actually depends on the driver. M2M devices will give you a private
>> instance whenever you open it. Others do not, but you can call most ioctls
>> in parallel. But after calling REQBUFS or CREATE_BUFS the filehandle that
>> called those ioctls becomes owner of the device until the buffers are
>> released. So other filehandles cannot do any streaming operations (EBUSY
>> will be returned).
>>
>>> You also mentioned that one of the devices requires some complex setup
>>> via configfs. Is this interface described somewhere? Do you think it's
>>> more profitable to pre-setup some fixed configuration for each test
>>> process? Or just give the setup interface to fuzzer and let it do
>>> random setup? Or both?
>>
>> That's the vimc driver, but the configfs code isn't in yet.
> 
> I'll try to submit it later this week (with documentation) :)

I submitted the first version at:
https://www.spinics.net/lists/linux-media/msg144244.html
As soon as it is updated we can add it to fuzzer. I believe some
pre-setup/fixed configuration would work.

I don't know much about fuzzer's code, if you could give me some
pointers I can help with that.

Thanks
Helen

> 
>>
>> Regards,
>>
>> 	Hans
>>
>>>
>>> Thanks in advance
>>>
>>
> 
> 
> Thanks
> Helen
> 

Re: VIVID/VIMC and media fuzzing

[Dmitry Vyukov]

On Fri, Dec 7, 2018 at 8:22 PM Helen Koike <helen.koike@collabora.com> wrote:
> >>> You also mentioned that one of the devices requires some complex setup
> >>> via configfs. Is this interface described somewhere? Do you think it's
> >>> more profitable to pre-setup some fixed configuration for each test
> >>> process? Or just give the setup interface to fuzzer and let it do
> >>> random setup? Or both?
> >>
> >> That's the vimc driver, but the configfs code isn't in yet.
> >
> > I'll try to submit it later this week (with documentation) :)
>
> I submitted the first version at:
> https://www.spinics.net/lists/linux-media/msg144244.html
> As soon as it is updated we can add it to fuzzer. I believe some
> pre-setup/fixed configuration would work.
>
> I don't know much about fuzzer's code, if you could give me some
> pointers I can help with that.

Hi Helen,

Great!

It may be easier to think about this on 2 levels:
The first is _what_ we want to do. For this, imagine you are writing a
stress test for the subsystem as a C program that does some fixed
setup and then executes random syscalls related to the subsystem and
acting on the devices using rand() to select syscalls and arguments.
What setup would you do for this? What syscalls would you issue?

The second is then how to fit this into syzkaller.
The setup part in syzkaller is also just custom C code. E.g. this
setups network devices for test process:
https://github.com/google/syzkaller/blob/master/executor/common_linux.h#L154-L301
There is a little bit of trickery because this code is also used to
generate C reproducers for crashes, and it also needs to preferably
support multiple independent test processes (namely this code has
procid=0..N variable and needs to setup e.g. /dev/loopN device
corresponding to current procid). E.g. for vivid we use
"vivid.n_devs=16 vivid.multiplanar=1,2,1,2,1,2,1,2,1,2,1,2,1,2,1,2".
But overall it's just C code.

For the main stress/fuzzing we have these declarative descriptions,
which are hopefully mostly self-explanatory:
https://github.com/google/syzkaller/blob/master/sys/linux/video4linux.txt
If there is something missing, we need to add missing parts. And maybe
even give fuzzer the configfs interface too to mess with (it can open
specified files and do, say, writes with complex inputs, both binary
and text based).

Also, will we gain something by enabling the following ones inside of a VM:
# CONFIG_V4L_PLATFORM_DRIVERS is not set
# CONFIG_V4L_MEM2MEM_DRIVERS is not set
? Or, it's just physical hardware drivers?
FTR, here are configs that syzbot uses:
https://github.com/google/syzkaller/blob/master/dashboard/config/upstream-kasan.config
https://github.com/google/syzkaller/blob/master/dashboard/config/upstream-selinux.cmdline
https://github.com/google/syzkaller/blob/master/dashboard/config/upstream.sysctl

Thanks