From: Marc Zyngier <maz@kernel.org>
To: Fuad Tabba <tabba@google.com>
Cc: kvmarm@lists.linux.dev, linux-arm-kernel@lists.infradead.org,
oliver.upton@linux.dev, will@kernel.org, joey.gouly@arm.com,
suzuki.poulose@arm.com, yuzenghui@huawei.com,
catalin.marinas@arm.com, vladimir.murzin@arm.com
Subject: Re: [PATCH v5 2/9] KVM: arm64: Fix Trace Buffer trap polarity for protected VMs
Date: Wed, 26 Nov 2025 11:47:53 +0000 [thread overview]
Message-ID: <865xaxqal2.wl-maz@kernel.org> (raw)
In-Reply-To: <CA+EHjTwHrLhdHrNSA8f-+bCZ1-QEuNocQQxeiaaost9oLwaG5A@mail.gmail.com>
On Wed, 26 Nov 2025 10:37:57 +0000,
Fuad Tabba <tabba@google.com> wrote:
>
> Hi Marc,
>
> On Wed, 26 Nov 2025 at 10:23, Marc Zyngier <maz@kernel.org> wrote:
> >
> > On Tue, 18 Nov 2025 10:37:59 +0000,
> > Fuad Tabba <tabba@google.com> wrote:
> > >
> > > The E2TB bits in MDCR_EL2 control trapping of Trace Buffer system
> > > register accesses. These accesses are trapped to EL2 when the bits are
> > > clear.
> > >
> > > The trap initialization logic for protected VMs in pvm_init_traps_mdcr()
> > > had the polarity inverted. When a guest did not support the Trace Buffer
> > > feature, the code was setting E2TB. This incorrectly disabled the trap,
> > > potentially allowing a protected guest to access registers for a feature
> > > it was not given.
> > >
> > > Fix this by inverting the operation.
> > >
> > > Fixes: f50758260bff ("KVM: arm64: Group setting traps for protected VMs by control register")
> > > Signed-off-by: Fuad Tabba <tabba@google.com>
> > > ---
> > > arch/arm64/kvm/hyp/nvhe/pkvm.c | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/arch/arm64/kvm/hyp/nvhe/pkvm.c b/arch/arm64/kvm/hyp/nvhe/pkvm.c
> > > index 8d06a246dfd1..f6f8996c4f97 100644
> > > --- a/arch/arm64/kvm/hyp/nvhe/pkvm.c
> > > +++ b/arch/arm64/kvm/hyp/nvhe/pkvm.c
> > > @@ -118,7 +118,7 @@ static void pvm_init_traps_mdcr(struct kvm_vcpu *vcpu)
> > > val |= MDCR_EL2_TTRF;
> > >
> > > if (!kvm_has_feat(kvm, ID_AA64DFR0_EL1, TraceBuffer, IMP))
> > > - val |= MDCR_EL2_E2TB_MASK;
> > > + val &= ~MDCR_EL2_E2TB_MASK;
> >
> > This does not only change the trapping logic (bit 24). It also change
> > the ownership of the buffer (bit 25). I wonder whether you should do
> > something for that, maybe by clearing TRBLIMITR_EL1.E, because
> > otherwise, you keep tracing, but using an EL2 VA. What could possibly
> > go wrong?
> >
> > Overall, I'm very uneasy about TRBE in the context of pKVM.
>
> So should we clear/restore TRBLIMITR_EL1.E on guest entry/exit in
> protected mode?
I think you need something of the sort, yes. Overall, SPE and TRBE
should be aligned on what they are allowed to do, as they are two
sides of the same ugly coin.
M.
--
Without deviation from the norm, progress is not possible.
next prev parent reply other threads:[~2025-11-26 11:48 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-11-18 10:37 [PATCH v5 0/9] KVM: arm64: Fixes for guest CPU feature trapping and enabling Fuad Tabba
2025-11-18 10:37 ` [PATCH v5 1/9] KVM: arm64: Fix Trace Buffer trapping for protected VMs Fuad Tabba
2025-11-18 10:37 ` [PATCH v5 2/9] KVM: arm64: Fix Trace Buffer trap polarity " Fuad Tabba
2025-11-18 11:11 ` Suzuki K Poulose
2025-11-26 10:23 ` Marc Zyngier
2025-11-26 10:29 ` James Clark
2025-11-26 10:36 ` Fuad Tabba
2025-11-26 10:39 ` James Clark
2025-11-26 10:37 ` Fuad Tabba
2025-11-26 11:47 ` Marc Zyngier [this message]
2025-11-26 11:48 ` Fuad Tabba
2025-11-27 15:26 ` James Clark
2025-11-27 15:38 ` Fuad Tabba
2025-11-27 16:06 ` James Clark
2025-11-27 16:23 ` Fuad Tabba
2025-11-18 10:38 ` [PATCH v5 3/9] KVM: arm64: Fix MTE flag initialization " Fuad Tabba
2025-11-18 10:38 ` [PATCH v5 4/9] KVM: arm64: Introduce helper to calculate fault IPA offset Fuad Tabba
2025-11-18 10:38 ` [PATCH v5 5/9] KVM: arm64: Include VM type when checking VM capabilities in pKVM Fuad Tabba
2025-11-26 10:52 ` Marc Zyngier
2025-11-26 11:00 ` Fuad Tabba
2025-11-26 15:36 ` Marc Zyngier
2025-11-26 17:05 ` Fuad Tabba
2025-11-18 10:38 ` [PATCH v5 6/9] KVM: arm64: Do not allow KVM_CAP_ARM_MTE for any guest " Fuad Tabba
2025-11-18 10:38 ` [PATCH v5 7/9] KVM: arm64: Track KVM IOCTLs and their associated KVM caps Fuad Tabba
2025-11-18 10:38 ` [PATCH v5 8/9] KVM: arm64: Check whether a VM IOCTL is allowed in pKVM Fuad Tabba
2025-11-18 10:38 ` [PATCH v5 9/9] KVM: arm64: Prevent host from managing timer offsets for protected VMs Fuad Tabba
2025-11-18 10:39 ` [PATCH v5 0/9] KVM: arm64: Fixes for guest CPU feature trapping and enabling Fuad Tabba
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=865xaxqal2.wl-maz@kernel.org \
--to=maz@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=joey.gouly@arm.com \
--cc=kvmarm@lists.linux.dev \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=oliver.upton@linux.dev \
--cc=suzuki.poulose@arm.com \
--cc=tabba@google.com \
--cc=vladimir.murzin@arm.com \
--cc=will@kernel.org \
--cc=yuzenghui@huawei.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).