[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <31421.1491569449@warthog.procyon.org.uk>
Date: Fri, 07 Apr 2017 13:50:49 +0100
From: David Howells <dhowells@...hat.com>
To: Andy Shevchenko <andy.shevchenko@...il.com>
Cc: dhowells@...hat.com,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
matthew.garrett@...ula.com, linux-efi@...r.kernel.org,
One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
acpi4asus-user <acpi4asus-user@...ts.sourceforge.net>,
Platform Driver <platform-driver-x86@...r.kernel.org>,
linux-security-module <linux-security-module@...r.kernel.org>,
keyrings@...r.kernel.org
Subject: Re: [PATCH 15/24] asus-wmi: Restrict debugfs interface when the kernel is locked down
Andy Shevchenko <andy.shevchenko@...il.com> wrote:
> > From: Matthew Garrett <matthew.garrett@...ula.com>
> >
> > We have no way of validating what all of the Asus WMI methods do on a given
> > machine - and there's a risk that some will allow hardware state to be
> > manipulated in such a way that arbitrary code can be executed in the
> > kernel, circumventing module loading restrictions. Prevent that if the
> > kernel is locked down.
>
> > + if (kernel_is_locked_down())
> > + return -EPERM;
>
> It looks a bit fragile when responsility of whatever reasons kernel
> can't serve become a driver burden.
> Can we fix this in debugfs framework instead?
Fix it with debugfs how? We can't offload the decision to userspace.
David
Powered by blists - more mailing lists