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 17:30:18 +0200
From:   Andy Shevchenko <andy.shevchenko@...il.com>
To:     Hans-Gert Dahmen <hans-gert.dahmen@...u.ne>
Cc:     Richard Hughes <hughsient@...il.com>,
        Ard Biesheuvel <ardb@...nel.org>,
        Mika Westerberg <mika.westerberg@...ux.intel.com>,
        Mauro Lima <mauro.lima@...ypsium.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

On Thu, Nov 11, 2021 at 4:33 PM Hans-Gert Dahmen
<hans-gert.dahmen@...u.ne> wrote:
> Am Do., 11. Nov. 2021 um 14:55 Uhr schrieb Andy Shevchenko
> <andy.shevchenko@...il.com>:
> > On Thu, Nov 11, 2021 at 2:56 PM Hans-Gert Dahmen
> > <hans-gert.dahmen@...u.ne> wrote:
> > > Am Do., 11. Nov. 2021 um 13:46 Uhr schrieb Andy Shevchenko
> > > <andy.shevchenko@...il.com>:
> > > > On Thu, Nov 11, 2021 at 1:46 PM Richard Hughes <hughsient@...il.com> wrote:
> > > > > On Thu, 11 Nov 2021 at 10:33, Mika Westerberg
> > > > > <mika.westerberg@...ux.intel.com> wrote:
> > > >
> > > > > it's always going to work on x64 -- if the system firmware isn't available at that offset then the platform just isn't going to boot.
> > > >
> > > > Well, it's _usual_ case, but in general the assumption is simply
> > > > incorrect. Btw, have you checked it on Coreboot enabled platforms?
> > > > What about bare metal configurations where the bootloader provides
> > > > services to the OS?
> > >
> > > No it is always the case. I suggest you go read your own Intel specs
> > > and datasheets
> >
> > Point me out, please, chapters in SDM (I never really read it in full,
> > it's kinda 10x Bible size). What x86 expects is 16 bytes at the end of
> > 1Mb physical address space that the CPU runs at first.
>
> So you do not know what you are talking about, am I correct?

Let me comment on this provocative question later, after some other
comments first.

> Starting
> from 386 the first instruction is executed at 0xFFFFFFF0h. What you
> are referring to is the 8086 reset vector and that was like 40 years
> ago.

True. The idea is the same, It has a reset vector standard for x86
(which doesn't explicitly tell what is there). So, nothing new or
different here.

> Please refer to SDM volume 3A, chapter 9, section 9.1.4 "First
> Instruction Executed", paragraph two. Just watch out for the hex
> number train starting with FFFFF... then you will find it. This is
> what requires the memory range to be mapped. Modern Intel CPUs require
> larger portions, because of the ACM loading and XuCode and whatnot.

Thanks. Have you read 9.7 and 9.8, btw?
Where does it tell anything about memory to be mapped to a certain
address, except the last up to 16 bytes?

> Please refer to the email [1] from me linked below where I reference
> all PCH datasheets of the x64 era to prove that 16MB are mapped
> hard-wired. Note that the range cannot be turned off and will read
> back 0xFF's if the PCH registers are configured to not be backed by
> the actual SPI flash contents.

And as I said it does not cover _all_ x86 designs (usual != all) .
Have you heard about Intel MID line of SoCs? Do you know that they
have no SPI NOR and the firmware is located on eMMC? Do you know that
they can run Linux?

So, maybe it's you who do not know what you are talking about, am I correct?

> [1] https://lkml.org/lkml/2021/6/24/379

-- 
With Best Regards,
Andy Shevchenko