From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 97FA3C433F5 for ; Mon, 3 Jan 2022 18:09:57 +0000 (UTC) Received: from localhost ([::1]:59404 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1n4RmO-0008TC-DX for qemu-devel@archiver.kernel.org; Mon, 03 Jan 2022 13:09:56 -0500 Received: from eggs.gnu.org ([209.51.188.92]:49048) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1n4RiT-0003C3-Uu for qemu-devel@nongnu.org; Mon, 03 Jan 2022 13:05:54 -0500 Received: from [2604:1380:4601:e00::1] (port=60308 helo=ams.source.kernel.org) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1n4RiR-0004w8-Cq for qemu-devel@nongnu.org; Mon, 03 Jan 2022 13:05:53 -0500 Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ams.source.kernel.org (Postfix) with ESMTPS id 86D03B8106E; Mon, 3 Jan 2022 18:05:49 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 3C912C36AED; Mon, 3 Jan 2022 18:05:48 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1641233148; bh=RYVO31Qei7SxPtc0IFvMbacM3biwWqbje+VljU3wb48=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=OVtNe2puW0E5M9tUaS9BRnKh3vqG9zVKKmtUcm2z9ZKFsQxCT66qXA/bmc4Kn+OPE 13PiQ05+qo3LxqaOKj2qUdwStVxSjxbm+yzU7u+xtWZVD/Zl0WhdPr662GDfRuPYuJ Ut9YXiQnmwd4H2vMyCf0U7GdHFCQH1Nv/y5AP6Y2X5eFPEnbJzVRbTJEY2iwwbYVef lWS3YEK0Chergv5c/+u0Wbk7DS2aDe6Mo4ErK5v4SA7b00byn42/JnzHMVs+hr+GJX UCG3j/qT5XgLO0gJgn0a1HbSPs3ZLHkKYsDxV56kWqCurpvJe2gR9B5+B37zSNZuVV TFHFrpqpxcNDg== Received: from sofa.misterjones.org ([185.219.108.64] helo=wait-a-minute.misterjones.org) by disco-boy.misterjones.org with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1n4RiM-00Fl1V-AY; Mon, 03 Jan 2022 18:05:46 +0000 Date: Mon, 03 Jan 2022 18:05:41 +0000 Message-ID: <878rvwzocq.wl-maz@kernel.org> From: Marc Zyngier To: Andrew Jones Subject: Re: [PATCH] hw/arm/virt: KVM: Enable PAuth when supported by the host In-Reply-To: <20220103134601.7cumwbza32wja3ei@gator> References: <20211228182347.1025501-1-maz@kernel.org> <20220103134601.7cumwbza32wja3ei@gator> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM-LB/1.14.9 (=?UTF-8?B?R29qxY0=?=) APEL-LB/10.8 EasyPG/1.0.0 Emacs/27.1 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-SA-Exim-Connect-IP: 185.219.108.64 X-SA-Exim-Rcpt-To: drjones@redhat.com, qemu-devel@nongnu.org, kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org, kernel-team@android.com, eric.auger@redhat.com, richard.henderson@linaro.org, peter.maydell@linaro.org X-SA-Exim-Mail-From: maz@kernel.org X-SA-Exim-Scanned: No (on disco-boy.misterjones.org); SAEximRunCond expanded to false X-Host-Lookup-Failed: Reverse DNS lookup failed for 2604:1380:4601:e00::1 (failed) Received-SPF: pass client-ip=2604:1380:4601:e00::1; envelope-from=maz@kernel.org; helo=ams.source.kernel.org X-Spam_score_int: 2 X-Spam_score: 0.2 X-Spam_bar: / X-Spam_report: (0.2 / 5.0 requ) DKIMWL_WL_HIGH=-0.37, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RDNS_NONE=0.793, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Peter Maydell , kvm@vger.kernel.org, Richard Henderson , qemu-devel@nongnu.org, Eric Auger , kernel-team@android.com, kvmarm@lists.cs.columbia.edu Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" Hi Andrew, On Mon, 03 Jan 2022 13:46:01 +0000, Andrew Jones wrote: > > Hi Marc, > > On Tue, Dec 28, 2021 at 06:23:47PM +0000, Marc Zyngier wrote: > > Add basic support for Pointer Authentication when running a KVM > > guest and that the host supports it, loosely based on the SVE > > support. > > > > Although the feature is enabled by default when the host advertises > > it, it is possible to disable it by setting the 'pauth=off' CPU > > property. > > > > Tested on an Apple M1 running 5.16-rc6. > > > > Cc: Eric Auger > > Cc: Andrew Jones > > Cc: Richard Henderson > > Cc: Peter Maydell > > Signed-off-by: Marc Zyngier > > --- > > docs/system/arm/cpu-features.rst | 5 +++++ > > target/arm/cpu.c | 1 + > > target/arm/cpu.h | 1 + > > target/arm/cpu64.c | 36 ++++++++++++++++++++++++++++++++ > > target/arm/kvm.c | 13 ++++++++++++ > > target/arm/kvm64.c | 10 +++++++++ > > target/arm/kvm_arm.h | 7 +++++++ > > 7 files changed, 73 insertions(+) > > > > diff --git a/docs/system/arm/cpu-features.rst b/docs/system/arm/cpu-features.rst > > index 584eb17097..c9e39546a5 100644 > > --- a/docs/system/arm/cpu-features.rst > > +++ b/docs/system/arm/cpu-features.rst > > @@ -211,6 +211,11 @@ the list of KVM VCPU features and their descriptions. > > influence the guest scheduler behavior and/or be > > exposed to the guest userspace. > > > > + pauth Enable or disable ``FEAT_Pauth``, pointer > > + authentication. By default, the feature is enabled > > + with ``-cpu host`` if supported by both the host > > + kernel and the hardware. > > + > > Thanks for considering a documentation update. In this case, though, I > think we should delete the "TCG VCPU Features" pauth paragraph, rather > than add a new "KVM VCPU Features" pauth paragraph. We don't need to > document each CPU feature. We just document complex ones, like sve*, > KVM specific ones (kvm-*), and TCG specific ones (now only pauth-impdef). Sure, works for me. Do we need to keep a trace of the available options? I'm not sure how a user is supposed to find out about those (I always end-up grepping through the code base, and something tells me I'm doing it wrong...). The QMP stuff flies way over my head. > > TCG VCPU Features > > ================= > > > > diff --git a/target/arm/cpu.c b/target/arm/cpu.c > > index a211804fd3..68b09cbc6a 100644 > > --- a/target/arm/cpu.c > > +++ b/target/arm/cpu.c > > @@ -2091,6 +2091,7 @@ static void arm_host_initfn(Object *obj) > > kvm_arm_set_cpu_features_from_host(cpu); > > if (arm_feature(&cpu->env, ARM_FEATURE_AARCH64)) { > > aarch64_add_sve_properties(obj); > > + aarch64_add_pauth_properties(obj); > > } > > #else > > hvf_arm_set_cpu_features_from_host(cpu); > > diff --git a/target/arm/cpu.h b/target/arm/cpu.h > > index e33f37b70a..c6a4d50e82 100644 > > --- a/target/arm/cpu.h > > +++ b/target/arm/cpu.h > > @@ -1076,6 +1076,7 @@ void aarch64_sve_narrow_vq(CPUARMState *env, unsigned vq); > > void aarch64_sve_change_el(CPUARMState *env, int old_el, > > int new_el, bool el0_a64); > > void aarch64_add_sve_properties(Object *obj); > > +void aarch64_add_pauth_properties(Object *obj); > > > > /* > > * SVE registers are encoded in KVM's memory in an endianness-invariant format. > > diff --git a/target/arm/cpu64.c b/target/arm/cpu64.c > > index 15245a60a8..305c0e19fe 100644 > > --- a/target/arm/cpu64.c > > +++ b/target/arm/cpu64.c > > @@ -625,6 +625,42 @@ void aarch64_add_sve_properties(Object *obj) > > #endif > > } > > > > +static bool cpu_arm_get_pauth(Object *obj, Error **errp) > > +{ > > + ARMCPU *cpu = ARM_CPU(obj); > > + return cpu_isar_feature(aa64_pauth, cpu); > > +} > > + > > +static void cpu_arm_set_pauth(Object *obj, bool value, Error **errp) > > +{ > > + ARMCPU *cpu = ARM_CPU(obj); > > + uint64_t t; > > + > > + if (value) { > > + if (!kvm_arm_pauth_supported()) { > > + error_setg(errp, "'pauth' feature not supported by KVM on this host"); > > + } > > + > > + return; > > + } > > + > > + /* > > + * If the host supports PAuth, we only end-up here if the user has > > + * disabled the support, and value is false. > > + */ > > + t = cpu->isar.id_aa64isar1; > > + t = FIELD_DP64(t, ID_AA64ISAR1, APA, value); > > + t = FIELD_DP64(t, ID_AA64ISAR1, GPA, value); > > + t = FIELD_DP64(t, ID_AA64ISAR1, API, value); > > + t = FIELD_DP64(t, ID_AA64ISAR1, GPI, value); > > + cpu->isar.id_aa64isar1 = t; > > +} > > + > > +void aarch64_add_pauth_properties(Object *obj) > > +{ > > + object_property_add_bool(obj, "pauth", cpu_arm_get_pauth, cpu_arm_set_pauth); > > +} > > I think we should try to merge as much as possible between the TCG and KVM > pauth property handling. I think we just need to move the > qdev_property_add_static(DEVICE(obj), &arm_cpu_pauth_property) call into > KVM/TCG common code and then modify arm_cpu_pauth_finalize() to > handle checking KVM for support when KVM is enabled and also to not > look at the impdef property. Happy to merge things more, though using qdev_property_add_static() feels a bit odd here (I have to forcefully replicate the probed state into the cpu->prop_pauth property in order to have a sensible default on KVM). Anyway, I'll post something with this hack, and we add another coat of paint to the bike shed! ;-) > > > + > > void arm_cpu_pauth_finalize(ARMCPU *cpu, Error **errp) > > { > > int arch_val = 0, impdef_val = 0; > > diff --git a/target/arm/kvm.c b/target/arm/kvm.c > > index bbf1ce7ba3..71e2f46ce8 100644 > > --- a/target/arm/kvm.c > > +++ b/target/arm/kvm.c > > @@ -84,6 +84,7 @@ bool kvm_arm_create_scratch_host_vcpu(const uint32_t *cpus_to_try, > > if (vmfd < 0) { > > goto err; > > } > > + > > cpufd = ioctl(vmfd, KVM_CREATE_VCPU, 0); > > if (cpufd < 0) { > > goto err; > > @@ -94,6 +95,18 @@ bool kvm_arm_create_scratch_host_vcpu(const uint32_t *cpus_to_try, > > goto finish; > > } > > > > + /* > > + * Ask for Pointer Authentication if supported. We can't play the > > + * SVE trick of synthetising the ID reg as KVM won't tell us > > + * whether we have the architected or IMPDEF version of PAuth, so > > + * we have to use the actual ID regs. > > + */ > > + if (ioctl(vmfd, KVM_CHECK_EXTENSION, KVM_CAP_ARM_PTRAUTH_ADDRESS) > 0 && > > + ioctl(vmfd, KVM_CHECK_EXTENSION, KVM_CAP_ARM_PTRAUTH_GENERIC) > 0) { > > + init->features[0] |= (1 << KVM_ARM_VCPU_PTRAUTH_ADDRESS | > > + 1 << KVM_ARM_VCPU_PTRAUTH_GENERIC); > > + } > > + > > I think kvm_init() is called prior to kvm_arm_get_host_cpu_features(), > which means we can do this instead > > diff --git a/target/arm/kvm64.c b/target/arm/kvm64.c > index e790d6c9a573..d1512035ac5b 100644 > --- a/target/arm/kvm64.c > +++ b/target/arm/kvm64.c > @@ -521,6 +521,17 @@ bool kvm_arm_get_host_cpu_features(ARMHostCPUFeatures *ahcf) > */ > struct kvm_vcpu_init init = { .target = -1, }; > > + /* > + * Ask for Pointer Authentication if supported. We can't play the > + * SVE trick of synthetising the ID reg as KVM won't tell us > + * whether we have the architected or IMPDEF version of PAuth, so > + * we have to use the actual ID regs. > + */ > + if (kvm_arm_pauth_supported()) { > + init->features[0] |= (1 << KVM_ARM_VCPU_PTRAUTH_ADDRESS | > + 1 << KVM_ARM_VCPU_PTRAUTH_GENERIC); > + } > + > if (!kvm_arm_create_scratch_host_vcpu(cpus_to_try, fdarray, &init)) { > return false; > } > > Assuming I'm right about the call order, then I think I'd like that more. Yup, works nicely, and allows for some further cleanups. > > > > if (init->target == -1) { > > struct kvm_vcpu_init preferred; > > > > diff --git a/target/arm/kvm64.c b/target/arm/kvm64.c > > index e790d6c9a5..95b6902ca0 100644 > > --- a/target/arm/kvm64.c > > +++ b/target/arm/kvm64.c > > @@ -725,6 +725,12 @@ bool kvm_arm_sve_supported(void) > > return kvm_check_extension(kvm_state, KVM_CAP_ARM_SVE); > > } > > > > +bool kvm_arm_pauth_supported(void) > > +{ > > + return (kvm_check_extension(kvm_state, KVM_CAP_ARM_PTRAUTH_ADDRESS) && > > + kvm_check_extension(kvm_state, KVM_CAP_ARM_PTRAUTH_GENERIC)); > > +} > > + > > bool kvm_arm_steal_time_supported(void) > > { > > return kvm_check_extension(kvm_state, KVM_CAP_STEAL_TIME); > > @@ -865,6 +871,10 @@ int kvm_arch_init_vcpu(CPUState *cs) > > assert(kvm_arm_sve_supported()); > > cpu->kvm_init_features[0] |= 1 << KVM_ARM_VCPU_SVE; > > } > > + if (cpu_isar_feature(aa64_pauth, cpu)) { > > + cpu->kvm_init_features[0] |= (1 << KVM_ARM_VCPU_PTRAUTH_ADDRESS | > > + 1 << KVM_ARM_VCPU_PTRAUTH_GENERIC); > > + } > > > > /* Do KVM_ARM_VCPU_INIT ioctl */ > > ret = kvm_arm_vcpu_init(cs); > > diff --git a/target/arm/kvm_arm.h b/target/arm/kvm_arm.h > > index b7f78b5215..c26acf7866 100644 > > --- a/target/arm/kvm_arm.h > > +++ b/target/arm/kvm_arm.h > > @@ -306,6 +306,13 @@ bool kvm_arm_pmu_supported(void); > > */ > > bool kvm_arm_sve_supported(void); > > > > +/** > > + * kvm_arm_pauth_supported: > > + * > > + * Returns true if KVM can enable Pointer Authentication and false otherwise. > > + */ > > +bool kvm_arm_pauth_supported(void); > > + > > If we merge more of the pauth property handling with the TCG code, then > we'll also need a stub in the !CONFIG_KVM section for compiling without > kvm support. Actually, this can go altogether, as it can now be made static in kvm64.c and not be visible outside of the KVM code at all. Thanks a lot for the review and the guidance! M. -- Without deviation from the norm, progress is not possible.