[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20171013104009.zlxwhugbbzglwpza@pali>
Date: Fri, 13 Oct 2017 12:40:09 +0200
From: Pali Rohár <pali.rohar@...il.com>
To: Greg KH <greg@...ah.com>
Cc: Darren Hart <dvhart@...radead.org>,
Alan Cox <gnomes@...rguk.ukuu.org.uk>,
Mario Limonciello <mario.limonciello@...l.com>,
Andy Shevchenko <andy.shevchenko@...il.com>,
LKML <linux-kernel@...r.kernel.org>,
platform-driver-x86@...r.kernel.org,
Andy Lutomirski <luto@...nel.org>, quasisec@...gle.com,
rjw@...ysocki.net, mjg59@...gle.com, hch@....de
Subject: Re: [PATCH v7 10/15] platform/x86: dell-smbios: add filtering
capability for requests
On Friday 13 October 2017 11:43:14 Greg KH wrote:
> I understand the goal here of getting this to all work properly, but
> note that this is a different type of an operating system, and for some
> things, maybe we just do not allow direct userspace access for the
> obvious reasons (security, maintance, auditability, long-term-support,
> etc.) A whitelist of known-good commands sounds like a good place to
> start, why not start with that and go from there?
So, I understood that Greg want to rather see explicit whitelist in
allowed functionality from userspace. And for such thing generic WMI API
is not a best option.
Creating generic API for kernel drivers for filtering WMI requests based
on some white list is hard.
If we want to choose this option, then it would be easier to create Dell
specific API for setting SMBIOS tokens and in kernel just add list of
whitelisted tokens, which userspace can set/unset.
Parsing SMBIOS requests in WMI buffer is harder, it leads to more
complicated code and basically serves same as "function specific API"
which is easier to implement and audit.
WMI is just "RPC" for function calls and inspecting it for security and
access is harder as designing new simple API which would mimic what is
"hidden" in that "RPC".
--
Pali Rohár
pali.rohar@...il.com
Powered by blists - more mailing lists