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]
Message-ID: <YY4Q46XogSDHgcsY@lahna>
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.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ