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:   Wed, 5 Jul 2023 15:21:04 -0700
From:   Kees Cook <keescook@chromium.org>
To:     Krzysztof Kozlowski <krzk@kernel.org>
Cc:     Mukesh Ojha <quic_mojha@quicinc.com>,
        Elliot Berman <quic_eberman@quicinc.com>,
        Kees Cook <kees@kernel.org>,
        Isaac Manjarres <isaacmanjarres@google.com>,
        John Stultz <jstultz@google.com>,
        Tony Luck <tony.luck@intel.com>,
        "Guilherme G. Piccoli" <gpiccoli@igalia.com>,
        kernel-team@android.com, linux-hardening@vger.kernel.org,
        linux-kernel@vger.kernel.org, Trilok Soni <quic_tsoni@quicinc.com>,
        Satya Durga Srinivasu Prabhala <quic_satyap@quicinc.com>
Subject: Re: [PATCH] pstore/ram: Add support for dynamically allocated
 ramoops memory regions
Message-ID: <202307051516.AE6080BF@keescook>
References: <20230622005213.458236-1-isaacmanjarres@google.com>
 <CANDhNCrEhx4LUPaz-FHZZJMG2yX670hk-vGTZs=HxiGR18zm5A@mail.gmail.com>
 <202306212212.5E53607@keescook>
 <ZJSES98P+zzrhBI5@google.com>
 <3A2CFB4D-27D0-4FEB-93B4-2F888305DE5A@kernel.org>
 <a2c9417b-3a50-bea4-dd39-2f021c196fa1@quicinc.com>
 <696269e1-8b97-66ed-c9b0-ce1b8d637d24@quicinc.com>
 <bd531778-a587-e4d0-e360-432208f064ea@kernel.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <bd531778-a587-e4d0-e360-432208f064ea@kernel.org>
Precedence: bulk

On Tue, Jul 04, 2023 at 08:07:09AM +0200, Krzysztof Kozlowski wrote:
> On 26/06/2023 19:34, Mukesh Ojha wrote:
> > I have tried multiple attempt already to get this patch in
> > 
> > https://lore.kernel.org/lkml/1675330081-15029-2-git-send-email-quic_mojha@quicinc.com/
> > 
> > later tried the approach of patch #9 along with minidump series..
> 
> For all dynamic reserved-memory-ramoops thingy, I think Rob made clear
> statement:
> 
> "I don't think dynamic ramoops location should be defined in DT."
> 
> https://lore.kernel.org/lkml/CAL_JsqKV6EEpsDNdj1BTN6nODb=hsHkzsdkCzzWwnTrygn0K-A@mail.gmail.com/
> 
> Please do not send three versions of the same patch hoping one will
> sneak in.

If I understand correctly, the driving issue here is that minidump wants
to be able to find the crash report "externally". Perhaps pstore could
provide either a known symbol that contains the address that was used,
or could add something to the kernel crash image (like is done for
KASLR), so that an external consumer of the kernel crash image could
find it?

And then the RAM backend for pstore could gain an option for "just
allocate regular RAM" for holding the dump? In other words, the address
is chosen by pstore, but an external consumer could still locate it.

-Kees

-- 
Kees Cook