linux-kernel - /dev/mem and secure boot

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [thread-next>] [day] [month] [year] [list]

Date:   Fri, 6 Sep 2019 13:02:21 +0200
From:   Jean Delvare <jdelvare@...e.de>
To:     Arnd Bergmann <arnd@...db.de>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Thomas <trenn@...e.de>
Cc:     LKML <linux-kernel@...r.kernel.org>
Subject: /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