lkml.org 
[lkml]   [2021]   [Nov]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectRe: [PATCH] firmware: export x86_64 platform flash bios region via sysfs
    Am Do., 11. Nov. 2021 um 14:34 Uhr schrieb Mika Westerberg
    <mika.westerberg@linux.intel.com>:
    >
    > On Thu, Nov 11, 2021 at 01:22:25PM +0000, Richard Hughes wrote:
    > > On Thu, 11 Nov 2021 at 13:01, Mika Westerberg
    > > <mika.westerberg@linux.intel.com> wrote:
    > > > I'm not sure I understand why the platform security needs to be turned off?
    > >
    > > Sorry to be unclear, I meant we had to turn off Secure Boot (and thus
    > > also kernel lockdown) so that we could use /dev/mem to verify that
    > > OEMs have set up the IFD, BLE, BIOSWP etc correctly. You'd be
    > > surprised just how many vendors don't read the specifications
    > > correctly and get this wrong. We also need port IO to use the
    > > intel-spi driver so we can parse the BIOS contents from userspace,
    > > which you can't obviously do when SB is turned off. The eSPI
    > > controller is hidden on some hardware now, and we need to play games
    > > to make it visible again.
    >
    > Okay, thanks for explaining.
    >
    > > > I think exposing /dev/mem opens another can of worms that we want to
    > > > avoid.
    > >
    > > Ohh it's not all of /dev/mem, it's just the 16MB BIOS region that has
    > > to be mapped at that address for the hardware to boot.
    >
    > I see.
    >
    > > > Don't we already expose some of the EFI stuff under /sys/firmware?
    > >
    > > Yes, some information, but not the file volumes themselves. I don't
    > > think the kernel wants to be in the game of supporting every nested
    > > container and compression format that EFI supports. It's also the
    > > wrong layer to expose platform attributes like BLE, but that's an
    > > orthogonal thing to the patch Hans-Gert is proposing.
    > >
    > > > I just don't want to
    > > > spend yet another Christmas holiday trying to fix angry peoples laptops :(
    > >
    > > Completely understood, I don't think any of us want that.
    > >
    > > > Having said that the hardware sequencer used in the recent CPUs should
    > > > be much safer in that sense.
    > >
    > > FWIW, I'd be fine if we had RO access for HWSEQ flash access only. If
    > > I understood correctly that's what Mauro proposed (with a patch) and
    > > instead was told that it was being rewritten as a mtd driver
    > > completion time unknown.
    >
    > I think Mauro proposed something different, basically exposing RO parts
    > of the driver only.
    >
    > The intel-spi driver is being moved from MTD to SPI because the MTD
    > SPI-NOR maintainers (not me) said that it needs to be done before we can
    > add any new feature to the driver. That includes also Mauro's patch.
    >
    > I have v4 of the conversion patch series done already but since it is a
    > middle of the merge window I'm holding it until v5.16-rc1 is released
    > (next sunday). I can CC you too and I suppose Hans and Mauro (who else,

    I'd be delighted.

    > let me know). Once the MTD maintainers are happy we can progress adding
    > features what fwupd needs there too (and the features we, Intel, want to
    > add there).

    Hans-Gert

    \
     
     \ /
      Last update: 2021-11-11 14:37    [W:3.250 / U:0.460 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site