From: Marc Zyngier <maz@kernel.org>
To: Joey Gouly <joey.gouly@arm.com>
Cc: kvmarm@lists.linux.dev, kvm@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
James Morse <james.morse@arm.com>,
Suzuki K Poulose <suzuki.poulose@arm.com>,
Oliver Upton <oliver.upton@linux.dev>,
Zenghui Yu <yuzenghui@huawei.com>, Will Deacon <will@kernel.org>,
Catalin Marinas <catalin.marinas@arm.com>
Subject: Re: [PATCH 01/13] KVM: arm64: Harden __ctxt_sys_reg() against out-of-range values
Date: Tue, 20 Feb 2024 11:57:04 +0000 [thread overview]
Message-ID: <8634tn4acv.wl-maz@kernel.org> (raw)
In-Reply-To: <20240220112031.GA16168@e124191.cambridge.arm.com>
On Tue, 20 Feb 2024 11:20:31 +0000,
Joey Gouly <joey.gouly@arm.com> wrote:
>
> On Mon, Feb 19, 2024 at 09:20:02AM +0000, Marc Zyngier wrote:
> > The unsuspecting kernel tinkerer can be easily confused into
> > writing something that looks like this:
> >
> > ikey.lo = __vcpu_sys_reg(vcpu, SYS_APIAKEYLO_EL1);
> >
> > which seems vaguely sensible, until you realise that the second
> > parameter is the encoding of a sysreg, and not the index into
> > the vcpu sysreg file... Debugging what happens in this case is
>
> type safety :(
Are you advocating for making everything a struct? Or something else?
>
> > an interesting exercise in head<->wall interactions.
> >
> > As they often say: "Any resemblance to actual persons, living
> > or dead, or actual events is purely coincidental".
> >
> > In order to save people's time, add some compile-time hardening
> > that will at least weed out the "stupidly out of range" values.
> > This will *not* catch anything that isn't a compile-time constant.
> >
> > Signed-off-by: Marc Zyngier <maz@kernel.org>
> > ---
> > arch/arm64/include/asm/kvm_host.h | 9 ++++++++-
> > 1 file changed, 8 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
> > index 181fef12e8e8..a5ec4c7d3966 100644
> > --- a/arch/arm64/include/asm/kvm_host.h
> > +++ b/arch/arm64/include/asm/kvm_host.h
> > @@ -895,7 +895,7 @@ struct kvm_vcpu_arch {
> > * Don't bother with VNCR-based accesses in the nVHE code, it has no
> > * business dealing with NV.
> > */
> > -static inline u64 *__ctxt_sys_reg(const struct kvm_cpu_context *ctxt, int r)
> > +static inline u64 *___ctxt_sys_reg(const struct kvm_cpu_context *ctxt, int r)
>
> When in doubt, add more underscores!
That's the one true way.
>
> > {
> > #if !defined (__KVM_NVHE_HYPERVISOR__)
> > if (unlikely(cpus_have_final_cap(ARM64_HAS_NESTED_VIRT) &&
> > @@ -905,6 +905,13 @@ static inline u64 *__ctxt_sys_reg(const struct kvm_cpu_context *ctxt, int r)
> > return (u64 *)&ctxt->sys_regs[r];
> > }
> >
> > +#define __ctxt_sys_reg(c,r) \
> > + ({ \
> > + BUILD_BUG_ON(__builtin_constant_p(r) && \
> > + (r) >= NR_SYS_REGS); \
> > + ___ctxt_sys_reg(c, r); \
> > + })
>
> I'm assuming the extra macro layer is to try make __builtin_constant_p() as
> effective as possible? Otherwise maybe it relies on the compiler inling the
> ___ctxt_sys_reg() function?
It's not about efficiency. It's about making it *work*. Otherwise,
lack of inlining will screw you over, and you may not check anything.
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
WARNING: multiple messages have this Message-ID (diff)
From: Marc Zyngier <maz@kernel.org>
To: Joey Gouly <joey.gouly@arm.com>
Cc: kvmarm@lists.linux.dev, kvm@vger.kernel.org,
linux-arm-kernel@lists.infradead.org,
James Morse <james.morse@arm.com>,
Suzuki K Poulose <suzuki.poulose@arm.com>,
Oliver Upton <oliver.upton@linux.dev>,
Zenghui Yu <yuzenghui@huawei.com>, Will Deacon <will@kernel.org>,
Catalin Marinas <catalin.marinas@arm.com>
Subject: Re: [PATCH 01/13] KVM: arm64: Harden __ctxt_sys_reg() against out-of-range values
Date: Tue, 20 Feb 2024 11:57:04 +0000 [thread overview]
Message-ID: <8634tn4acv.wl-maz@kernel.org> (raw)
In-Reply-To: <20240220112031.GA16168@e124191.cambridge.arm.com>
On Tue, 20 Feb 2024 11:20:31 +0000,
Joey Gouly <joey.gouly@arm.com> wrote:
>
> On Mon, Feb 19, 2024 at 09:20:02AM +0000, Marc Zyngier wrote:
> > The unsuspecting kernel tinkerer can be easily confused into
> > writing something that looks like this:
> >
> > ikey.lo = __vcpu_sys_reg(vcpu, SYS_APIAKEYLO_EL1);
> >
> > which seems vaguely sensible, until you realise that the second
> > parameter is the encoding of a sysreg, and not the index into
> > the vcpu sysreg file... Debugging what happens in this case is
>
> type safety :(
Are you advocating for making everything a struct? Or something else?
>
> > an interesting exercise in head<->wall interactions.
> >
> > As they often say: "Any resemblance to actual persons, living
> > or dead, or actual events is purely coincidental".
> >
> > In order to save people's time, add some compile-time hardening
> > that will at least weed out the "stupidly out of range" values.
> > This will *not* catch anything that isn't a compile-time constant.
> >
> > Signed-off-by: Marc Zyngier <maz@kernel.org>
> > ---
> > arch/arm64/include/asm/kvm_host.h | 9 ++++++++-
> > 1 file changed, 8 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/arm64/include/asm/kvm_host.h b/arch/arm64/include/asm/kvm_host.h
> > index 181fef12e8e8..a5ec4c7d3966 100644
> > --- a/arch/arm64/include/asm/kvm_host.h
> > +++ b/arch/arm64/include/asm/kvm_host.h
> > @@ -895,7 +895,7 @@ struct kvm_vcpu_arch {
> > * Don't bother with VNCR-based accesses in the nVHE code, it has no
> > * business dealing with NV.
> > */
> > -static inline u64 *__ctxt_sys_reg(const struct kvm_cpu_context *ctxt, int r)
> > +static inline u64 *___ctxt_sys_reg(const struct kvm_cpu_context *ctxt, int r)
>
> When in doubt, add more underscores!
That's the one true way.
>
> > {
> > #if !defined (__KVM_NVHE_HYPERVISOR__)
> > if (unlikely(cpus_have_final_cap(ARM64_HAS_NESTED_VIRT) &&
> > @@ -905,6 +905,13 @@ static inline u64 *__ctxt_sys_reg(const struct kvm_cpu_context *ctxt, int r)
> > return (u64 *)&ctxt->sys_regs[r];
> > }
> >
> > +#define __ctxt_sys_reg(c,r) \
> > + ({ \
> > + BUILD_BUG_ON(__builtin_constant_p(r) && \
> > + (r) >= NR_SYS_REGS); \
> > + ___ctxt_sys_reg(c, r); \
> > + })
>
> I'm assuming the extra macro layer is to try make __builtin_constant_p() as
> effective as possible? Otherwise maybe it relies on the compiler inling the
> ___ctxt_sys_reg() function?
It's not about efficiency. It's about making it *work*. Otherwise,
lack of inlining will screw you over, and you may not check anything.
Thanks,
M.
--
Without deviation from the norm, progress is not possible.
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2024-02-20 11:57 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-19 9:20 [PATCH 00/13] KVM/arm64: Add NV support for ERET and PAuth Marc Zyngier
2024-02-19 9:20 ` Marc Zyngier
2024-02-19 9:20 ` [PATCH 01/13] KVM: arm64: Harden __ctxt_sys_reg() against out-of-range values Marc Zyngier
2024-02-19 9:20 ` Marc Zyngier
2024-02-20 11:20 ` Joey Gouly
2024-02-20 11:20 ` Joey Gouly
2024-02-20 11:57 ` Marc Zyngier [this message]
2024-02-20 11:57 ` Marc Zyngier
2024-02-20 13:17 ` Joey Gouly
2024-02-20 13:17 ` Joey Gouly
2024-02-19 9:20 ` [PATCH 02/13] KVM: arm64: Clarify ESR_ELx_ERET_ISS_ERET* Marc Zyngier
2024-02-19 9:20 ` Marc Zyngier
2024-02-20 11:31 ` Joey Gouly
2024-02-20 11:31 ` Joey Gouly
2024-02-20 12:29 ` Marc Zyngier
2024-02-20 12:29 ` Marc Zyngier
2024-02-20 13:23 ` Joey Gouly
2024-02-20 13:23 ` Joey Gouly
2024-02-20 13:41 ` Marc Zyngier
2024-02-20 13:41 ` Marc Zyngier
2024-02-20 15:18 ` Joey Gouly
2024-02-20 15:18 ` Joey Gouly
2024-02-19 9:20 ` [PATCH 03/13] KVM: arm64: nv: Drop VCPU_HYP_CONTEXT flag Marc Zyngier
2024-02-19 9:20 ` Marc Zyngier
2024-02-20 11:58 ` Joey Gouly
2024-02-20 11:58 ` Joey Gouly
2024-02-19 9:20 ` [PATCH 04/13] KVM: arm64: nv: Configure HCR_EL2 for FEAT_NV2 Marc Zyngier
2024-02-19 9:20 ` Marc Zyngier
2024-02-20 15:16 ` Joey Gouly
2024-02-20 15:16 ` Joey Gouly
2024-02-20 15:41 ` Marc Zyngier
2024-02-20 15:41 ` Marc Zyngier
2024-02-19 9:20 ` [PATCH 05/13] KVM: arm64: nv: Add trap forwarding for ERET and SMC Marc Zyngier
2024-02-19 9:20 ` Marc Zyngier
2024-02-22 11:05 ` Joey Gouly
2024-02-22 11:05 ` Joey Gouly
2024-02-19 9:20 ` [PATCH 06/13] KVM: arm64: nv: Fast-track 'InHost' exception returns Marc Zyngier
2024-02-19 9:20 ` Marc Zyngier
2024-02-19 9:20 ` [PATCH 07/13] KVM: arm64: nv: Honor HFGITR_EL2.ERET being set Marc Zyngier
2024-02-19 9:20 ` Marc Zyngier
2024-02-19 9:20 ` [PATCH 08/13] KVM: arm64: nv: Handle HCR_EL2.{API,APK} independantly Marc Zyngier
2024-02-19 9:20 ` Marc Zyngier
2024-02-19 9:20 ` [PATCH 09/13] KVM: arm64: nv: Reinject PAC exceptions caused by HCR_EL2.API==0 Marc Zyngier
2024-02-19 9:20 ` Marc Zyngier
2024-02-19 9:20 ` [PATCH 10/13] KVM: arm64: nv: Add kvm_has_pauth() helper Marc Zyngier
2024-02-19 9:20 ` Marc Zyngier
2024-02-19 9:20 ` [PATCH 11/13] KVM: arm64: nv: Add emulation for ERETAx instructions Marc Zyngier
2024-02-19 9:20 ` Marc Zyngier
2024-02-19 9:20 ` [PATCH 12/13] KVM: arm64: nv: Handle ERETA[AB] instructions Marc Zyngier
2024-02-19 9:20 ` Marc Zyngier
2024-02-19 9:20 ` [PATCH 13/13] KVM: arm64: nv: Advertise support for PAuth Marc Zyngier
2024-02-19 9:20 ` Marc Zyngier
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=8634tn4acv.wl-maz@kernel.org \
--to=maz@kernel.org \
--cc=catalin.marinas@arm.com \
--cc=james.morse@arm.com \
--cc=joey.gouly@arm.com \
--cc=kvm@vger.kernel.org \
--cc=kvmarm@lists.linux.dev \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=oliver.upton@linux.dev \
--cc=suzuki.poulose@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.