MIME-Version: 1.0
References: <CAHifhD5V9vwJenRLcPRH5ZMeLa_JnjZKfdcFZw1CjceBtC6=Ew@mail.gmail.com>
 <CAHp75VeyQEaABFOnEUh2pdFx9ROJvRcud-BuEbKWmaEWpL9_Uw@mail.gmail.com>
 <CAHifhD7Qf7+dc7K-MjNguqmiCWUxOJZmQoCTRUZOR-RWMm_JPw@mail.gmail.com>
 <CAHp75Ve9BMNy3gP=-Dajm+Lgu+E4FCqc4phLgV1_cr2qUnTX_w@mail.gmail.com>
 <CAHifhD4n7O5eWFPOjRAmHYL52tW0K=uXXzVj7L5+enTFwFXW2A@mail.gmail.com>
 <CAArk9MP5cKJ+VhAZUseW4LnQNRvux=MZe2eSy3rQkbHKnUsGig@mail.gmail.com>
 <CAHp75VdRwvU5WjFP5E4gg8U+_e34A0Lwze+nz_wVHoB49jLeLg@mail.gmail.com>
 <CAArk9MNGSxR+92n-D2pe_+r+Z0Q9FoTMPqk11sAKA=4Vckj0HQ@mail.gmail.com>
 <YYy7QZGKeEEfI1mH@lahna> <CAHifhD5bXu2nP533RXyWDnyNt=k2rRZq5Z6A6CCik_2e6XNgGA@mail.gmail.com>
 <YYzxWPIWFAV04LRU@lahna>
In-Reply-To: <YYzxWPIWFAV04LRU@lahna>
From:   Richard Hughes <hughsient@gmail.com>
Date:   Thu, 11 Nov 2021 11:46:39 +0000
Message-ID: <CAD2FfiGnmFSTPvkJaXj+cf4yDvci-j+2QkpMqNY821fUT5C=CA@mail.gmail.com>
Subject: Re: [PATCH] firmware: export x86_64 platform flash bios region via sysfs
To:     Mika Westerberg <mika.westerberg@linux.intel.com>
Cc:     Hans-Gert Dahmen <hans-gert.dahmen@immu.ne>,
        Mauro Lima <mauro.lima@eclypsium.com>,
        Andy Shevchenko <andy.shevchenko@gmail.com>,
        Greg KH <gregkh@linuxfoundation.org>,
        "akpm@linux-foundation.org" <akpm@linux-foundation.org>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
        Philipp Deppenwiese <philipp.deppenwiese@immu.ne>,
        "platform-driver-x86@vger.kernel.org" 
        <platform-driver-x86@vger.kernel.org>
Content-Type: text/plain; charset="UTF-8"
Precedence: bulk

On Thu, 11 Nov 2021 at 10:33, Mika Westerberg
<mika.westerberg@linux.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.

> 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.

> 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.

Richard