linux-kernel - Re: [PATCH v2] schemas: Add a schema for memory map

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: <CAL_Jsq+jYexj8CR86cktxeiXyo7X+8i35+Ao0GBMhinVPNUoEw@mail.gmail.com>
Date:   Tue, 22 Aug 2023 13:52:40 -0500
From:   Rob Herring <robh@...nel.org>
To:     Simon Glass <sjg@...omium.org>
Cc:     devicetree@...r.kernel.org,
        Lean Sheng Tan <sheng.tan@...ements.com>,
        Tom Rini <trini@...sulko.com>,
        lkml <linux-kernel@...r.kernel.org>, linux-acpi@...r.kernel.org,
        Chiu Chasel <chasel.chiu@...el.com>,
        U-Boot Mailing List <u-boot@...ts.denx.de>,
        Gua Guo <gua.guo@...el.com>
Subject: Re: [PATCH v2] schemas: Add a schema for memory map

On Mon, Aug 21, 2023 at 2:48 PM Simon Glass <sjg@...omium.org> wrote:
>
> The Devicespec specification skips over handling of a logical view of
> the memory map, pointing users to the UEFI specification.

It's more that the DT spec defines what is not used with UEFI. If UEFI
covers more than the DT Spec defined, then we should look at that.

I would look some into (IBM) PowerPC for any prior art in this area.
Unfortunately, not publicly documented other than any users.

> It is common to split firmware into 'Platform Init', which does the
> initial hardware setup and a "Payload" which selects the OS to be booted.
> Thus an handover interface is required between these two pieces.
>
> Where UEFI boot-time services are not available, but UEFI firmware is
> present on either side of this interface, information about memory usage
> and attributes must be presented to the "Payload" in some form.
>
> This aims to provide an initial schema for this mapping.
>
> Note that this is separate from the existing /memory and /reserved-memory
> nodes, since it is mostly concerned with what the memory is used for. It
> may cover only a small fraction of available memory, although it could be
> used to signal which area of memory has ECC.
>
> For now, no attempt is made to create an exhaustive binding, so there are
> some example types lists. This can be completed once this has passed
> initial review.

I don't have much interest in picking this up unless there's some
wider agreement. From the previously referenced discussion[1], it
didn't seem like there was. But none of those folk are Cc'ed here.

> ---
>
> Changes in v2:
> - Reword commit message
>
>  dtschema/schemas/memory-map.yaml | 51 ++++++++++++++++++++++++++++++++
>  1 file changed, 51 insertions(+)
>  create mode 100644 dtschema/schemas/memory-map.yaml
>
> diff --git a/dtschema/schemas/memory-map.yaml b/dtschema/schemas/memory-map.yaml
> new file mode 100644
> index 0000000..97e531e
> --- /dev/null
> +++ b/dtschema/schemas/memory-map.yaml
> @@ -0,0 +1,51 @@
> +# SPDX-License-Identifier: BSD-2-Clause
> +# Copyright 2023 Google LLC
> +%YAML 1.2
> +---
> +$id: http://devicetree.org/schemas/memory-map.yaml#
> +$schema: http://devicetree.org/meta-schemas/core.yaml#
> +
> +title: /memory-map nodes
> +description: |
> +  Common properties always required in /memory-map nodes. These nodes are
> +  intended to resolve the nonchalant clause 3.4.1 ("/memory node and UEFI")
> +  in the Devicetree Specification.
> +
> +maintainers:
> +  - Simon Glass <sjg@...omium.org>
> +
> +properties:
> +  $nodename:
> +    const: '/'

This goes in the root node?

> +  usage:
> +    $ref: /schemas/types.yaml#/definitions/string
> +    description: |
> +      Describes the usage of the memory region, e.g.:
> +
> +        "acpi-reclaim", "acpi-nvs", "bootcode", "bootdata", "bootdata",
> +        "runtime-code", "runtime-data"

Can't these be covered by reserved-memory? The client is free to
reclaim any regions if it knows what they are.

> +  attr:
> +    $ref: /schemas/types.yaml#/definitions/string-array
> +    description: |
> +      Attributes possessed by this memory region:
> +
> +        "single-bit-ecc" - supports single-bit ECC
> +        "multi-bit-ecc" - supports multiple-bit ECC
> +        "no-ecc" - non-ECC memory

Isn't this pretty much a property of a memory region as a whole. IOW,
couldn't it just go into /memory node(s)?

> +
> +patternProperties:
> +  "^([a-z][a-z0-9\\-]+@[0-9a-f]+)?$":
> +    type: object
> +    additionalProperties: false
> +
> +    properties:
> +      reg:
> +        minItems: 1
> +        maxItems: 1024
> +
> +    required:
> +      - reg
> +
> +additionalProperties: true
> +
> +...
> --
> 2.42.0.rc1.204.g551eb34607-goog

[1] https://patches.linaro.org/project/linux-acpi/patch/20230426034001.16-1-cuiyunhui@bytedance.com/