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> <CAD2FfiGnmFSTPvkJaXj+cf4yDvci-j+2QkpMqNY821fUT5C=CA@mail.gmail.com>
In-Reply-To: <CAD2FfiGnmFSTPvkJaXj+cf4yDvci-j+2QkpMqNY821fUT5C=CA@mail.gmail.com>
From:   Andy Shevchenko <andy.shevchenko@gmail.com>
Date:   Thu, 11 Nov 2021 14:46:10 +0200
Message-ID: <CAHp75Vcp=hC1oL5FBQDDFe8EBxWB9Po4FKNS9ZGtD3q-yQPtAw@mail.gmail.com>
Subject: Re: [PATCH] firmware: export x86_64 platform flash bios region via sysfs
To:     Richard Hughes <hughsient@gmail.com>,
        Ard Biesheuvel <ardb@kernel.org>
Cc:     Mika Westerberg <mika.westerberg@linux.intel.com>,
        Hans-Gert Dahmen <hans-gert.dahmen@immu.ne>,
        Mauro Lima <mauro.lima@eclypsium.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, Nov 11, 2021 at 1:46 PM Richard Hughes <hughsient@gmail.com> wrote:
> On Thu, 11 Nov 2021 at 10:33, Mika Westerberg
> <mika.westerberg@linux.intel.com> wrote:

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

Well, it's _usual_ case, but in general the assumption is simply
incorrect. Btw, have you checked it on Coreboot enabled platforms?
What about bare metal configurations where the bootloader provides
services to the OS?

> Ideally, fwupd needs the entire IFD partition which contains all the
> EFI File Volumes.

Well, can't it be part of the EFI subsystem in the kernel then? (+Ard)

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


-- 
With Best Regards,
Andy Shevchenko