linux-kernel - Re: [PATCH] firmware: export x86_64 platform flash bios region via sysfs

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-prev] [thread-next>] [day] [month] [year] [list]

Date:   Thu, 11 Nov 2021 15:00:56 +0200
From:   Mika Westerberg <mika.westerberg@...ux.intel.com>
To:     Richard Hughes <hughsient@...il.com>
Cc:     Hans-Gert Dahmen <hans-gert.dahmen@...u.ne>,
        Mauro Lima <mauro.lima@...ypsium.com>,
        Andy Shevchenko <andy.shevchenko@...il.com>,
        Greg KH <gregkh@...uxfoundation.org>,
        "akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Philipp Deppenwiese <philipp.deppenwiese@...u.ne>,
        "platform-driver-x86@...r.kernel.org" 
        <platform-driver-x86@...r.kernel.org>
Subject: Re: [PATCH] firmware: export x86_64 platform flash bios region via
 sysfs

On Thu, Nov 11, 2021 at 11:46:39AM +0000, Richard Hughes wrote:
> On Thu, 11 Nov 2021 at 10:33, Mika Westerberg
> <mika.westerberg@...ux.intel.com> wrote:
> > OK, I see from your patch that it uses the direct mapped read-only
> > region to read this data.
> 
> Sorry for the delay in replying here. What I like about Hans-Gert's
> patch is that it's always going to work on x64 -- if the system
> firmware isn't available at that offset then the platform just isn't
> going to boot. It's super simple, and means we can read out the hugely
> complex UEFI blob without asking the user to turn off kernel lockdown
> and secure boot so we can run the security verification tools. At the
> moment we're in this strange situation where we ask the user to
> cripple their platform security to run the platform security tools.

I'm not sure I understand why the platform security needs to be turned
off? Sorry if that was already mentioned somewhere in the thread, I did
not read all of them throughly.

> > Do we know what information exactly fwupd needs? I mean exposing all of
> > this might not be good idea from security perspective (but I'm not an
> > expert).
> 
> Ideally, fwupd needs the entire IFD partition which contains all the
> EFI File Volumes. We already parse these when the user is booting
> without secure boot using the Intel SPI controller and doing *evil*
> hacks to make the PCI device visible. The reason we want to parse the
> BIOS can be explained pretty easily; at startup we look at the TPM
> PCRs and we know very quickly and easily if the system firmware event
> has changed. If the checksum changed, then the firmware was modified
> in some way. However, saying to the user that "checksum changed" isn't
> useful at all. What we want to do is say something like "an EFI binary
> called RootKitz.efi was added" or "the AmiTcgPlatformPeiAfterMem.efi
> binary changed" and actually report what was done. At the moment we
> can do this, but not if /dev/mem cannot be used.

I think exposing /dev/mem opens another can of worms that we want to
avoid.

Is there anything preventing to add a sane interface from say the
intel-spi driver (can be something else too) that exposes the minimal
set you need? That can be in the mainline kernel and is secure (and
safe) enough that distros (and users) can enable it?

Don't we already expose some of the EFI stuff under /sys/firmware?

> > However, we can perhaps expose some of it through intel-spi,
> > and make that work so that distros can enable it safely.
> 
> I think, if we're being honest, that Intel has no plans to make
> intel-spi available as a RO interface of any sort. There's some sort
> of hardware errata or misdesign that nobody can mention that makes the
> RO access unsafe. I think it's probably more than missing arbitration.

No that's not the reason. The real reason I'm concerned (as the author
and maintainer of that thing) is that last time the driver was
accidentally enabled in Ubuntu (around 2019) there was a driver bug
(which was fixed already but it was not yet in the Ubuntu kernel) that
turned some Lenovo based systems' BIOSes to read-only. It has nothing to
do with my employer or hardware errata/misdesign. I just don't want to
spend yet another Christmas holiday trying to fix angry peoples laptops :(

Having said that the hardware sequencer used in the recent CPUs should
be much safer in that sense. It should not allow things like this to
happen (the affected systems used software based sequencer).