> -----Original Message----- > From: Alan Cox [mailto:gno...@lxorguk.ukuu.org.uk] > Sent: Thursday, October 5, 2017 8:59 AM > To: Limonciello, Mario <mario_limoncie...@dell.com> > Cc: dvh...@infradead.org; Andy Shevchenko <andy.shevche...@gmail.com>; > LKML <linux-kernel@vger.kernel.org>; platform-driver-...@vger.kernel.org; > Andy Lutomirski <l...@kernel.org>; quasi...@google.com; > pali.ro...@gmail.com; r...@rjwysocki.net; mj...@google.com; h...@lst.de; Greg > KH <g...@kroah.com> > Subject: Re: [PATCH v4 13/14] platform/x86: dell-smbios-wmi: introduce > userspace interface > > On Wed, 4 Oct 2017 17:48:39 -0500 > Mario Limonciello <mario.limoncie...@dell.com> wrote: > > > This userspace character device will be used to perform SMBIOS calls > > from any applications. > > > > It provides an ioctl that will allow passing the 32k WMI calling > > interface buffer between userspace and kernel space. > > What is your security model for firing 32K of random crap at the BIOS ?
Adding new class and select methods requires a review with the security team. They will do STRIDE analysis and threat modeling. > Do you fuzz test the BIOS interface ? Yes there has been internal fuzz testing classes and selects used in the ACPI interface in the past. I can't comment on how regularly that is done. I do think it's interesting is to use the interface in Linux for further fuzz testing though. > > How do we know that between now and the end of the universe every call is > safe to execute as any random user without upsetting other users on the > same PC ? Any random user shouldn't be executing the ioctl. Only root should be executing any of these calls. If there is a particular call that is deemed too dangerous to have available the ioctl call can be filtered by the kernel module. > > Right now this patch is scary. U've fuzzed tested BIOS firmware in thepast > and it almost universally ended up in reaching for the power cord because > PC firmware is usually closed and usually crap. > Can you please share more context? > In addition you are assuming that every function you ever provide via > that ioctl has the same securiy model. So if one of them should only be > usable by the user logged in on the console the system would have to > enforce that for all. If you have two conflicting security policies we'd > have to make it root only and owned by a daemon. If a BIOS turns out to > have a hole then we have to make it CAP_SYS_RAWIO. > > /dev/dorandomvendorspecificshit is not an API and not a security policy. > > Alan All functionality offered through this interface has the same security model. This should only be made available to root, but I don't see the need for a daemon to further sit between calls. The two applications that I see using this in the short term (fwupd and fwupdate) both run as root and would directly use this interface.
