linux-kernel - Re: [PATCH] KVM: arm64: Fix the upper limit of the walker range

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: <e79c78a7-24a3-42e6-a217-ec64f8320e91@arm.com>
Date: Thu, 16 Jan 2025 13:49:54 +0000
From: Suzuki K Poulose <suzuki.poulose@....com>
To: Marc Zyngier <maz@...nel.org>, Sebastian Ene <sebastianene@...gle.com>,
 Mark Brown <broonie@...nel.org>
Cc: catalin.marinas@....com, joey.gouly@....com, kvmarm@...ts.linux.dev,
 linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org,
 oliver.upton@...ux.dev, will@...nel.org, Aishwarya.TCV@....com
Subject: Re: [PATCH] KVM: arm64: Fix the upper limit of the walker range

On 16/01/2025 10:55, Marc Zyngier wrote:
> On Thu, 16 Jan 2025 01:16:40 +0000,
> Mark Brown <broonie@...nel.org> wrote:
>>
>> On Tue, Jan 14, 2025 at 02:50:51PM +0000, Sebastian Ene wrote:
>>
>>> Prevent the walker from running into weeds when walking an
>>> entire address range.
>>
>> The KVM page_fault_test selftest started failing in next-20250115 on
>> at least n1sdp and TX2 in VHE mode and a bisect seems to point to this
>> change.  The bisect only just finished, I've done no further
>> investigation.
>>
>> When the test fails it generates backtraces like that below:
> 
> [...]
> 
> Thanks for the heads up.
> 
> Given how close we are to the merge window opening, I've dropped this
> patch from -next.
> 
> Seb: it looks this breaks a bunch of existing assumptions. Let's
> revisit this before -rc1, if possible.
In kvm_pgtable_walk() we set the walk_data.end to PAGE_ALIGNED(start + 
size), where size is BIT(ia_size) and start = 0, for 
kvm_pgtable_stage2_destroy().

And subtracting the limit in _kvm_pgtable_walk makes things go bad,
  returning -ERANGE.
Given the kvm_pgtable_walk() passes the "end" as the top address (not 
including it), and is always PAGE_ALIGNED, we should probably leave 
things as it is in the code.


Cheers
Suzuki


> 
> Thanks,
> 
> 	M.
>