linux-kernel - Re: [PATCH 2/2] x86/xen: fix memblock

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]

Message-ID: <036855d4-b1d4-444b-92d6-84376ecdffb8@suse.com>
Date: Thu, 25 Jul 2024 11:13:19 +0200
From: Jürgen Groß <jgross@...e.com>
To: Roger Pau Monné <roger.pau@...rix.com>
Cc: xen-devel@...ts.xenproject.org, linux-kernel@...r.kernel.org,
 Boris Ostrovsky <boris.ostrovsky@...cle.com>,
 Thomas Gleixner <tglx@...utronix.de>, Ingo Molnar <mingo@...hat.com>,
 Borislav Petkov <bp@...en8.de>, Dave Hansen <dave.hansen@...ux.intel.com>,
 x86@...nel.org, "H. Peter Anvin" <hpa@...or.com>
Subject: Re: [PATCH 2/2] x86/xen: fix memblock_reserve() usage on PVH

On 25.07.24 10:10, Roger Pau Monné wrote:
> On Thu, Jul 25, 2024 at 10:01:17AM +0200, Jürgen Groß wrote:
>> On 25.07.24 09:31, Roger Pau Monne wrote:
>>> The current usage of memblock_reserve() in init_pvh_bootparams() is done before
>>> the .bss is zeroed, and that used to be fine when
>>> memblock_reserved_init_regions implicitly ended up in the .meminit.data
>>> section.  However after commit 73db3abdca58c memblock_reserved_init_regions
>>> ends up in the .bss section, thus breaking it's usage before the .bss is
>>> cleared.
>>>
>>> Move and rename the call to xen_reserve_extra_memory() so it's done in the
>>> x86_init.oem.arch_setup hook, which gets executed after the .bss has been
>>> zeroed, but before calling e820__memory_setup().
>>>
>>> Fixes: 38620fc4e893 ('x86/xen: attempt to inflate the memory balloon on PVH')
>>> Signed-off-by: Roger Pau Monné <roger.pau@...rix.com>
>>> ---
>>> While the commit that introduced the user-noticeable regression is
>>> 73db3abdca58c, I think 38620fc4e893 should have been more careful to not
>>> initialize the memblock ranges ahead of the .bss zeroing.
>>
>> Reviewed-by: Juergen Gross <jgross@...e.com>
>>
>> I'd prefer using 73db3abdca58c for the fixes tag. Otherwise you'd need to
>> add this patch to the stable branches, too, which is technically not really
>> needed.
>>
>> Additionally I'd like to drop the Fixes: tag from the prereq patch, as this
>> one doesn't really fix anything.
>>
>> I can do both while committing.
> 
> I was unsure myself (as noted in the post-commit notes) about which
> "Fixes:" tag to use.
> 
> Is there anyway that it can be noted that this commit depends on the
> previous change also being present?  For backport reasons, if anyone
> ends up backporting 73db3abdca58c it would also need to pick the two
> patches here.

This is normal business of backporting. This patch added to a stable kernel
would at least result in a build failure. The person doing the backport could
it either fixup locally in the backported patch, or look which patch did setup
the source to make this patch work.

Juergen