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 C2A4EC433EF for ; Thu, 6 Jan 2022 09:18:01 +0000 (UTC) Received: from localhost ([::1]:39664 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1n5OuG-0008Nj-MS for qemu-devel@archiver.kernel.org; Thu, 06 Jan 2022 04:18:00 -0500 Received: from eggs.gnu.org ([209.51.188.92]:43956) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1n5Osn-0006uB-1p for qemu-devel@nongnu.org; Thu, 06 Jan 2022 04:16:29 -0500 Received: from [2604:1380:4641:c500::1] (port=33430 helo=dfw.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 1n5Osk-0005Jx-BH for qemu-devel@nongnu.org; Thu, 06 Jan 2022 04:16:28 -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 dfw.source.kernel.org (Postfix) with ESMTPS id D187161AD8; Thu, 6 Jan 2022 09:16:15 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 468B4C36AE5; Thu, 6 Jan 2022 09:16:15 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1641460575; bh=mdH8wLVZw9IC0axvrDBOf6u/F9++nH65H2Vt9jCeYSw=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=SQjF2ZDmhHDLNU8PSy++u2GW+aV5bYBZIvBxoyy64NK/p1qEKEZS/h+XSTUIQc+6f o/NRsYCnzIAA5VFr6oPA4RVEI7Gfl1n2uoVb8ttjuFAyVRZFVm3kR9/v+Ryl4UPY77 nfRqyeUuULHcuDdR7uq2AcSfTIHhLoSQeKmaWw24CtOnMPBxd57odRQ6U78/P+oLFP E3uDVxRESpx4SIBCr1z96gI8+upvhVGQeuQZw2+jWxdciYe2ilxWBfapj5quTT1qqS cafpQWWJln0aRWs+G/qJgURciNlHE2w6owB7qYAG0LEy0IfOmGSZycO96G5Jym9Je0 K50GjjtSua87w== Received: from sofa.misterjones.org ([185.219.108.64] helo=why.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 1n5OsW-00GJrc-Rh; Thu, 06 Jan 2022 09:16:12 +0000 Date: Thu, 06 Jan 2022 09:16:08 +0000 Message-ID: <87czl5usvb.wl-maz@kernel.org> From: Marc Zyngier To: Richard Henderson Subject: Re: [PATCH v2] hw/arm/virt: KVM: Enable PAuth when supported by the host In-Reply-To: References: <20220103180507.2190429-1-maz@kernel.org> 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: richard.henderson@linaro.org, qemu-devel@nongnu.org, kvmarm@lists.cs.columbia.edu, kvm@vger.kernel.org, kernel-team@android.com, eric.auger@redhat.com, drjones@redhat.com, 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:4641:c500::1 (failed) Received-SPF: pass client-ip=2604:1380:4641:c500::1; envelope-from=maz@kernel.org; helo=dfw.source.kernel.org X-Spam_score_int: -16 X-Spam_score: -1.7 X-Spam_bar: - X-Spam_report: (-1.7 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.372, 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 , Andrew Jones , kvm@vger.kernel.org, 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 Richard, On Wed, 05 Jan 2022 21:36:55 +0000, Richard Henderson wrote: > > On 1/3/22 10:05 AM, Marc Zyngier wrote: > > - /* > > - * KVM does not support modifications to this feature. > > - * We have not registered the cpu properties when KVM > > - * is in use, so the user will not be able to set them. > > - */ > > - if (!kvm_enabled()) { > > - arm_cpu_pauth_finalize(cpu, &local_err); > > - if (local_err != NULL) { > > + arm_cpu_pauth_finalize(cpu, &local_err); > > + if (local_err != NULL) { > > error_propagate(errp, local_err); > > return; > > - } > > - } > > + } > > Looks like the indentation is off? Most probably. I only just discovered how to use the QEMU style for Emacs, and was indenting things by hand before that (yes, pretty painful and likely to lead to issues (there is a TAB instead of a set of spaces there...). > > > +static 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)); > > +} > > Do we really need to have them both set to play the game? Given that > the only thing that happens is that we disable whatever host support > exists, can we have "pauth enabled" mean whatever subset the host has? The host will always expose either both features or none, and that's part of the ABI. From the bit of kernel documentation located in Documentation/virt/kvm/api.rst: 4.82 KVM_ARM_VCPU_INIT ---------------------- [...] - KVM_ARM_VCPU_PTRAUTH_ADDRESS: Enables Address Pointer authentication for arm64 only. Depends on KVM_CAP_ARM_PTRAUTH_ADDRESS. If KVM_CAP_ARM_PTRAUTH_ADDRESS and KVM_CAP_ARM_PTRAUTH_GENERIC are both present, then both KVM_ARM_VCPU_PTRAUTH_ADDRESS and KVM_ARM_VCPU_PTRAUTH_GENERIC must be requested or neither must be requested. - KVM_ARM_VCPU_PTRAUTH_GENERIC: Enables Generic Pointer authentication for arm64 only. Depends on KVM_CAP_ARM_PTRAUTH_GENERIC. If KVM_CAP_ARM_PTRAUTH_ADDRESS and KVM_CAP_ARM_PTRAUTH_GENERIC are both present, then both KVM_ARM_VCPU_PTRAUTH_ADDRESS and KVM_ARM_VCPU_PTRAUTH_GENERIC must be requested or neither must be requested. KVM will reject the initialisation if only one of the features is requested, so checking and enabling both makes sense to me. > > > @@ -521,6 +527,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 > > synthesizing Yup. > > > + * 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); > > Align the two 1's. Gah, another of these... Will fix. > > Otherwise, it looks good. Thanks, M. -- Without deviation from the norm, progress is not possible.