linux-kernel - Re: [RFC 0/2] Add Virtual Box vboxguest and vboxsf guest drivers to the mainline kernel

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 11 Aug 2017 18:32:02 +0200
From:   Arnd Bergmann <arnd@...db.de>
To:     Hans de Goede <hdegoede@...hat.com>
Cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Alexander Viro <viro@...iv.linux.org.uk>,
        Michael Thayer <michael.thayer@...cle.com>,
        "Knut St . Osmundsen" <knut.osmundsen@...cle.com>,
        Larry Finger <Larry.Finger@...inger.net>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Linux FS-devel Mailing List <linux-fsdevel@...r.kernel.org>
Subject: Re: [RFC 0/2] Add Virtual Box vboxguest and vboxsf guest drivers to
 the mainline kernel

On Fri, Aug 11, 2017 at 6:09 PM, Hans de Goede <hdegoede@...hat.com> wrote:
> On 11-08-17 18:02, Arnd Bergmann wrote:
>> Can you clarify which ioctl interface they agreed to? Would they
>> only keep the one that the proposed driver implements today,
>> or the one we end up with after a full review? ;-)
>
>
> Given that there are a lot of users already using the existing interface
> more the former (the proposed driver implements today) then the latter.
>
> But for now they assume that the userspace and kernel module versions
> are always in sync, so some small fixes might be possible. Some questions
> from me about unclear behavior of one ioctl command have already let
> to one small fix. But in general given the long out of tree history
> of this driver the interface is something which will be hard to change.

Ok.

>> I think these drivers should be part of the kernel, but I see
>> drivers/misc/
>> as a last resort location for things that don't fit anywhere else.
>
>
> I ended up using drivers/misc because that is where the vmware drivers
> are.
>
>> In this case,
>> would maybe drivers/platform/vbox or drivers/firmware/vbox be better?
>
>
> Definitely not drivers/firmware that feels wrong (the driver talks
> to a pci device), I personally think adding a new dir under drivers/platform
> for just the single driver is overkill.

Actually we have a lot of different places already. I wasn't aware
of drivers/misc/vmw_vmci/, then we also have drivers/xen, drivers/hv
drivers/lguest and drivers/virtio for hypervisor specific interfaces, and
there is drivers/virt/fsl_hypervisor.c.

In drivers/firmware, we have a couple of similar things, mostly for
ARM Trustzone based firmware which has a lot in common with a
hypervisor.

How about adding it to drivers/virt/ then?

     Arnd