[lkml]   [2017]   [Oct]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRE: [PATCH v4 13/14] platform/x86: dell-smbios-wmi: introduce userspace interface
> -----Original Message-----
> From: Alan Cox []
> Sent: Thursday, October 5, 2017 8:59 AM
> To: Limonciello, Mario <>
> Cc:; Andy Shevchenko <>;
> LKML <>;;
> Andy Lutomirski <>;;
>;;;; Greg
> KH <>
> 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 <> 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.

 \ /
  Last update: 2017-10-05 16:23    [W:0.119 / U:11.816 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site