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: <hzif6tde7p5q3fyrmu5got25rwuiuea5pzbf2ubbqdfc5uof4y@7waunf3d65fo>
Date: Sun, 7 Sep 2025 17:39:53 +0800
From: Wei-Lin Chang <r09922117@...e.ntu.edu.tw>
To: Marc Zyngier <maz@...nel.org>
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 Mon, Sep 01, 2025 at 12:06:22PM +0100, Marc Zyngier wrote:
> 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.

Ah yes I get it now! Make the shadow S2 more TLB-like and use it to
dictate our actions instead of looking for info in the guest S2 by
rewalking it.

> 
> 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
> 

Makes sense. Yes with this we'll have to distinguish the reason of the fault.

> > > 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.

Got it! Thanks for helping me understand this!

Thanks,
Wei-Lin Chang

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