[lkml]   [2019]   [Sep]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: /dev/mem and secure boot
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:

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

 \ /
  Last update: 2019-09-09 15:11    [W:0.114 / U:1.652 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site