linux-kernel - Re: [PATCH 0/6] rust: page: Support borrowing `struct page` and physaddr conversion

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: <38333d54-62e4-4d61-a49d-48489d6f977e@redhat.com>
Date: Thu, 6 Feb 2025 19:02:17 +0100
From: David Hildenbrand <david@...hat.com>
To: Asahi Lina <lina@...hilina.net>, Jason Gunthorpe <jgg@...pe.ca>
Cc: Miguel Ojeda <ojeda@...nel.org>, Alex Gaynor <alex.gaynor@...il.com>,
 Boqun Feng <boqun.feng@...il.com>, Gary Guo <gary@...yguo.net>,
 Björn Roy Baron <bjorn3_gh@...tonmail.com>,
 Benno Lossin <benno.lossin@...ton.me>,
 Andreas Hindborg <a.hindborg@...nel.org>, Alice Ryhl <aliceryhl@...gle.com>,
 Trevor Gross <tmgross@...ch.edu>, Jann Horn <jannh@...gle.com>,
 Matthew Wilcox <willy@...radead.org>, Paolo Bonzini <pbonzini@...hat.com>,
 Danilo Krummrich <dakr@...nel.org>, Wedson Almeida Filho
 <wedsonaf@...il.com>, Valentin Obst <kernel@...entinobst.de>,
 Andrew Morton <akpm@...ux-foundation.org>, linux-mm@...ck.org,
 airlied@...hat.com, Abdiel Janulgue <abdiel.janulgue@...il.com>,
 rust-for-linux@...r.kernel.org, linux-kernel@...r.kernel.org,
 asahi@...ts.linux.dev
Subject: Re: [PATCH 0/6] rust: page: Support borrowing `struct page` and
 physaddr conversion

On 04.02.25 22:18, Asahi Lina wrote:
> 
> 
> On 2/5/25 5:47 AM, David Hildenbrand wrote:
>> On 04.02.25 21:41, David Hildenbrand wrote:
>>> On 04.02.25 21:26, Jason Gunthorpe wrote:
>>>> On Tue, Feb 04, 2025 at 09:05:47PM +0100, David Hildenbrand wrote:
>>>>> Fully agreed, this is going into the right direction. Dumping what's
>>>>> mapped
>>>>> is a different story. Maybe that dumping logic could simply be
>>>>> written in C
>>>>> for the time being?
>>>>
>>>> ?
>>>>
>>>> Isn't dumping just a
>>>>      decode pte -> phys_to_virt() -> for_each_u64(virt) -> printk?
>>>>
>>>
>>> IIUC, the problematic bit is that you might not have a directmap such
>>> that phys_to_virt() would tell you the whole story.
>>
>> ... but it's late and I am confused. For dumping the *page table* that
>> would not be required, only when dumping mapped page content (and at
>> this point I am not sure if that is a requirement).
>>
>> So hopefully Asahi Lina can clarify what the issue was (if there is
>> any :) ).
> 
> Yes, the crash dumper has to dump the mapped page content. In fact, I
> don't care about the page tables themselves other than PTE permission
> bits, and the page tables alone are not useful for debugging firmware
> crashes (and aren't even included in the dump verbatim, at least not the
> kernel-allocated ones). The goal of the crash dumper is to take a
> complete dump of firmware virtual memory address space (which includes
> the kinds of memory I mentioned in [1]). The output is an ELF format
> core dump with all memory that the GPU firmware can access, that the
> kernel was able to successfully dump (which should be everything except
> for MMIO if the bootloader/DT have the right reserved-memory setup).
> 
> I *think* phys_to_virt should work just fine for *this* specific use
> case on this platform, but I'm not entirely sure. I still want to use
> the various pfn check functions before doing that, to exclude ranges
> that would definitely not work.

See my other mail, in /proc/kcore we do exactly that. See 
fs/proc/kcore.c, especially the KCORE_RAM case in read_kcore_iter().

So I would hope that at least for the Devcoredump we can find an 
alternative that does not require rust bindings, and maybe not even new 
c code at all (in a perfect world where you could just reuse  /proc/kcore).

-- 
Cheers,

David / dhildenb