Re: /dev/mem and secure boot
Jean Delvare 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/alpine.lrh.2.21.1909101402230.20...@namei.org/T/#u > Out of curiosity, are these patches in RHEL kernels? Fedora, yes, my patchset; RHEL-7 and RHEL-8, no. David
Re: /dev/mem and secure boot
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
Re: /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: 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
Re: /dev/mem and secure boot
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
Re: /dev/mem and secure boot
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
Re: /dev/mem and secure boot
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
/dev/mem and secure boot
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
