linux-hardening - Re: [PATCH] pstore/ram: Add support for dynamically allocated ramoops memory regions

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] [day] [month] [year] [list]

Date:   Thu, 6 Jul 2023 21:30:58 +0530
From:   Mukesh Ojha <quic_mojha@...cinc.com>
To:     Kees Cook <keescook@...omium.org>,
        Krzysztof Kozlowski <krzk@...nel.org>
CC:     Elliot Berman <quic_eberman@...cinc.com>,
        Kees Cook <kees@...nel.org>,
        Isaac Manjarres <isaacmanjarres@...gle.com>,
        John Stultz <jstultz@...gle.com>,
        Tony Luck <tony.luck@...el.com>,
        "Guilherme G. Piccoli" <gpiccoli@...lia.com>,
        <kernel-team@...roid.com>, <linux-hardening@...r.kernel.org>,
        <linux-kernel@...r.kernel.org>,
        "Trilok Soni" <quic_tsoni@...cinc.com>,
        Satya Durga Srinivasu Prabhala <quic_satyap@...cinc.com>
Subject: Re: [PATCH] pstore/ram: Add support for dynamically allocated ramoops
 memory regions



On 7/6/2023 3:51 AM, Kees Cook wrote:
> 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.

Yes, in-short, it wants RAM backend (fs/pstore/ram.c) to use regular ram
instead of fixed ram address range and at the same time it should be
able to query the address used.

So, registering with minidump is what telling upfront what address range
content would we be getting in final crash dump.

-Mukesh

> 
> -Kees
>