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: Re: [PATCH] pstore/ram: Add support for dynamically allocated ramoops memory regions
Date: Thu, 22 Jun 2023 10:58:01 -0700 [thread overview]
Message-ID: <3A2CFB4D-27D0-4FEB-93B4-2F888305DE5A@kernel.org> (raw)
In-Reply-To: <ZJSES98P+zzrhBI5@google.com>
On June 22, 2023 10:26:35 AM PDT, Isaac Manjarres <isaacmanjarres@google.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. This is not desirable
>> > > in environments where it is preferred for the region to be dynamically
>> > > allocated early during boot (i.e. the memory region is defined with
>> > > the "alloc-ranges" property instead of the "reg" property).
>> > >
>> >
>> > Thanks for sending this out, Isaac!
>> >
>> > 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?
>> >
>> > > Since ramoops regions are part of the reserved-memory devicetree
>> > > node, they exist in the reserved_mem array. 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.
>> >
>> > I think this is answering my question above, but it's a little opaque,
>> > so I'm not sure.
>>
>> 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.
>
>I had proposed re-wording the end of the commit message in my response
>to John as follows:
>
>"...and that structure contains the address of the base of the region
>that was allocated at boot anywhere within the range specified by the
>"alloc-ranges" devicetree property."
>
>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.e. the things written during the last boot would then no longer accessible at the next boot? E.g.:
Boot 1.
Get address Foo.
Crash, write to Foo.
Boot 2.
Get address Bar, different from Foo.
Nothing found at Bar, so nothing populated in pstorefs; crash report from Boot 1 unavailable.
I feel like there is something I don't understand about the Foo/Bar addresses in my example.
-Kees
--
Kees Cook
next prev parent reply other threads:[~2023-06-22 17:58 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-22 0:52 Isaac J. Manjarres
2023-06-22 4:47 ` John Stultz
2023-06-22 5:15 ` Kees Cook
2023-06-22 17:26 ` Isaac Manjarres
2023-06-22 17:58 ` Kees Cook [this message]
2023-06-22 19:51 ` Elliot Berman
2023-06-26 17:34 ` Mukesh Ojha
2023-07-04 6:07 ` Krzysztof Kozlowski
2023-07-05 22:21 ` Kees Cook
2023-07-06 16:00 ` Mukesh Ojha
2023-07-04 6:05 ` Krzysztof Kozlowski
2023-06-22 17:19 ` Isaac Manjarres
2023-07-04 6:05 ` Krzysztof Kozlowski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=3A2CFB4D-27D0-4FEB-93B4-2F888305DE5A@kernel.org \
--to=kees@kernel.org \
--cc=gpiccoli@igalia.com \
--cc=isaacm@codeaurora.org \
--cc=isaacmanjarres@google.com \
--cc=jstultz@google.com \
--cc=keescook@chromium.org \
--cc=kernel-team@android.com \
--cc=linux-hardening@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mojha@codeaurora.org \
--cc=psodagud@codeaurora.org \
--cc=tony.luck@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®