Received: by 2002:ac0:8845:0:0:0:0:0 with SMTP id g63csp906911img; Tue, 26 Feb 2019 10:35:37 -0800 (PST) X-Google-Smtp-Source: AHgI3IbuhtBmZaWMQ/CYfYPmt4zu7zzGyM/vwBKv/PwuG6pxrzyVJCS7PI3xt9iAMMF1AJoxjWDw X-Received: by 2002:a62:4299:: with SMTP id h25mr27135741pfd.165.1551206137285; Tue, 26 Feb 2019 10:35:37 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1551206137; cv=none; d=google.com; s=arc-20160816; b=hjpTo2+aUJcGLdCuJllMFn4NfOaGR+SDZ03JoCf/azIfQq1PV6NXvcQXi0nxqOZAMz wpn6ZvnVP50MNWHfjXQLirF2ufWKPhRkqqifCqL9pt1v09ampTUk6UIurSWYQLzM1DfJ eoO9dVAcyOFKoHHypZPVDJlCIjoEtLxHnjTCBBwWnNYq0lRR0aegvHby1EWx3OmOWrXQ our17mtDZbk3JqxZvAVGUTqTYmtdS9kAk70LGJa5CGjG0AY5ieLXm6kU0EwhBJv3Q6Ov pKBRfD93ChKTNR2Gl8T703UOnSIah1c+FD8499gF1+PyMafp2fC1ouB9zIVInUBZnWAl rZNg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:references:cc:to:subject; bh=o1LeP8ZSqpBp5H9xzgmApCi87rAgWMlPuws2HqYYQdY=; b=Q0Yt79+ziMtxbFI4DQWoJJkxX4B3vGV/elT1KaZ3uz8lQmDVXvWKvKBWpcLZtk7KRD t0FPmdbgtdgoMCHh7Uj+t8TNEsebsPYk/9w4VEjdl0KERXMeAZ7VIDN6aV7pmGuQGK5W 2TCIw0kJhJ3wAMPaHhosy2xAxH0UyI1sQYQOxl3mL633d6GaD49qRHpUxR6B3sPv/0+Q CVbwyZLyV5Wk2pLEsQF5I3z6s0K2h9Hog4aZkmLgX2SrgnJSKIxec7X3mGQR2Qz7b6LZ 9eOwwJ/zwX6OD2nAnMcTem64HChn3U1Qk9Ne42QFMTPeVdgi+DAzk8aYCltXc++OTzQW wjYQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id m2si2291055pgn.481.2019.02.26.10.35.22; Tue, 26 Feb 2019 10:35:37 -0800 (PST) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729180AbfBZSeo (ORCPT + 99 others); Tue, 26 Feb 2019 13:34:44 -0500 Received: from foss.arm.com ([217.140.101.70]:52132 "EHLO foss.arm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729001AbfBZSen (ORCPT ); Tue, 26 Feb 2019 13:34:43 -0500 Received: from usa-sjc-imap-foss1.foss.arm.com (unknown [10.72.51.249]) by usa-sjc-mx-foss1.foss.arm.com (Postfix) with ESMTP id 3E77F80D; Tue, 26 Feb 2019 10:34:43 -0800 (PST) Received: from [10.1.196.105] (eglon.cambridge.arm.com [10.1.196.105]) by usa-sjc-imap-foss1.foss.arm.com (Postfix) with ESMTPSA id DA4DE3F738; Tue, 26 Feb 2019 10:34:40 -0800 (PST) Subject: Re: [PATCH v6 5/6] arm64/kvm: control accessibility of ptrauth key registers To: Amit Daniel Kachhap Cc: linux-arm-kernel@lists.infradead.org, Christoffer Dall , Marc Zyngier , Catalin Marinas , Will Deacon , Andrew Jones , Dave Martin , Ramana Radhakrishnan , kvmarm@lists.cs.columbia.edu, Kristina Martsenko , linux-kernel@vger.kernel.org, Mark Rutland , Julien Thierry References: <1550568271-5319-1-git-send-email-amit.kachhap@arm.com> <1550568271-5319-6-git-send-email-amit.kachhap@arm.com> From: James Morse Message-ID: Date: Tue, 26 Feb 2019 18:34:39 +0000 User-Agent: Mozilla/5.0 (X11; Linux aarch64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: <1550568271-5319-6-git-send-email-amit.kachhap@arm.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Amit, On 19/02/2019 09:24, Amit Daniel Kachhap wrote: > According to userspace settings, ptrauth key registers are conditionally > present in guest system register list based on user specified flag > KVM_ARM_VCPU_PTRAUTH. > > Reset routines still sets these registers to default values but they are > left like that as they are conditionally accessible (set/get). What problem is this patch solving? I think it's that now we have ptrauth support, we have a glut of new registers visible to user-space. This breaks migration and save/resume if the target machine doesn't have pointer-auth configured, even if the guest wasn't using it. Because we've got a VCPU bit, we can be smarter about this, and only expose the registers if user-space was able to enable ptrauth. > --- > This patch needs patch [1] by Dave Martin and adds feature to manage accessibility in a scalable way. > > [1]: https://lore.kernel.org/linux-arm-kernel/1547757219-19439-13-git-send-email-Dave.Martin@arm.com/ This is v4. Shortly before you posted this there was a v5 (but the subject changed, easily missed). V5 has subsequently been reviewed. As we can't have both, could you rebase onto that v5 so that there is one way of doing this? (in general if you could re-post the version you develop/tested with then it makes it clear what is going on) > diff --git a/Documentation/arm64/pointer-authentication.txt b/Documentation/arm64/pointer-authentication.txt > index 0529a7d..996e435 100644 > --- a/Documentation/arm64/pointer-authentication.txt > +++ b/Documentation/arm64/pointer-authentication.txt > @@ -87,3 +87,7 @@ created by passing a flag (KVM_ARM_VCPU_PTRAUTH) requesting this feature > to be enabled. Without this flag, pointer authentication is not enabled > in KVM guests and attempted use of the feature will result in an UNDEFINED > exception being injected into the guest. > + > +Additionally, when KVM_ARM_VCPU_PTRAUTH is not set then KVM will filter > +out the Pointer Authentication system key registers from KVM_GET/SET_REG_* > +ioctls. > diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c > index f7bcc60..c2f4974 100644 > --- a/arch/arm64/kvm/sys_regs.c > +++ b/arch/arm64/kvm/sys_regs.c > @@ -1005,8 +1005,13 @@ static bool trap_ptrauth(struct kvm_vcpu *vcpu, > return false; > } > > +static bool check_ptrauth(const struct kvm_vcpu *vcpu, const struct sys_reg_desc *rd) > +{ > + return kvm_arm_vcpu_ptrauth_allowed(vcpu); > +} > + > #define __PTRAUTH_KEY(k) \ > - { SYS_DESC(SYS_## k), trap_ptrauth, reset_unknown, k } > + { SYS_DESC(SYS_## k), trap_ptrauth, reset_unknown, k , .check_present = check_ptrauth} Looks good. I'm pretty sure the changes due to Dave's v5 map neatly. Thanks, James