Received: by 2002:ac0:946b:0:0:0:0:0 with SMTP id j40csp660956imj; Wed, 13 Feb 2019 15:11:42 -0800 (PST) X-Google-Smtp-Source: AHgI3Ib9xbUzFizGH8WqTEu8UqNpfUfNGU1twVTz2g4GRwCBOrK7mXAGART1rUwGOQP5oH7fbeOd X-Received: by 2002:a63:5962:: with SMTP id j34mr611343pgm.297.1550099502113; Wed, 13 Feb 2019 15:11:42 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1550099502; cv=none; d=google.com; s=arc-20160816; b=TTWD8pOVZN0enVyi5aaXa8nMlyHA3NkIR6cw271TuPcuCUDZvlvwjbetH32lWcIL42 JvDGKm6XvjwpDQGCR6iO5ImesuVgLu72iRbsBYIr2Q+o6QfTqltYCQIwx3IRLE+ZEJvq sFyFyja0yHATbtRpKiqinYgNlDQAGfWo1Wh9HEPrF2iNgt4kMd4qjAPJX6201UmCvlLi As+jXiYwx0kThGEWTxC1GSZlVQFKwuF9QO65/fdhYIw2nGSVarnyRkRuaoEVdvDlK5DM eW8u6N5EQrvX8wG/1ykWLE8YZolMkTUqDsBvORXbMH0jsipvP6L2jy5z4quVUxQ2ZJhB 2R2Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:content-transfer-encoding :content-id:user-agent:content-language:accept-language:in-reply-to :references:message-id:date:thread-index:thread-topic:subject:cc:to :from:dkim-signature; bh=Y4pDO6PcCUizzZaA6wrzfQk3h4mIUB/IfC6eIOWAVzs=; b=yt4KhgT5FZoXd4XJyDAEgikEKB7jOkG70s7gRvaz8txug9SOp1KxHlgp9dB6MVk07k N0RseC/44zgSN3ZFFequ6FseYQYYMTshAaRR4elSFvUlZYzQCbGd9v4BpmrGe4lHIRL0 RZBcZKwHrsf6n5x/rpboZ5ZLuPITJhVJd2PX8T5siM1YwiBuCHkRjOh1pZ6YW6XkyPxm PKNqLT1BhbQiu8VHz8R0X4Up3p5iNIL/ECNph1oW7jfS89PxyvSxrgOy6cFZLbX3l9eJ 0mc0cHB2hU9i4RmjP/Kllu7ten4r5XjJArlXqW0vywIdZ9TopaOS4EGUh/j1vwM6zCX7 fGhQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@armh.onmicrosoft.com header.s=selector1-arm-com header.b=NQ1tJ0mT; 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 i18si572040pgi.385.2019.02.13.15.11.25; Wed, 13 Feb 2019 15:11:41 -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; dkim=pass header.i=@armh.onmicrosoft.com header.s=selector1-arm-com header.b=NQ1tJ0mT; 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 S2393429AbfBMRyj (ORCPT + 99 others); Wed, 13 Feb 2019 12:54:39 -0500 Received: from mail-eopbgr40072.outbound.protection.outlook.com ([40.107.4.72]:12512 "EHLO EUR03-DB5-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S2393391AbfBMRyj (ORCPT ); Wed, 13 Feb 2019 12:54:39 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=armh.onmicrosoft.com; s=selector1-arm-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=Y4pDO6PcCUizzZaA6wrzfQk3h4mIUB/IfC6eIOWAVzs=; b=NQ1tJ0mTgKv+RSJ6H0DcffESkTvTRhE2JHt7XtXKSyrH6m9aaUt8dNJGknhqyHu4HF7kpEudAbyj7jUXjgvf0ffVbgDoNfI5EYyG6UeUfaWrR4ZPfDB9oXhiPyF4y/4ozDnOPh73X2qHzXDT+R+8dLIjX4EQtmcXmdQtqeMH6TA= Received: from VI1PR0801MB1599.eurprd08.prod.outlook.com (10.167.211.15) by VI1PR0801MB1917.eurprd08.prod.outlook.com (10.173.73.143) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1601.24; Wed, 13 Feb 2019 17:54:32 +0000 Received: from VI1PR0801MB1599.eurprd08.prod.outlook.com ([fe80::e11e:abd4:7d4:d8aa]) by VI1PR0801MB1599.eurprd08.prod.outlook.com ([fe80::e11e:abd4:7d4:d8aa%3]) with mapi id 15.20.1601.023; Wed, 13 Feb 2019 17:54:32 +0000 From: Dave P Martin To: Kristina Martsenko CC: Amit Kachhap , "linux-arm-kernel@lists.infradead.org" , Christoffer Dall , Marc Zyngier , Catalin Marinas , Will Deacon , Andrew Jones , Ramana Radhakrishnan , "kvmarm@lists.cs.columbia.edu" , "linux-kernel@vger.kernel.org" , Mark Rutland Subject: Re: [PATCH v5 5/5] arm64/kvm: control accessibility of ptrauth key registers Thread-Topic: [PATCH v5 5/5] arm64/kvm: control accessibility of ptrauth key registers Thread-Index: AQHUttcIXMlYMTNtLUi7qKmd4qbM7KXeF2wAgAAFOoA= Date: Wed, 13 Feb 2019 17:54:31 +0000 Message-ID: <20190213175428.GR32634@e103592.cambridge.arm.com> References: <1548658727-14271-1-git-send-email-amit.kachhap@arm.com> <1548658727-14271-6-git-send-email-amit.kachhap@arm.com> <6ddfa9ae-5c98-540e-b4aa-8149c8515c9e@arm.com> In-Reply-To: <6ddfa9ae-5c98-540e-b4aa-8149c8515c9e@arm.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Mutt/1.5.23 (2014-03-12) x-originating-ip: [217.140.106.49] x-clientproxiedby: LNXP265CA0094.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:76::34) To VI1PR0801MB1599.eurprd08.prod.outlook.com (2603:10a6:800:19::15) authentication-results: spf=none (sender IP is ) smtp.mailfrom=Dave.Martin@arm.com; x-ms-exchange-messagesentrepresentingtype: 1 x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 8c5d73e0-139c-41f3-36c5-08d691dc4e8f x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0;PCL:0;RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600110)(711020)(4605077)(4618075)(2017052603328)(7153060)(7193020);SRVR:VI1PR0801MB1917; x-ms-traffictypediagnostic: VI1PR0801MB1917: x-ms-exchange-purlcount: 1 x-microsoft-exchange-diagnostics: 1;VI1PR0801MB1917;20:OpAFND329mqx4I1wIEWwZ0SVTK2kX9/HxjmN//Eyj/UzpRhVmIs4EBG96aovk8wYRnbE12S2u/Bn2fUtfOTNJA2jxjWFWGO85HJRIz9b4t7DoFl6xmvqSVMo6COBqOP6pT+Gamt6UWsy0/v9V+ndxYG1ZNHJCmk6d9dDgFEklIY= x-microsoft-antispam-prvs: x-forefront-prvs: 094700CA91 x-forefront-antispam-report: SFV:NSPM;SFS:(10009020)(979002)(396003)(346002)(39860400002)(136003)(376002)(366004)(199004)(189003)(40434004)(99286004)(53546011)(6306002)(6506007)(105586002)(11346002)(486006)(966005)(71200400001)(72206003)(71190400001)(6636002)(478600001)(76176011)(386003)(54906003)(476003)(256004)(5024004)(14444005)(1076003)(6436002)(6862004)(106356001)(446003)(97736004)(4326008)(86362001)(6512007)(58126008)(53936002)(229853002)(6486002)(6246003)(316002)(2906002)(305945005)(8676002)(33656002)(81166006)(102836004)(81156014)(7736002)(52116002)(186003)(14454004)(25786009)(26005)(3846002)(6116002)(66066001)(8936002)(68736007)(18370500001)(969003)(989001)(999001)(1009001)(1019001);DIR:OUT;SFP:1101;SCL:1;SRVR:VI1PR0801MB1917;H:VI1PR0801MB1599.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: kTgyqczUbE7DYXwPq4ZBJ1ZRc0291fVW9EBBSYkUcfunDdHsW4r1Qj+8ztGEC5jV63wVmmpu+/UfysYYniE+sHjKxTJjyZeEknqYm9Vtp4NjbC/E104Z+0U2XaMeGxafHbt4cEZPaw27HkO9VCYg8EdaSVInbLy7Du72LIQfCMPTmmNY1CVGY5S17/dScImTSmfh6F0y5pGQzyxBsc4tt9+JRX+us5CMgw34Iul96ToeF476YR8A+1rdRRKMwS6O2dsjtQ9yRA1RGBszsJR9SdQmeEAYSwQCFLFNgRdDkmBIoK8f7j5odNmN2xWVI4W8GNBJ5Ja1zAPP28EnZfftVorYwpVYXZnxUPNgWr7AwE2TZ5qVxb/z9hfwuhE34fcIDrG6MUe3PuuKQjphsZxehol14cAULeKsBLVaORt17hY= Content-Type: text/plain; charset="us-ascii" Content-ID: <7CCFAA3A6CDAE249A322E913752952E1@eurprd08.prod.outlook.com> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: arm.com X-MS-Exchange-CrossTenant-Network-Message-Id: 8c5d73e0-139c-41f3-36c5-08d691dc4e8f X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Feb 2019 17:54:31.2331 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-id: f34e5979-57d9-4aaa-ad4d-b122a662184d X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0801MB1917 Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, Feb 13, 2019 at 05:35:46PM +0000, Kristina Martsenko wrote: > On 28/01/2019 06:58, Amit Daniel Kachhap wrote: > > According to userspace settings, ptrauth key registers are conditionall= y > > present in guest system register list based on user specified flag > > KVM_ARM_VCPU_PTRAUTH. > > > > Signed-off-by: Amit Daniel Kachhap > > Cc: Mark Rutland > > Cc: Christoffer Dall > > Cc: Marc Zyngier > > Cc: Kristina Martsenko > > Cc: kvmarm@lists.cs.columbia.edu > > Cc: Ramana Radhakrishnan > > Cc: Will Deacon > > --- > > Documentation/arm64/pointer-authentication.txt | 3 ++ > > arch/arm64/kvm/sys_regs.c | 42 ++++++++++++++++++= +------- > > 2 files changed, 34 insertions(+), 11 deletions(-) > > [...] > > diff --git a/arch/arm64/kvm/sys_regs.c b/arch/arm64/kvm/sys_regs.c [...] > > @@ -2487,18 +2493,22 @@ static int walk_one_sys_reg(const struct sys_re= g_desc *rd, > > } > > > > /* Assumed ordered tables, see kvm_sys_reg_table_init. */ > > -static int walk_sys_regs(struct kvm_vcpu *vcpu, u64 __user *uind) > > +static int walk_sys_regs(struct kvm_vcpu *vcpu, u64 __user *uind, > > +const struct sys_reg_desc *desc, unsigned int len) > > { > > const struct sys_reg_desc *i1, *i2, *end1, *end2; > > unsigned int total =3D 0; > > size_t num; > > int err; > > > > +if (desc =3D=3D ptrauth_reg_descs && !kvm_arm_vcpu_ptrauth_allowed(vcp= u)) > > +return total; > > + > > /* We check for duplicates here, to allow arch-specific overrides. */ > > i1 =3D get_target_table(vcpu->arch.target, true, &num); > > end1 =3D i1 + num; > > -i2 =3D sys_reg_descs; > > -end2 =3D sys_reg_descs + ARRAY_SIZE(sys_reg_descs); > > +i2 =3D desc; > > +end2 =3D desc + len; > > > > BUG_ON(i1 =3D=3D end1 || i2 =3D=3D end2); > > > > @@ -2526,7 +2536,10 @@ unsigned long kvm_arm_num_sys_reg_descs(struct k= vm_vcpu *vcpu) > > { > > return ARRAY_SIZE(invariant_sys_regs) > > + num_demux_regs() > > -+ walk_sys_regs(vcpu, (u64 __user *)NULL); > > ++ walk_sys_regs(vcpu, (u64 __user *)NULL, sys_reg_descs, > > +ARRAY_SIZE(sys_reg_descs)) > > ++ walk_sys_regs(vcpu, (u64 __user *)NULL, ptrauth_reg_descs, > > +ARRAY_SIZE(ptrauth_reg_descs)); > > } > > > > int kvm_arm_copy_sys_reg_indices(struct kvm_vcpu *vcpu, u64 __user *ui= ndices) > > @@ -2541,7 +2554,12 @@ int kvm_arm_copy_sys_reg_indices(struct kvm_vcpu= *vcpu, u64 __user *uindices) > > uindices++; > > } > > > > -err =3D walk_sys_regs(vcpu, uindices); > > +err =3D walk_sys_regs(vcpu, uindices, sys_reg_descs, ARRAY_SIZE(sys_re= g_descs)); > > +if (err < 0) > > +return err; > > +uindices +=3D err; > > + > > +err =3D walk_sys_regs(vcpu, uindices, ptrauth_reg_descs, ARRAY_SIZE(pt= rauth_reg_descs)); > > if (err < 0) > > return err; > > uindices +=3D err; > > @@ -2575,6 +2593,7 @@ void kvm_sys_reg_table_init(void) > > BUG_ON(check_sysreg_table(cp15_regs, ARRAY_SIZE(cp15_regs))); > > BUG_ON(check_sysreg_table(cp15_64_regs, ARRAY_SIZE(cp15_64_regs))); > > BUG_ON(check_sysreg_table(invariant_sys_regs, ARRAY_SIZE(invariant_sys= _regs))); > > +BUG_ON(check_sysreg_table(ptrauth_reg_descs, ARRAY_SIZE(ptrauth_reg_de= scs))); > > > > /* We abuse the reset function to overwrite the table itself. */ > > for (i =3D 0; i < ARRAY_SIZE(invariant_sys_regs); i++) > > @@ -2616,6 +2635,7 @@ void kvm_reset_sys_regs(struct kvm_vcpu *vcpu) > > > > /* Generic chip reset first (so target could override). */ > > reset_sys_reg_descs(vcpu, sys_reg_descs, ARRAY_SIZE(sys_reg_descs)); > > +reset_sys_reg_descs(vcpu, ptrauth_reg_descs, ARRAY_SIZE(ptrauth_reg_de= scs)); > > > > table =3D get_target_table(vcpu->arch.target, true, &num); > > reset_sys_reg_descs(vcpu, table, num); > > This isn't very scalable, since we'd need to duplicate all the above > code every time we add new system registers that are conditionally > accessible. Agreed, putting feature-specific checks in walk_sys_regs() is probably best avoided. Over time we would likely accumulate a fair number of these checks. > It seems that the SVE patches [1] solved this problem by adding a > check_present() callback into struct sys_reg_desc. It probably makes > sense to rebase onto that patch and just implement the callback for the > ptrauth key registers as well. > > [1] https://lore.kernel.org/linux-arm-kernel/1547757219-19439-13-git-send= -email-Dave.Martin@arm.com/ Note, I'm currently refactoring this so that enumeration through KVM_GET_REG_LIST can be disabled independently of access to the register. This may not be the best approach, but for SVE I have a feature-specific ID register to handle too (ID_AA64ZFR0_EL1), which needs to be hidden from the enumeration but still accessible with read-as-zero behaviour. This changes the API a bit: I move to a .restrictions() callback which returns flags to say what is disabled, and this callback is used in the common code so that you don't have repeat your "feature present" check in every accessor, as is currently the case. I'm aiming to post a respun series in the next day or two. The code may of course change again after it gets reviewed... Basing on [1] is probably a reasonable starting point, though. Cheers ---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.