linux-kernel - Re: [PATCH resend v2 0/3] virt: Add vboxguest driver for Virtual Box Guest integration

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:   Tue, 28 Nov 2017 11:01:42 +0100
From:   Hans de Goede <hdegoede@...hat.com>
To:     Larry Finger <Larry.Finger@...inger.net>,
        Arnd Bergmann <arnd@...db.de>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc:     Michael Thayer <michael.thayer@...cle.com>,
        "Knut St . Osmundsen" <knut.osmundsen@...cle.com>,
        Christoph Hellwig <hch@...radead.org>,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH resend v2 0/3] virt: Add vboxguest driver for Virtual Box
 Guest integration

Hi,

On 27-11-17 20:44, Larry Finger wrote:
> On 11/26/2017 09:12 AM, Hans de Goede wrote:
>> Here is resend of v2 of my cleaned up version of the VirtualBox vboxguest
>> driver, rebased on top of current the master from Linus.
>>
>> Note there currently is an issue with vboxvideo in the current master from
>> Linus, this is fixed by this patch:
>> https://patchwork.freedesktop.org/patch/189812/
>>
>> Once this is merged, I will do some further cleanups on the vboxsf driver
>> and also submit that upstream, if people want to test it before then, here
>> is a version which applies on top of this series:
>> https://github.com/jwrdegoede/linux-sunxi/commit/7f18b741945de3ae09ca8f1a9e48456ce32986c9
>>
>> Changes in v2:
>> -Change all uapi headers to kernel coding style: Drop struct and enum typedefs
>>   make type and struct-member names all lowercase, enum values all uppercase.
>> -Remove unused struct type declarations from some headers (shaving of another
>>   1000 lines)
>> -Remove or fixup doxygen style comments
>> -Get rid of CHECK macros, use a function taking in_ and out_size args instead
>> -Some other small codyingstyle fixes
>> -Split into multiple patches
>>
>> Here is (part of) the v1 cover-letter which is still relevant:
>>
>> VirtualBox upstream has declared the ioctl API for the /dev/vboxguest device
>> as being stable now, so once this passes review this is ready for merging.
>>
>> I'm only submitting the vboxguest driver for now, as the vboxsf driver
>> depends on this and it easier to first just get the vboxguest driver
>> upstream.
>>
>> I've removed all depenencies on vbox's OS-independent runtime and
>> the runtime itself, reducing the vboxguest driver from 100000+ lines
>> of code to aprox. 4300 lines. This reduces the non debug vboxguest.ko
>> size from 450kB to less then 100 kB. I've also cleaned up various other
>> warts such as doing hardware init in module_init rather then in a
>> pci_probe callback.
>>
>> The vboxguest driver introduces a new userspace API + ABI in the form
>> of ioctls on a character device. VirtualBox upstream not willing to
>> commit to keeping this ABI stable was one of the things which has
>> kept this driver driver out of mainline sofar. I've been talking to
>> VirtualBox upstream about mainlining the guest drivers and VirtualBox
>> upstream has agreed to consider the userspace ABI stable and only
>> extend it in a backwards compatible manner from now on.
> 
> Hans,
> 
> I have finished reviewing the commits for vboxguest. Most of my comments are minor.

Thank you for the review!

> I did have two problems when I tried to build these commits and the one that creates vboxsf.
> 
> The more serious one is that it is possible to build vboxguest without vboxvideo. When that happens, a non-privileged user cannot start X. As I say in the review, > I think that combination does not make sense and should not be allowed.

vboxguest and vboxvideo are completely independent at least from the kernel pov,
I do not believe that making them depend on each other makes sense.

AFAIK a non-privileged user cannot start X without vboxvideo at all, independent
of vboxguest being build or not. Falling back to vesa modesetting always requires
Xorg to be suid root, or the user to be privileged.

TL;DR: I can add a dependency between the 2, but I would rather not.

> When the system is booted, vboxsf is not loaded, and the shared folders are not automounted. Of course, that issue is not germane to these patches, but will be important when vboxsf is merged.

Hmm, I mount a couple of shares from rc.local (I don't use vbox' automount as I
want to specify a uid for the files) and as soon as mount.vboxsf gets executed
the vboxsf module gets auto-loaded as the module contains:

MODULE_ALIAS_FS("vboxsf");

AFAIK the communication of which volumes to automount is done through vboxguest,
anyways I will look into this before submitting vboxsf, in the worst case
we need to drop a modprobe.conf.d/vboxguest.conf file which has a postinst vboxguest
which loads vboxsf.

Regards,

Hans