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 DF4EDC433EF for ; Thu, 6 Jan 2022 17:32:50 +0000 (UTC) Received: from localhost ([::1]:34700 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1n5Wd7-0001QU-Iq for qemu-devel@archiver.kernel.org; Thu, 06 Jan 2022 12:32:49 -0500 Received: from eggs.gnu.org ([209.51.188.92]:47690) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1n5WZi-00084j-S0 for qemu-devel@nongnu.org; Thu, 06 Jan 2022 12:29:19 -0500 Received: from ams.source.kernel.org ([145.40.68.75]:54630) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1n5WZg-0000vM-Qp for qemu-devel@nongnu.org; Thu, 06 Jan 2022 12:29:18 -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 79312B82293; Thu, 6 Jan 2022 17:29:14 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 39AE0C36AEB; Thu, 6 Jan 2022 17:29:13 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1641490153; bh=UocvUcOmZWT5ldIPIkaD4rsCvWPMPEMtiSRjhoXcK4k=; h=Date:From:To:Cc:Subject:In-Reply-To:References:From; b=I84+eqrKEXIr4U3kWzkWnd755DYf/g+iNGUfykOkxaf7leo3ZbwkC9N6YQgK6c1uo ozyJyUadP/lSwbMT6BdUDSNn2T/2V6AVOyJcK5bxqyBcfTiIq8lCcJ1G/9bx6zpL/i BvUTwnV4t8/IrOvjzAlAGs6NgnbtcfbuewMdLOkNFRde24pzlbuFDaKhyNdxuvu98F LtjJu88kghAJmEodgFQxT82cRSlMwCIIlig3VHa564B3E5Uq9u37UnSEZky8pshWCh fSor+L6yW54W9IIXolNrNT0k+BSWHM/N7YWN6EQUiOFTHPK1gGC74ux0hwCQzw63hp Ag1l1YoxEEYtA== 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 1n5WZb-00GOfp-6Y; Thu, 06 Jan 2022 17:29:11 +0000 Date: Thu, 06 Jan 2022 17:29:10 +0000 Message-ID: <875yqwvkm1.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: <3db95713-2f05-3c70-82b1-7e12c579d3e2@linaro.org> References: <20220103180507.2190429-1-maz@kernel.org> <87czl5usvb.wl-maz@kernel.org> <3db95713-2f05-3c70-82b1-7e12c579d3e2@linaro.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 Received-SPF: pass client-ip=145.40.68.75; envelope-from=maz@kernel.org; helo=ams.source.kernel.org X-Spam_score_int: -24 X-Spam_score: -2.5 X-Spam_bar: -- X-Spam_report: (-2.5 / 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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham 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" On Thu, 06 Jan 2022 17:20:33 +0000, Richard Henderson wrote: > > On 1/6/22 1:16 AM, Marc Zyngier wrote: > >>> +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. > > Well, no, that's not what that says. It says that *if* both host > flags are set, then both guest flags must be set or both unset. Indeed. But KVM never returns just one flag. It only exposes both or none. > It's probably all academic anyway, because I can't actually imagine a > vendor implementing ADDR and not GENERIC, but in theory we ought to be > able to support a host with only ADDR. We explicitly decided against supporting such a configuration. If someone comes up with such a contraption, guests won't be able to see it. M. -- Without deviation from the norm, progress is not possible.