linux-kernel - Re: [PATCH v7 10/15] platform/x86: dell-smbios: add filtering capability for requests

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:   Fri, 13 Oct 2017 17:56:03 +0200
From:   Greg KH <greg@...ah.com>
To:     Mario.Limonciello@...l.com
Cc:     dvhart@...radead.org, gnomes@...rguk.ukuu.org.uk,
        andy.shevchenko@...il.com, linux-kernel@...r.kernel.org,
        platform-driver-x86@...r.kernel.org, luto@...nel.org,
        quasisec@...gle.com, pali.rohar@...il.com, rjw@...ysocki.net,
        mjg59@...gle.com, hch@....de
Subject: Re: [PATCH v7 10/15] platform/x86: dell-smbios: add filtering
 capability for requests

Just want to respond to this part first:

On Fri, Oct 13, 2017 at 03:03:10PM +0000, Mario.Limonciello@...l.com wrote:
> Take off your "kernel" hat and put on a "customer" hat for a few moments
> while I try to put this in practical terms why the whitelist approach doesn't
> scale for what I'm trying to do.

Heh, you do know my background in running an enterprise kernel team,
right? :)

> Let's say hypothetically a future version of this series that has only whitelisted
> commands and tokens lands in a kernel that's in the next Ubuntu LTS, RHEL
> release etc.
> Hardware coming out about that time works fine, you can control the various
> knobs.  Then later that year some new headless hardware is released that has
> zigbee controllers that work with inbox kernel drivers but you can't turn them 
> on and off any way BUT through the manageability interface (it's headless!).
> In the manageability interface we also offer a new class/select or token that 
> can control the GPIO that turns on/off these radios.

It's the "later" that you are missing here.  We only have code today for
hardware we have today.  If you come out with new hardware, you need new
kernel drivers for it, and as such, "old" enterprise kernels will just
not work properly.

It's always been that way, this is nothing new, we can't predict the
future, and is one big reason why I think the whole "enterprise" distro
market is wrong and going to fail in the end :)

Same goes for that new device id for the wifi chip, or the video camera
or the fingerprint reader.  Those have to be added to the kernel, and if
the distro so desires, backported to their old and crufty version.

This has been happening for two decades now, somehow coming up with a
"raw" pipe from userspace to the kernel to control the hardware just
because you don't want to update the kernel code, isn't going to solve
the issue here (hint, you now have to update your userspace code, why is
that suddenly easier than the kernel?)

I know hardware companies want to stop writing software for their new
hardware designs.  I too want a pony :)

Sorry, this argument isn't going to fly.

greg k-h