linux-kernel - Re: [PATCH] KVM: arm64: nv: Allow shadow stage 2 read fault

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: <864itme8k1.wl-maz@kernel.org>
Date: Mon, 01 Sep 2025 12:06:22 +0100
From: Marc Zyngier <maz@...nel.org>
To: Wei-Lin Chang <r09922117@...e.ntu.edu.tw>
Cc: linux-arm-kernel@...ts.infradead.org,
	kvmarm@...ts.linux.dev,
	linux-kernel@...r.kernel.org,
	Oliver Upton <oliver.upton@...ux.dev>,
	Joey Gouly <joey.gouly@....com>,
	Suzuki K Poulose <suzuki.poulose@....com>,
	Zenghui Yu <yuzenghui@...wei.com>,
	Catalin Marinas <catalin.marinas@....com>,
	Will Deacon <will@...nel.org>
Subject: Re: [PATCH] KVM: arm64: nv: Allow shadow stage 2 read fault

On Tue, 26 Aug 2025 14:49:27 +0100,
Wei-Lin Chang <r09922117@...e.ntu.edu.tw> wrote:
> 
> Hi Marc,
> 
> On Fri, Aug 22, 2025 at 10:40:07AM +0100, Marc Zyngier wrote:
> >
> > This would imply taking the guest's S2 permission at face value, and
> > only drop W permission when the memslot is RO -- you'd then need to
> > keep track of the original W bit somewhere. And that's where things
> > become much harder, because KVM can decide to remap arbitrary ranges
> > of IPA space as RO, which implies we should track the W bit at all
> > times, most likely as one of the SW bits in the PTE.
> 
> But sorry, I struggle to understand this paragraph after reading it many
> times, probably my experience with the code isn't enough for me to make
> the connection. Why are we talking about the W bit suddenly?
> If you don't mind, can you reword what's discussed here?
> I only very vaguely get that there will be 2 W bits, one from what L1 set,
> and one from the L0 memslot, if I didn't completely miss the point..

Sorry, I quickly drifted into something related.

My take on this category of problems is that we're better off always
using the permissions that the guest gives us. This is the scheme that
we have adopted with VNCR. It means we wouldn't have to rewalk the
guest S2 on permission fault, since we'd be guaranteed to have the
latest update.

However, S2 management implies that a S2 mapping can be made read-only
at any point (dirty log, for example). Which means that on a
permission fault, you'd need to find out whether the page is R/O
because the guest said so, or because the host decided to make it so.

Which means that somehow you need to work out why you have taken a
permission fault. You can either

- rewalk the guest S2 as if you missed in the TLB
- or keep a copy of the W bit in the shadow SW

> > We'll need exactly that if we ever want to implement the
> > Hardware-managed Dirty Bit, but I have the feeling we need an actual
> > design for this, and not a quick hack. Your approach is therefore the
> > correct one for the time being.

And that's why I brought this up: to support HD in the guest S2, we
need to mark the full shadow S2 as R/O, and update the guest S2 on the
back of that fault.

Thanks,

	M.

-- 
Without deviation from the norm, progress is not possible.