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-next>] [day] [month] [year] [list]
Date:   Mon, 14 Aug 2017 14:19:46 +0200
From:   Hans de Goede <hdegoede@...hat.com>
To:     "Knut St. Osmundsen" <knut.osmundsen@...cle.com>,
        vbox-dev@...tualbox.org
Cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Arnd Bergmann <arnd@...db.de>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [vbox-dev] [RFC] VGDrvCommonIoCtl: Add f32bit flag argument

Hi,

On 14-08-17 13:43, Knut St. Osmundsen wrote:
> Hi Hans,
> 
> the other platforms also have KPIs or similar constructs for figuring
> out whether the client process issuing the I/O controls is a 32-bit or
> 64-bit one.  However, using the VBOXGUEST_IOCTL_FLAG set to 0 or 0x80 if
> 32-bit or 64-bit was a less complex (+faster(+safer)) way of deal with
> this.  The host driver does this as well.  I would like the structure of
> the two to be as similar as possible.
> 
> I'm not very keen to adding linux specific clutter (f32Bit + #ifndef
> RT_OS_LINUX) to the common code just because you can do it differently
> only Linux.  Sorry.  Want minimal platform specific cruft in common
> code.  Hope you understand.

OK and yes I understand.

> PS. I noticed in the Linux kernel RFC email thread that we've agreed to
> freeze the I/O control ABI.  We cannot guarantee that's it's 100% frozen
> at this point, since the generic status code fix (getting rid of that
> ioctl non-zero return value) hasn't been done yet.  I will see if I can
> squeeze it in later this week.

I had already decided to just live with the positive return for vbox
host status codes, but if you want this changed for other reasons, then yes
now would be the time to do that. But you don't have to do it just on
my account.

Regards,

Hans



> 
> 
> On 2017-08-14 9:30 AM, Hans de Goede wrote:
>> On 14-08-17 09:27, Hans de Goede wrote:
>>> Note to linux-kernel readers: This Cc-ed to linux-kernel because it is
>>> relevant for the "[RFC 0/2] Add Virtual Box vboxguest and vboxsf guest
>>> drivers to the mainline kernel" thread.
>>>
>>> Hi Michael, Knut,
>>>
>>> My first submission of the vboxguest driver for inclusion into
>>> the Linux kernel has lead to some questions about the use of the
>>> VBOXGUEST_IOCTL_FLAG to differentiate between 32 and 64 bit
>>> ioctls. Under Linux this is not necessary, as the driver already
>>> knows if it is serving a 32 bit compat or a regular ioctl.
>>>
>>> So I've come up with this patch to make VBOXGUEST_IOCTL_FLAG
>>> always 0 under Linux. I was hoping the f32bit flag could be
>>> used under more platforms so that it would actually be a cleanup,
>>> but it seems that Linux is the only platform with a compat_ioctl
>>> callback in its file-operations struct.
>>>
>>> Please let me know if you would be willing to merge this patch
>>> into upstream VirtualBox.
>>
>> p.s.
>>
>> I've only tested this patch with Linux!
>> _______________________________________________
>> vbox-dev mailing list
>> vbox-dev@...tualbox.org
>> https://www.virtualbox.org/mailman/listinfo/vbox-dev
> 
> 
> _______________________________________________
> vbox-dev mailing list
> vbox-dev@...tualbox.org
> https://www.virtualbox.org/mailman/listinfo/vbox-dev
> 

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ