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 for Android: free password hash cracker in your pocket

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

Message-ID: <CAHp75Ve9BMNy3gP=-Dajm+Lgu+E4FCqc4phLgV1_cr2qUnTX_w@mail.gmail.com>
Date:   Wed, 10 Nov 2021 11:25:02 +0200
From:   Andy Shevchenko <andy.shevchenko@...il.com>
To:     Hans-Gert Dahmen <hans-gert.dahmen@...u.ne>
Cc:     Mika Westerberg <mika.westerberg@...ux.intel.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>,
        Mauro Lima <mauro.lima@...ypsium.com>,
        Richard Hughes <hughsient@...il.com>,
        "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 Wed, Nov 10, 2021 at 11:17 AM Hans-Gert Dahmen
<hans-gert.dahmen@...u.ne> wrote:
> Am Mi., 10. Nov. 2021 um 10:05 Uhr schrieb Andy Shevchenko
> <andy.shevchenko@...il.com>:
> > On Wed, Nov 10, 2021 at 10:37 AM Hans-Gert Dahmen
> > <hans-gert.dahmen@...u.ne> wrote:
> > > Am Mi., 10. Nov. 2021 um 07:35 Uhr schrieb Andy Shevchenko
> > > <andy.shevchenko@...il.com>:
> > > > On Tuesday, November 9, 2021, Hans-Gert Dahmen <hans-gert.dahmen@...u.ne> wrote:
> > > >> Am Di., 9. Nov. 2021 um 13:42 Uhr schrieb Greg KH <gregkh@...uxfoundation.org>:
> >
> > > >> > Do you have a pointer to these complex and buggy drivers anywhere?
> > > >>
> > > >> I am talking about the linux-mtd intel-spi driver for example, but I
> > > >> feel that this gets the discussion in the wrong direction.
> > > >
> > > > This is the driver that covers all BIOSes on modern x86\64. What’s wrong with it? Why do you need this?!
> > > >
> > > > If it’s buggy, where is the bug reports from you or somebody else?
> > >
> > > Please see Mauro's mail in this thread from yesterday below:
> >
> > I didn't get this. What's wrong with the response from the author of
> > intel-spi (since we are speaking about it, let me add him to the
> > thread)?
> > What you are trying to do is to sneak around with ugly hack behind the
> > proper subsystem's back.
> >
> > NAK as I already said.
>
> There is nothing wrong with the response. Also we are not trying to
> sneak anything into the kernel. This just is no mtd or spi driver, it
> is not even a driver. What this does is it opens back up a portion of
> memory that can not be read anymore through /dev/mem on locked down
> systems with SecureBoot enabled. This portion of memory is actively
> being used by userspace programs. We, 9elements, Eclypsium, fwudp and
> immune are among those who rely upon this to improve the security of
> x86_64 linux devices.

I appreciate this.

x86_64 starting from long time ago has more or less standard hardware
interface for BIOS chip, i.e. SPI NOR. PCH usually has a separate host
controller and we have the driver in the kernel for that (coverage of
the systems may not be 100%, but close enough). Now you are trying to
repeat something that is _already_ provided by the kernel. Correct?

> Now what happens is that more distros start to
> lock down their kernels and require signed modules. With the mtd
> driver not working on those machine to read the bios binary, you are
> effectively forcing users into less secure system configurations (i.e.
> opening up the whole /dev/mem and/or disabling SecureBoot) just to be
> able to run fwupd or other tools to assess firmware information. The
> issue of being able to assess and compare the bios binary to the one
> publicly available from the vendors is increasingly getting important
> in the wake of recent CVEs about supply-chain attacks where UEFI
> malware was pre-installed. So we are not even doing anything new here,
> you are just making life harder for everybody.

Why me? As far as I got it from above the bottleneck is the distros
which do not enable the driver. So why not go and work with them?

-- 
With Best Regards,
Andy Shevchenko