linux-kernel - Re: [PATCH v1 04/13] kho: Verify deserialization status and fix FDT alignment access

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: <mafs0qztv4gw9.fsf@kernel.org>
Date: Tue, 18 Nov 2025 14:19:50 +0100
From: Pratyush Yadav <pratyush@...nel.org>
To: Mike Rapoport <rppt@...nel.org>
Cc: Pratyush Yadav <pratyush@...nel.org>,  Pasha Tatashin
 <pasha.tatashin@...een.com>,  akpm@...ux-foundation.org,  bhe@...hat.com,
  jasonmiu@...gle.com,  arnd@...db.de,  coxu@...hat.com,
  dave@...ilevsky.ca,  ebiggers@...gle.com,  graf@...zon.com,
  kees@...nel.org,  linux-kernel@...r.kernel.org,
  kexec@...ts.infradead.org,  linux-mm@...ck.org
Subject: Re: [PATCH v1 04/13] kho: Verify deserialization status and fix FDT
 alignment access

On Sat, Nov 15 2025, Mike Rapoport wrote:

> On Fri, Nov 14, 2025 at 05:52:37PM +0100, Pratyush Yadav wrote:
>> On Fri, Nov 14 2025, Pasha Tatashin wrote:
>> 
>> > @@ -1377,16 +1387,12 @@ static void __init kho_release_scratch(void)
>> >  
>> >  void __init kho_memory_init(void)
>> >  {
>> > -	struct folio *folio;
>> > -
>> >  	if (kho_in.scratch_phys) {
>> >  		kho_scratch = phys_to_virt(kho_in.scratch_phys);
>> >  		kho_release_scratch();
>> >  
>> > -		kho_mem_deserialize(kho_get_fdt());
>> > -		folio = kho_restore_folio(kho_in.fdt_phys);
>> > -		if (!folio)
>> > -			pr_warn("failed to restore folio for KHO fdt\n");
>> > +		if (!kho_mem_deserialize(kho_get_fdt()))
>> > +			kho_in.fdt_phys = 0;
>> 
>> The folio restore does serve a purpose: it accounts for that folio in
>> the system's total memory. See the call to adjust_managed_page_count()
>> in kho_restore_page(). In practice, I don't think it makes much of a
>> difference, but I don't see why not.
>
> This page is never freed, so adding it to zone managed pages or keeping it
> reserved does not change anything.

In practice, sure. I still don't see a good reason to _not_ initialize
the page properly. It's not like it costs us much in terms of
performance or code complexity.

Since kho_restore_folio() makes sure the folio was _actually_ preserved
from KHO, you have a safety check against previous kernel having a bug
and not preserving the FDT properly. And I get that the FDT has already
been used by this point, but at least you would have some known point to
catch this.

[...]

-- 
Regards,
Pratyush Yadav