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
| ||
|
Date: Mon, 21 Aug 2017 14:48:00 +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: Modifying the vboxguest ioctl API (Was: Re: [vbox-dev] [RFC] VGDrvCommonIoCtl: Add f32bit flag argument) Hi, On 14-08-17 14:19, Hans de Goede wrote: > 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. I plan to post a v2 of the vboxguest driver for upstream tomorrow. Given the above I will mark it as a RFC for now. Anychance you can wrap this up soonish so that I can post a non RFC version with the final ABI upstream ? Regards, Hans
Powered by blists - more mailing lists