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;
From:   Dave P Martin <Dave.Martin@arm.com>
To:     Marc Zyngier <Marc.Zyngier@arm.com>
CC:     Amit Kachhap <Amit.Kachhap@arm.com>,
        "linux-arm-kernel@lists.infradead.org" 
        <linux-arm-kernel@lists.infradead.org>,
        Catalin Marinas <Catalin.Marinas@arm.com>,
        Will Deacon <Will.Deacon@arm.com>,
        Kristina Martsenko <Kristina.Martsenko@arm.com>,
        "kvmarm@lists.cs.columbia.edu" <kvmarm@lists.cs.columbia.edu>,
        Ramana Radhakrishnan <Ramana.Radhakrishnan@arm.com>,
        "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v10 2/5] KVM: arm/arm64: context-switch ptrauth registers
Thread-Topic: [PATCH v10 2/5] KVM: arm/arm64: context-switch ptrauth registers
Thread-Index: AQHU+Y8LLN0qY1301kuXxM6+yNZcpqZLY9CA///9TgCAAABZgA==
Date:   Wed, 24 Apr 2019 14:30:43 +0000
Message-ID: <20190424143041.GF17864@e103592.cambridge.arm.com>
References: <1555994558-26349-1-git-send-email-amit.kachhap@arm.com>
 <1555994558-26349-3-git-send-email-amit.kachhap@arm.com>
 <20190424133903.GU3567@e103592.cambridge.arm.com>
 <4e475e1f-80f2-372a-2c16-a03ac947525a@arm.com>
In-Reply-To: <4e475e1f-80f2-372a-2c16-a03ac947525a@arm.com>
Accept-Language: en-GB, en-US
Content-Language: en-US
user-agent: Mutt/1.5.23 (2014-03-12)
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: 916b8688-a312-4c17-e514-08d6c8c16ee0
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0;PCL:0;RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(4618075)(2017052603328)(7193020);SRVR:VE1PR08MB5085;
x-ms-traffictypediagnostic: VE1PR08MB5085:
x-microsoft-antispam-prvs: <VE1PR08MB5085D8AF1C7344C2A6378B6CFE3C0@VE1PR08MB5085.eurprd08.prod.outlook.com>
x-forefront-prvs: 00179089FD
x-forefront-antispam-report: SFV:NSPM;SFS:(10009020)(376002)(366004)(39860400002)(396003)(346002)(136003)(40434004)(199004)(189003)(7736002)(6862004)(25786009)(14444005)(66556008)(6246003)(58126008)(66476007)(71200400001)(53936002)(99286004)(5024004)(76176011)(316002)(256004)(6436002)(71190400001)(5660300002)(6486002)(73956011)(54906003)(66446008)(6636002)(64756008)(52116002)(229853002)(305945005)(1076003)(4326008)(446003)(476003)(26005)(486006)(386003)(53546011)(81166006)(8676002)(102836004)(2906002)(33656002)(3846002)(8936002)(11346002)(97736004)(68736007)(6506007)(81156014)(66946007)(14454004)(186003)(6116002)(478600001)(66066001)(93886005)(72206003)(6512007)(86362001);DIR:OUT;SFP:1101;SCL:1;SRVR:VE1PR08MB5085;H:VE1PR08MB4847.eurprd08.prod.outlook.com;FPR:;SPF:None;LANG:en;PTR:InfoNoRecords;A:1;MX:1;
received-spf: None (protection.outlook.com: arm.com does not designate
 permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: y9L11XgMbGaXkhJj5h78+kuubTExF8JPftRRKhMrmyYogpb2Bh9fvQUsVBtKM4BlC9WuJ3v/AmLlgn64jR9Ea4v3zScs+BW+Qcciw7YQGzXWT/WRokFbtfwm6PC26CdHT0uZHVbBYRuJ5VSvScrr+nPiRflwk+Fq0X3JyPxMLNJTYZ7mE9pr7T9jENROTnZeHa7xnqrOK9qnzzAGvRzbl9PaIyLoR0+LhxFcqkjcfIP3evH3GXx383pzmd/oltgkl//4AIzCCuPaL7IfF0HdNUF3VWf6AEIflkE+FZ+VhvlVuCbGldxewqCC+y+pVIlaFpz2TTtxZPHC2UHc75s7usQlLwHU5Qt7Wi1LUUXbzQ99vdQmaqek3sCQhGOHhhybc85PFqXlq+3CaVU4DxbQSOZFkEom5ltVwSY6Etl6yVs=
Content-Type: text/plain; charset="us-ascii"
Content-ID: <D2A58B168B45CC428E0A9CEAA7BD1BB8@eurprd08.prod.outlook.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-OriginatorOrg: arm.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 916b8688-a312-4c17-e514-08d6c8c16ee0
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Apr 2019 14:30:43.6341
 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VE1PR08MB5085
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Wed, Apr 24, 2019 at 03:29:26PM +0100, Marc Zyngier wrote:
> On 24/04/2019 14:39, Dave Martin wrote:
> > On Tue, Apr 23, 2019 at 10:12:35AM +0530, Amit Daniel Kachhap wrote:
> >> From: Mark Rutland <mark.rutland@arm.com>
> >>
> >> When pointer authentication is supported, a guest may wish to use it.
> >> This patch adds the necessary KVM infrastructure for this to work, wit=
h
> >> a semi-lazy context switch of the pointer auth state.
> >>
> >> Pointer authentication feature is only enabled when VHE is built
> >> in the kernel and present in the CPU implementation so only VHE code
> >> paths are modified.
> >>
> >> When we schedule a vcpu, we disable guest usage of pointer
> >> authentication instructions and accesses to the keys. While these are
> >> disabled, we avoid context-switching the keys. When we trap the guest
> >> trying to use pointer authentication functionality, we change to eager=
ly
> >> context-switching the keys, and enable the feature. The next time the
> >> vcpu is scheduled out/in, we start again. However the host key save is
> >> optimized and implemented inside ptrauth instruction/register access
> >> trap.
> >>
> >> Pointer authentication consists of address authentication and generic
> >> authentication, and CPUs in a system might have varied support for
> >> either. Where support for either feature is not uniform, it is hidden
> >> from guests via ID register emulation, as a result of the cpufeature
> >> framework in the host.
> >>
> >> Unfortunately, address authentication and generic authentication canno=
t
> >> be trapped separately, as the architecture provides a single EL2 trap
> >> covering both. If we wish to expose one without the other, we cannot
> >> prevent a (badly-written) guest from intermittently using a feature
> >> which is not uniformly supported (when scheduled on a physical CPU whi=
ch
> >> supports the relevant feature). Hence, this patch expects both type of
> >> authentication to be present in a cpu.
> >>
> >> This switch of key is done from guest enter/exit assembly as preparati=
on
> >> for the upcoming in-kernel pointer authentication support. Hence, thes=
e
> >> key switching routines are not implemented in C code as they may cause
> >> pointer authentication key signing error in some situations.
> >>
> >> Signed-off-by: Mark Rutland <mark.rutland@arm.com>
> >> [Only VHE, key switch in full assembly, vcpu_has_ptrauth checks
> >> , save host key in ptrauth exception trap]
> >> Signed-off-by: Amit Daniel Kachhap <amit.kachhap@arm.com>
> >> Reviewed-by: Julien Thierry <julien.thierry@arm.com>
> >> Cc: Marc Zyngier <marc.zyngier@arm.com>
> >> Cc: Christoffer Dall <christoffer.dall@arm.com>
> >> Cc: kvmarm@lists.cs.columbia.edu
> >> ---
> >> Changes since v9:
> >>
> >> * Removed hardcoding of enum values[Mark Zyngier].
> >> * Changed kvm_ptrauth_asm.h to kvm_ptrauth.h[Mark Zyngier].
> >> * Removed macro __ptrauth_save_state and applied inline [Marc Zyngier]=
.
> >> * Moved kvm_arm_vcpu_ptrauth_setup_lazy, kvm_arm_vcpu_ptrauth_enable a=
nd
> >>   kvm_arm_vcpu_ptrauth_disable from *.c to kvm_emulate.h file [Marc Zy=
ngier].
> >> * Added/Modified comments at few places [Marc Zyngier].

[...]

> >  if (id =3D=3D SYS_ID_AA64PFR0_EL1 && !vcpu_has_sve(vcpu)) {
> >  val &=3D ~(0xfUL << ID_AA64PFR0_SVE_SHIFT);
> > -} else if (id =3D=3D SYS_ID_AA64ISAR1_EL1) {
> > -const u64 ptrauth_mask =3D (0xfUL << ID_AA64ISAR1_APA_SHIFT) |
> > - (0xfUL << ID_AA64ISAR1_API_SHIFT) |
> > - (0xfUL << ID_AA64ISAR1_GPA_SHIFT) |
> > - (0xfUL << ID_AA64ISAR1_GPI_SHIFT);
> > -if (!vcpu_has_ptrauth(vcpu)) {
> > -if (val & ptrauth_mask)
> > -kvm_debug("ptrauth unsupported for guests, suppressing\n");
> > -val &=3D ~ptrauth_mask;
> > -}
> > +} else if (id =3D=3D SYS_ID_AA64ISAR1_EL1 && !vcpu_has_ptrauth(vcpu)) =
{
> > +val &=3D ~((0xfUL << ID_AA64ISAR1_APA_SHIFT) |
> > + (0xfUL << ID_AA64ISAR1_API_SHIFT) |
> > + (0xfUL << ID_AA64ISAR1_GPA_SHIFT) |
> > + (0xfUL << ID_AA64ISAR1_GPI_SHIFT));
> >  }
> >
> >  return val;
> >
>
> Since the series isn't in -next yet, I've squashed the above with the
> other nits I had in -queue.

Okey doke.

Thanks
---Dave
IMPORTANT NOTICE: The contents of this email and any attachments are confid=
ential and may also be privileged. If you are not the intended recipient, p=
lease notify the sender immediately and do not disclose the contents to any=
 other person, use it for any purpose, or store or copy the information in =
any medium. Thank you.