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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 14596C38142 for ; Wed, 25 Jan 2023 02:24:33 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S233699AbjAYCYb (ORCPT ); Tue, 24 Jan 2023 21:24:31 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53136 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S233639AbjAYCY3 (ORCPT ); Tue, 24 Jan 2023 21:24:29 -0500 Received: from wout1-smtp.messagingengine.com (wout1-smtp.messagingengine.com [64.147.123.24]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 786414FC01; Tue, 24 Jan 2023 18:24:12 -0800 (PST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id 669313200583; Tue, 24 Jan 2023 21:24:08 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Tue, 24 Jan 2023 21:24:09 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=russell.cc; h=cc :cc:content-transfer-encoding:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to; s=fm1; t=1674613448; x= 1674699848; bh=ffEhCn+X2jqCw1f4djQYZddJ1ObjP/owju4xwUAZF9M=; b=r PC0jYBfvHDpaNaJCwwQmpP7qPF1is0Ck4COrr6WH/bBW0mqrvB9YtLlQOP+saAQq DMDLbKfIZTTuDJKJhMPBJJFBhEHjhK7hdoGTemWSzUCeSk/9R2kQFvRYQw40Jbw1 pmWxvJnh3XsXqmUQgIPWEO52gUtuLBqLbQd0/i2l0bee+Zz+NWMGILBL9Y1EtfEx f3A3/cYgbru3wVL4hkVL8mXOyq7Pwc2R4SLyo9Gu3lcXXLRn8qYJiFyulbBSHG3b 8TjBvp8JU+ZOW3cAb1L5BrfsNYxtzVDZv3Ho5O2MIMrdMxXVc/sUOnYCpwoxbKjI sBWM7Baq6v6DqLdNA43bw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t=1674613448; x= 1674699848; bh=ffEhCn+X2jqCw1f4djQYZddJ1ObjP/owju4xwUAZF9M=; b=k SKNPt84ElG2XNyl5RUZoQ4zEGzO3yLxQWI2lxv91BlhuyzXRvEB7jmaMx5sqOK26 XPoUDEA4ITYSH0/HgfQUYeRuV/hKc2WGR8Syc/Y/mOZ7WQXtMyna5lQ+miZcxIzS osOrCTsiNhlxP6/lWd/u/idtd8+m/2pKpKnVLGsmQEP52BAZIrwT0gewyyeakX5W ph9AK/xHpTSZykSClk5/F24fT5GxBZtBwwsxD27pI+Pl4BzzzsWBdj9g0nGTnu38 iWC3nkIcXNCnx4gZevZvzyllRrdcnQP8B2+xcX5XC+kHhxW/KkSyZusN4CyJQrjz SFg3fT2XWK/O14/dvQVGQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedruddvuddghedtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne gfrhhlucfvnfffucdludehmdenucfjughrpefkuffhvfevffgjfhgtgfgfggesthhqredt tderjeenucfhrhhomheptfhushhsvghllhcuvehurhhrvgihuceorhhushgtuhhrsehruh hsshgvlhhlrdgttgeqnecuggftrfgrthhtvghrnheptefgieelhfeufeevvdekheeifeej gfefgeehtedukeeigfduuddtueekteevleelnecuvehluhhsthgvrhfuihiivgeptdenuc frrghrrghmpehmrghilhhfrhhomheprhhushgtuhhrsehruhhsshgvlhhlrdgttg X-ME-Proxy: Feedback-ID: i4421424f:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 24 Jan 2023 21:24:03 -0500 (EST) Message-ID: <71b48934e26a991eaf62c9869a8dfee769e0799d.camel@russell.cc> Subject: Re: [PATCH v4 24/24] integrity/powerpc: Support loading keys from pseries secvar From: Russell Currey To: Mimi Zohar , Andrew Donnellan , linuxppc-dev@lists.ozlabs.org, linux-integrity@vger.kernel.org Cc: gregkh@linuxfoundation.org, gcwilson@linux.ibm.com, linux-kernel@vger.kernel.org, nayna@linux.ibm.com, mpe@ellerman.id.au, gjoyce@linux.ibm.com, sudhakar@linux.ibm.com, bgray@linux.ibm.com, erichte@linux.ibm.com, joel@jms.id.au Date: Wed, 25 Jan 2023 13:23:59 +1100 In-Reply-To: <57dca1ea3ef66bc0935bdd1dab4536f1151f4004.camel@linux.ibm.com> References: <20230120074306.1326298-1-ajd@linux.ibm.com> <20230120074306.1326298-25-ajd@linux.ibm.com> <57dca1ea3ef66bc0935bdd1dab4536f1151f4004.camel@linux.ibm.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.46.3 (3.46.3-1.fc37) MIME-Version: 1.0 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 2023-01-24 at 10:14 -0500, Mimi Zohar wrote: > On Fri, 2023-01-20 at 18:43 +1100, Andrew Donnellan wrote: > > From: Russell Currey > >=20 > > The secvar object format is only in the device tree under powernv. > > We now have an API call to retrieve it in a generic way, so we > > should > > use that instead of having to handle the DT here. > >=20 > > Add support for pseries secvar, with the "ibm,plpks-sb-v1" format. > > The object format is expected to be the same, so there shouldn't be > > any > > functional differences between objects retrieved from powernv and > > pseries. > >=20 > > Signed-off-by: Russell Currey > > Signed-off-by: Andrew Donnellan > >=20 > > --- > >=20 > > v3: New patch > >=20 > > v4: Pass format buffer size (stefanb, npiggin) > > --- > > =C2=A0.../integrity/platform_certs/load_powerpc.c=C2=A0=C2=A0=C2=A0=C2= =A0 | 17 ++++++++++--- > > ---- > > =C2=A01 file changed, 10 insertions(+), 7 deletions(-) > >=20 > > diff --git a/security/integrity/platform_certs/load_powerpc.c > > b/security/integrity/platform_certs/load_powerpc.c > > index dee51606d5f4..d4ce91bf3fec 100644 > > --- a/security/integrity/platform_certs/load_powerpc.c > > +++ b/security/integrity/platform_certs/load_powerpc.c > > @@ -10,7 +10,6 @@ > > =C2=A0#include > > =C2=A0#include > > =C2=A0#include > > -#include > > =C2=A0#include > > =C2=A0#include > > =C2=A0#include "keyring_handler.h" > > @@ -59,16 +58,22 @@ static int __init load_powerpc_certs(void) > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0void *db =3D NULL, *dbx= =3D NULL; > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0u64 dbsize =3D 0, dbxsi= ze =3D 0; > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0int rc =3D 0; > > -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0struct device_node *node; > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0ssize_t len; > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0char buf[32]; > > =C2=A0 > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0if (!secvar_ops) > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0return -ENODEV; > > =C2=A0 > > -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0/* The following only applie= s for the edk2-compat backend. > > */ > > -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0node =3D of_find_compatible_= node(NULL, NULL, "ibm,edk2- > > compat-v1"); > > -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0if (!node) > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0len =3D secvar_ops->format(b= uf, 32); >=20 > "powerpc/secvar: Handle format string in the consumer"=C2=A0 defines > opal_secvar_format() for the object format "ibm,secvar-backend".=C2=A0 > Here > shouldn't it being returning the format for "ibm,edk2-compat-v1"? >=20 They end up with the same value. The DT structure on powernv looks like this: /proc/device-tree/ibm,opal/secvar: name "secvar" compatible "ibm,secvar-backend" "ibm,edk2-compat-v1" format "ibm,edk2-compat-v1" max-var-key-len 00000000 00000400 phandle 0000805a (32858) max-var-size 00000000 00002000 The existing code is checking for a node compatible with "ibm,edk2- compat-v1", which would match the node above. opal_secvar_format() checks for a node compatible with "ibm,secvar-backend" (again, matching above) and then returns the contents of the "format" string, which is "ibm,edk2-compat-v1". Ultimately it's two different ways of doing the same thing, but this way load_powerpc_certs() doesn't have to interact with the device tree. - Russell > Mimi >=20 > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0if (len <=3D 0) > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0return -ENODEV; > > =C2=A0 > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0// Check for known secure bo= ot implementations from OPAL or > > PLPKS > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0if (strcmp("ibm,edk2-compat-= v1", buf) && strcmp("ibm,plpks- > > sb-v1", buf)) { > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0pr_err("Unsupported secvar implementation \"%s\", > > not loading certs\n", buf); > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0return -ENODEV; > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0} > > + > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0/* > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 * Get db, and dbx. The= y might not exist, so it isn't an > > error if we > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 * can't get them. > > @@ -103,8 +108,6 @@ static int __init load_powerpc_certs(void) > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0kfree(dbx); > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0} > > =C2=A0 > > -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0of_node_put(node); > > - > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0return rc; > > =C2=A0} > > =C2=A0late_initcall(load_powerpc_certs); >=20 >=20