linux-kernel - Re: [PATCH v7 2/2] schemas: Add some common reserved-memory usages

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]

Date: Tue, 19 Dec 2023 21:46:04 -0700
From: Simon Glass <sjg@...omium.org>
To: "Chiu, Chasel" <chasel.chiu@...el.com>
Cc: Ard Biesheuvel <ardb@...nel.org>, 
	"devicetree@...r.kernel.org" <devicetree@...r.kernel.org>, Mark Rutland <mark.rutland@....com>, 
	Rob Herring <robh@...nel.org>, "Tan, Lean Sheng" <sheng.tan@...ements.com>, 
	lkml <linux-kernel@...r.kernel.org>, Dhaval Sharma <dhaval@...osinc.com>, 
	"Brune, Maximilian" <maximilian.brune@...ements.com>, Yunhui Cui <cuiyunhui@...edance.com>, 
	"Dong, Guo" <guo.dong@...el.com>, Tom Rini <trini@...sulko.com>, 
	ron minnich <rminnich@...il.com>, "Guo, Gua" <gua.guo@...el.com>, 
	"linux-acpi@...r.kernel.org" <linux-acpi@...r.kernel.org>, U-Boot Mailing List <u-boot@...ts.denx.de>
Subject: Re: [PATCH v7 2/2] schemas: Add some common reserved-memory usages

Hi,

On Mon, 11 Dec 2023 at 10:52, Simon Glass <sjg@...omium.org> wrote:
>
> Hi,
>
> On Tue, 28 Nov 2023 at 13:31, Chiu, Chasel <chasel.chiu@...el.com> wrote:
> >
> >
> >
> >
> > > -----Original Message-----
> > > From: Ard Biesheuvel <ardb@...nel.org>
> > > Sent: Tuesday, November 28, 2023 10:08 AM
> > > To: Chiu, Chasel <chasel.chiu@...el.com>
> > > Cc: Simon Glass <sjg@...omium.org>; devicetree@...r.kernel.org; Mark Rutland
> > > <mark.rutland@....com>; Rob Herring <robh@...nel.org>; Tan, Lean Sheng
> > > <sheng.tan@...ements.com>; lkml <linux-kernel@...r.kernel.org>; Dhaval
> > > Sharma <dhaval@...osinc.com>; Brune, Maximilian
> > > <maximilian.brune@...ements.com>; Yunhui Cui <cuiyunhui@...edance.com>;
> > > Dong, Guo <guo.dong@...el.com>; Tom Rini <trini@...sulko.com>; ron minnich
> > > <rminnich@...il.com>; Guo, Gua <gua.guo@...el.com>; linux-
> > > acpi@...r.kernel.org; U-Boot Mailing List <u-boot@...ts.denx.de>
> > > Subject: Re: [PATCH v7 2/2] schemas: Add some common reserved-memory
> > > usages
> > >
> > > You are referring to a 2000 line patch so it is not 100% clear where to look tbh.
> > >
> > >
> > > On Tue, 21 Nov 2023 at 19:37, Chiu, Chasel <chasel.chiu@...el.com> wrote:
> > > >
> > > >
> > > > In PR, UefiPayloadPkg/Library/FdtParserLib/FdtParserLib.c, line 268 is for
> > > related example code.
> > > >
> > >
> > > That refers to a 'memory-allocation' node, right? How does that relate to the
> > > 'reserved-memory' node?
> > >
> > > And crucially, how does this clarify in which way "runtime-code" and "runtime-
> > > data" reservations are being used?
> > >
> > > Since the very beginning of this discussion, I have been asking repeatedly for
> > > examples that describe the wider context in which these reservations are used.
> > > The "runtime" into runtime-code and runtime-data means that these regions have
> > > a special significance to the operating system, not just to the next bootloader
> > > stage. So I want to understand exactly why it is necessary to describe these
> > > regions in a way where the operating system might be expected to interpret this
> > > information and act upon it.
> > >
> >
> >
> > I think runtime code and data today are mainly for supporting UEFI runtime services - some BIOS functions for OS to utilize, OS may follow below ACPI spec to treat them as reserved range:
> > https://uefi.org/specs/ACPI/6.5/15_System_Address_Map_Interfaces.html#uefi-memory-types-and-mapping-to-acpi-address-range-types
> >
> > Like I mentioned earlier, that PR is still in early phase and has not reflected all the required changes yet, but the idea is to build gEfiMemoryTypeInformationGuid HOB from FDT reserved-memory nodes.
> > UEFI generic Payload has DxeMain integrated, however Memory Types are platform-specific, for example, some platforms may need bigger runtime memory for their implementation, that's why we want such FDT reserved-memory node to tell DxeMain.
> >
> > The Payload flow will be like this:
> >   Payload creates built-in default MemoryTypes table ->
> >     FDT reserved-memory node to override if required (this also ensures the same memory map cross boots so ACPI S4 works) ->
> >       Build gEfiMemoryTypeInformationGuid HOB by "platfom specific" MemoryTypes Table ->
> >         DxeMain/GCD to consume this MemoryTypes table and setup memory service ->
> >           Install memory types table to UEFI system table.Configuration table...
> >
> > Note: if Payload built-in default MemoryTypes table works fine for the platform, then FDT reserved-memory node does not need to provide such 'usage' compatible strings. (optional)
> > This FDT node could allow flexibility/compatibility without rebuilding Payload binary.
> >
> > Not sure if I answered all your questions, please highlight which area you need more information.
>
> Any more thoughts on this? If not, I would like to see this patch
> applied, please.

I am really not sure who or what is holding this up, so far.

Can we perhaps get this applied in time for Christmas? It would be a
nice end to the year.

Regards,
Simon