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 12:32:56 +0200
From:   Mika Westerberg <mika.westerberg@...ux.intel.com>
To:     Hans-Gert Dahmen <hans-gert.dahmen@...u.ne>
Cc:     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>,
        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

Hi,

On Thu, Nov 11, 2021 at 09:59:32AM +0100, Hans-Gert Dahmen wrote:
> > I think we discussed this previously already but in any case, instead of
> > removing the tag from the "main" driver, we can make certain "safe"
> > parts of the driver available without that tag. That would allow you to
> > read the things the controller exposes and allow distros safely include
> > the driver too. By "safe" parts, I mean the information available
> > through the SPI flash controller without actually sending commands to
> > the flash chip. I think this is the information everybody (on this
> > thread at least) is interested in. Unless I'm mistaken - I did not check
> 
> Yes you are mistaken. My patch is about safely reading the BIOS/UEFI
> binary on every past and future x86_64 system. There are tools out
> there that use the interface my patch uses and they can not work any
> longer when /dev/mem is locked down with SecureBoot enabled. The
> tools, like fwupd, should work out-of-the-box on the typical
> distribution. During this discussion we were told that my patch is not
> welcome and that we have to work with you to achieve the same. So I'm
> curious to hear how that can be done.

OK, I see from your patch that it uses the direct mapped read-only
region to read this data.

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). However, we can perhaps expose some of it through intel-spi,
and make that work so that distros can enable it safely. My concern of
removing the DANGEROUS tag is that we end up bricking yet another Lenovo
laptop by accident. Avoiding that would give me more peace of mind :)