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:   Fri, 12 Nov 2021 08:59:47 +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>,
        Richard Hughes <hughsient@...il.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>,
        "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 04:16:14PM +0100, Hans-Gert Dahmen wrote:
> > In case someone is unfamiliar with this, the Intel SPI hardware
> > exposes two interfaces through the same controller. One that is called
> > software sequencer and there is a register of "allowed" opcodes that
> > software can use as it wishes. This register can be locked down but is
> > not always. The second interface is the hardware sequencer that only
> > exposes higher level commands like read, write and so on and internally
> > then executes whatever opcode the controller got from the chip
> > "supported opcodes table" (SFDP).  The recent Intel hardware, all
> > big-cores, only provide hardware sequencer and the software one is not
> > even available.
> 
> I am familiar with this and I do totally agree. I believe HW
> sequencing is available since sandy-bridge from 2011, so it will
> suffice for modern platforms. Honestly me and my developer friends
> never understood why this driver needs to still focus on SW sequencing
> altogether, it seems like a (possibly buggy) relic that just slows
> down the vital parts.

Just to clarify the software sequencer was used in "recent" Atoms
(Baytrail, Braswell and I think its successor too). After Broxton I
think it all is now hardware sequencer only. AFAIK those are still used
in embedded world so we should keep the support in the driver but that
support can be put under the "DANGEROUS" KConfig option.