I've been bitten recently by mcelog not working on machines started in
secure boot mode. mcelog tries to read DMI information from /dev/mem
and fails to open it.
This made me wonder: if not even root can read /dev/mem (nor, I
suppose, /dev/kmem and /dev/port) in secure boot mode, why are we
creating these device nodes at all in the first place? Can't we detect
that we are in secure boot mode and skip that step, and reap the rewards
(faster boot, lower memory footprint and less confusion)?
Thanks,
--
Jean Delvare
SUSE L3 Support
On Fri, Sep 06, 2019 at 01:02:21PM +0200, Jean Delvare wrote:
> I've been bitten recently by mcelog not working on machines started in
> secure boot mode. mcelog tries to read DMI information from /dev/mem
> and fails to open it.
What do you mean by "secure boot"? Is this matthew's patchset that
restricts /dev/mem/ or something else?
> This made me wonder: if not even root can read /dev/mem (nor, I
> suppose, /dev/kmem and /dev/port) in secure boot mode, why are we
> creating these device nodes at all in the first place? Can't we detect
> that we are in secure boot mode and skip that step, and reap the rewards
> (faster boot, lower memory footprint and less confusion)?
Sure, feel free to not register it at all if the mode is enabled.
thanks,
greg k-h
On Fri, 6 Sep 2019 14:15:10 +0200, Greg Kroah-Hartman wrote:
> On Fri, Sep 06, 2019 at 01:02:21PM +0200, Jean Delvare wrote:
> > I've been bitten recently by mcelog not working on machines started in
> > secure boot mode. mcelog tries to read DMI information from /dev/mem
> > and fails to open it.
>
> What do you mean by "secure boot"? Is this matthew's patchset that
> restricts /dev/mem/ or something else?
I mean that early in the kernel log is:
Secure boot enabled and kernel locked down
> > This made me wonder: if not even root can read /dev/mem (nor, I
> > suppose, /dev/kmem and /dev/port) in secure boot mode, why are we
> > creating these device nodes at all in the first place? Can't we detect
> > that we are in secure boot mode and skip that step, and reap the rewards
> > (faster boot, lower memory footprint and less confusion)?
>
> Sure, feel free to not register it at all if the mode is enabled.
>
> thanks,
>
> greg k-h
--
Jean Delvare
SUSE L3 Support
D'oh, I hit reply while still editing... Sorry for the noise, a better
answer will come later when ready.
--
Jean Delvare
SUSE L3 Support
Hi Greg,
On Fri, 6 Sep 2019 14:15:10 +0200, Greg Kroah-Hartman wrote:
> On Fri, Sep 06, 2019 at 01:02:21PM +0200, Jean Delvare wrote:
> > I've been bitten recently by mcelog not working on machines started in
> > secure boot mode. mcelog tries to read DMI information from /dev/mem
> > and fails to open it.
>
> What do you mean by "secure boot"? Is this matthew's patchset that
> restricts /dev/mem/ or something else?
I mean that early in the kernel log is:
Secure boot enabled and kernel locked down
Digging it up, I found that this comes from a patch in our SLES kernel,
that's not upstream (yet). It is from a patch set by David Howells
(Cc'd) posted in April 2017:
https://patchwork.kernel.org/patch/9665591/
https://patchwork.kernel.org/patch/9665015/
I wrongly assumed it had been merged upstream meanwhile but I was
wrong. David, any reason why this didn't happen? Out of curiosity, are
these patches in RHEL kernels?
> > This made me wonder: if not even root can read /dev/mem (nor, I
> > suppose, /dev/kmem and /dev/port) in secure boot mode, why are we
> > creating these device nodes at all in the first place? Can't we detect
> > that we are in secure boot mode and skip that step, and reap the rewards
> > (faster boot, lower memory footprint and less confusion)?
>
> Sure, feel free to not register it at all if the mode is enabled.
Now I feel sorry that I asked my question upstream when there's nothing
to be done there. I'll go bother SUSE kernel folks instead, sorry for
the noise. And thanks for the advice.
--
Jean Delvare
SUSE L3 Support
On Monday, September 9, 2019 3:09:57 PM CEST Jean Delvare wrote:
> Hi Greg,
...
> > Sure, feel free to not register it at all if the mode is enabled.
> Now I feel sorry that I asked my question upstream when there's nothing
> to be done there. I'll go bother SUSE kernel folks instead, sorry for
> the noise. And thanks for the advice.
I also/still think /dev/mem should vanish in secure boot mode, also upstream.
There may have been strong reasons why it has been restricted to /dev/ioport
which I do not know.
Whatever the exact definition for kernel behaviour in secure boot mode in the
UEFI books is (if there is any), it should close quite some possible doors
for hijacking a machine or read sensible data and if anyhow possible secure
boot mode should head for this feature (IMHO): Get rid of /dev/mem.
Thanks for bringing this up,
Thomas
Jean Delvare <[email protected]> wrote:
> I wrongly assumed it had been merged upstream meanwhile but I was
> wrong. David, any reason why this didn't happen?
There were last-minute objections.
The patches got redesigned somewhat by Matthew Garrett and are now pending
pulling once again:
https://lore.kernel.org/linux-security-module/[email protected]/T/#u
> Out of curiosity, are these patches in RHEL kernels?
Fedora, yes, my patchset; RHEL-7 and RHEL-8, no.
David