Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Thu, 22 Jun 2023 10:58:01 -0700
From:   Kees Cook <kees@kernel.org>
To:     Isaac Manjarres <isaacmanjarres@google.com>,
        Kees Cook <keescook@chromium.org>
CC:     John Stultz <jstultz@google.com>, Tony Luck <tony.luck@intel.com>,
        "Guilherme G. Piccoli" <gpiccoli@igalia.com>,
        "Isaac J. Manjarres" <isaacm@codeaurora.org>,
        Mukesh Ojha <mojha@codeaurora.org>,
        Prasad Sodagudi <psodagud@codeaurora.org>,
        kernel-team@android.com, linux-hardening@vger.kernel.org,
        linux-kernel@vger.kernel.org
Subject: =?US-ASCII?Q?Re=3A_=5BPATCH=5D_pstore/ram=3A_Add_support_for_dy?= =?US-ASCII?Q?namically_allocated_ramoops_memory_regions?=
User-Agent: K-9 Mail for Android
In-Reply-To: <ZJSES98P+zzrhBI5@google.com>
References: <20230622005213.458236-1-isaacmanjarres@google.com> <CANDhNCrEhx4LUPaz-FHZZJMG2yX670hk-vGTZs=HxiGR18zm5A@mail.gmail.com> <202306212212.5E53607@keescook> <ZJSES98P+zzrhBI5@google.com>
Message-ID: <3A2CFB4D-27D0-4FEB-93B4-2F888305DE5A@kernel.org>
MIME-Version: 1.0
Content-Type: text/plain;
 charset=utf-8
Content-Transfer-Encoding: quoted-printable
Precedence: bulk

On June 22, 2023 10:26:35 AM PDT, Isaac Manjarres <isaacmanjarres@google=2E=
com> wrote:
>On Wed, Jun 21, 2023 at 10:15:45PM -0700, Kees Cook wrote:
>> On Wed, Jun 21, 2023 at 09:47:26PM -0700, John Stultz wrote:
>> > > The reserved memory region for ramoops is assumed to be at a fixed
>> > > and known location when read from the devicetree=2E This is not des=
irable
>> > > in environments where it is preferred for the region to be dynamica=
lly
>> > > allocated early during boot (i=2Ee=2E the memory region is defined =
with
>> > > the "alloc-ranges" property instead of the "reg" property)=2E
>> > >
>> >=20
>> > Thanks for sending this out, Isaac!
>> >=20
>> > Apologies, I've forgotten much of the details around dt bindings here=
,
>> > so forgive my questions:
>> > If the memory is dynamically allocated from a specific range, is it
>> > guaranteed to be consistently the same address boot to boot?
>> >=20
>> > > Since ramoops regions are part of the reserved-memory devicetree
>> > > node, they exist in the reserved_mem array=2E This means that the
>> > > of_reserved_mem_lookup() function can be used to retrieve the
>> > > reserved_mem structure for the ramoops region, and that structure
>> > > contains the base and size of the region, even if it has been
>> > > dynamically allocated=2E
>> >=20
>> > I think this is answering my question above, but it's a little opaque=
,
>> > so I'm not sure=2E
>>=20
>> Yeah, I had exactly the same question: will this be the same
>> boot-to-boot?
>
>Hi Kees,
>
>Thank you for taking a look at this patch and for your review! When the
>alloc-ranges property is used to describe a memory region, the memory
>region will always be allocated within that range, but it's not
>guaranteed to be allocated at the same base address across reboots=2E
>
>I had proposed re-wording the end of the commit message in my response
>to John as follows:
>
>"=2E=2E=2Eand that structure contains the address of the base of the regi=
on
>that was allocated at boot anywhere within the range specified by the
>"alloc-ranges" devicetree property=2E"
>
>Does that clarify things better?

I am probably misunderstanding something still, but it it varies from boot=
 to boot, what utility is there for pstore if it changes? I=2Ee=2E the thin=
gs written during the last boot would then no longer accessible at the next=
 boot? E=2Eg=2E:

Boot 1=2E
Get address Foo=2E
Crash, write to Foo=2E
Boot 2=2E
Get address Bar, different from Foo=2E
Nothing found at Bar, so nothing populated in pstorefs; crash report from =
Boot 1 unavailable=2E

I feel like there is something I don't understand about the Foo/Bar addres=
ses in my example=2E

-Kees


--=20
Kees Cook