Received: by 2002:a05:6358:a55:b0:ec:fcf4:3ecf with SMTP id 21csp1885481rwb; Thu, 19 Jan 2023 17:15:57 -0800 (PST) X-Google-Smtp-Source: AMrXdXsD7YdSNEuoFcBYYAGoPn/st7+NntYRJOM/n2yxWL8zSFwXFJJIgC4WP2mkeK8uczK/PkkR X-Received: by 2002:a17:906:3a4d:b0:873:393f:1bda with SMTP id a13-20020a1709063a4d00b00873393f1bdamr11137794ejf.47.1674177357013; Thu, 19 Jan 2023 17:15:57 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1674177356; cv=none; d=google.com; s=arc-20160816; b=DuGP+ZWEAXNNztJ1a+nqFftCAdBkc7f9YSNM7v5BlRoL3XU1+djKMHyeHQXVHBdUnZ 7Q0oT0LZTGvHlG1IzAaSljsNY178WqpgFeFBsXaE8hhP4pyvBFmG/gemIm08b358Z/u3 vvGsCyXmGrOuWkis3FiB03aisRAn4wXtmk0Oolk9h6REJKHYR4u8rGlbVBXQj2f4VIsz X/r7UW9Y+U22lWdeYOdwCfnjpqxFe/ej43w7g0F4tX22uxObyvZLR5EBFMMiztcNr0MQ SafbGUauoByIbAUHQjo5x10IgfDBOsFtC0MWCc8Zea083fat+zplsoAR7hou4scegTY6 Taaw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:user-agent :content-transfer-encoding:references:in-reply-to:date:cc:to:from :subject:message-id:feedback-id:dkim-signature:dkim-signature; bh=oVodv+f7tO66O7huZdWKERwv7Beigm5tN48FcTUIthc=; b=gYMTJLxXFtUc3yUCuBGzicCnCMO/z1Yf0rZVwhTDlgbTeW6n4rFGfsusZyJ1mfq9w0 KEfzJOFJghXAEZjavEXSWo0sNaljyONtlIMNpdeWC8LrpZHmj88eg+4ZiKFCBqKo5nIz wBYZXuJFhU/VvNLEVbxYwhg9NFCWLYm/agvYcSVdaGxTDHoWRtE5hP0WCj7sciK6DNmt cTJButGBmQYExnoyyW2kpjFcMUXUSvMSu6Yhc+jspI3YTjxL+ULWvHX+cXLowZg3RahJ 1i3uBei52Wj4zwe3v3en3k/OqzM7M05JfyLfEjcSeaajl4g0qOq2XM38ZFEYrXXWLYoa LNQw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@russell.cc header.s=fm1 header.b=mHrv+P2K; dkim=pass header.i=@messagingengine.com header.s=fm3 header.b=mpy5pc4Y; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id hu9-20020a170907a08900b008777488ed46si3914359ejc.125.2023.01.19.17.15.45; Thu, 19 Jan 2023 17:15:56 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@russell.cc header.s=fm1 header.b=mHrv+P2K; dkim=pass header.i=@messagingengine.com header.s=fm3 header.b=mpy5pc4Y; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229623AbjATAvi (ORCPT + 48 others); Thu, 19 Jan 2023 19:51:38 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:53314 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229437AbjATAvf (ORCPT ); Thu, 19 Jan 2023 19:51:35 -0500 Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id F05F42719; Thu, 19 Jan 2023 16:51:32 -0800 (PST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 663865C0041; Thu, 19 Jan 2023 19:51:31 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Thu, 19 Jan 2023 19:51:31 -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=1674175891; x= 1674262291; bh=oVodv+f7tO66O7huZdWKERwv7Beigm5tN48FcTUIthc=; b=m Hrv+P2KS6He5GJADam0ymxMgPpSjBSs0fPLtwhPwL6V7rjBYswNdNvugTQOIJ+Dy 5awXIu77v5YBmJIw9qsFOv01IVRtF1y6nKHlTTMuzFRhu/fCRl3GK3sCOerjph2w SkTaYIz9o5C+aTeTY3Yzajdq4g7OJN+iFydgUJiDMNbFdqWypg+VJpCPeHtBhR5B oygQTVHXy7Xmn4p6YaFvp6EqsW1mX/GPxCgkYVI5KQ6XV/oN6c6SfRITRvAZZEd/ D39pqLOdc+wSWHjkD0Xk8wee3AiSNjNyh/nWQU/Aoqtw2qvkPHTbgg2GNUwl/YEt KSLR68cKOcRBU0le6/SsA== 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=1674175891; x= 1674262291; bh=oVodv+f7tO66O7huZdWKERwv7Beigm5tN48FcTUIthc=; b=m py5pc4Y2rCa/bfxvG8c/0IDTR8Idu8DxfDeWdixFkb1e7DMaIzfvvcTaeFf4t0RH Qi4vF/dBWRuw2wlH3CYlIph5krdY2Ygbi647jn6xavgeKyGgITh0nkqnEyd/p/SZ JzrNaoX3tIZ+XoqFU+EFIwkQBEdl32eCKMeo+AOUU9fJbl5dcSU532dUsxPFVESB UhZESekMjsQ970nLj2UL/JVPEsO5pXRy9/cM/157F8rbERSqB6qEDCD9tJVKgTMX qzmxcLKo/L+Iar8RAhyBSrU8lXU3mY9bAu+4Ng/Jzz529g+usEcBejj3hpGyc8KE goHUqmvzHbuotZT9/sYeg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrudduuddgvdekucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne gfrhhlucfvnfffucdludehmdenucfjughrpefkuffhvfevffgjfhgtgfgfggesthhqredt tderjeenucfhrhhomheptfhushhsvghllhcuvehurhhrvgihuceorhhushgtuhhrsehruh hsshgvlhhlrdgttgeqnecuggftrfgrthhtvghrnheptefgieelhfeufeevvdekheeifeej gfefgeehtedukeeigfduuddtueekteevleelnecuvehluhhsthgvrhfuihiivgeptdenuc frrghrrghmpehmrghilhhfrhhomheprhhushgtuhhrsehruhhsshgvlhhlrdgttg X-ME-Proxy: Feedback-ID: i4421424f:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 19 Jan 2023 19:51:27 -0500 (EST) Message-ID: <26945a8372ddde0c2bea9f2382ea9f1e74b9fe63.camel@russell.cc> Subject: Re: [PATCH v3 04/24] powerpc/secvar: Handle format string in the consumer From: Russell Currey To: Nicholas Piggin , Andrew Donnellan , linuxppc-dev@lists.ozlabs.org, linux-integrity@vger.kernel.org Cc: gjoyce@linux.ibm.com, erichte@linux.ibm.com, gregkh@linuxfoundation.org, nayna@linux.ibm.com, linux-kernel@vger.kernel.org, zohar@linux.ibm.com, sudhakar@linux.ibm.com, bgray@linux.ibm.com, gcwilson@linux.ibm.com Date: Fri, 20 Jan 2023 11:51:24 +1100 In-Reply-To: References: <20230118061049.1006141-1-ajd@linux.ibm.com> <20230118061049.1006141-5-ajd@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 X-Spam-Status: No, score=-2.8 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_HELO_PASS,SPF_PASS autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Thu, 2023-01-19 at 11:17 +1000, Nicholas Piggin wrote: > On Wed Jan 18, 2023 at 4:10 PM AEST, Andrew Donnellan wrote: > > From: Russell Currey > >=20 > > The code that handles the format string in secvar-sysfs.c is > > entirely > > OPAL specific, so create a new "format" op in secvar_operations to > > make > > the secvar code more generic.=C2=A0 No functional change. > >=20 > > Signed-off-by: Russell Currey > > Signed-off-by: Andrew Donnellan > >=20 > > --- > >=20 > > v2: Use sysfs_emit() instead of sprintf() (gregkh) > >=20 > > v3: Enforce format string size limit (ruscur) > > --- > > =C2=A0arch/powerpc/include/asm/secvar.h=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0 3 +++ > > =C2=A0arch/powerpc/kernel/secvar-sysfs.c=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 | 23 ++++------------ > > -- > > =C2=A0arch/powerpc/platforms/powernv/opal-secvar.c | 25 > > ++++++++++++++++++++ > > =C2=A03 files changed, 33 insertions(+), 18 deletions(-) > >=20 > > diff --git a/arch/powerpc/include/asm/secvar.h > > b/arch/powerpc/include/asm/secvar.h > > index 07ba36f868a7..8b6475589120 100644 > > --- a/arch/powerpc/include/asm/secvar.h > > +++ b/arch/powerpc/include/asm/secvar.h > > @@ -11,12 +11,15 @@ > > =C2=A0#include > > =C2=A0#include > > =C2=A0 > > +#define SECVAR_MAX_FORMAT_LEN=C2=A0=C2=A030 // max length of string re= turned > > by ->format() > > + > > =C2=A0extern const struct secvar_operations *secvar_ops; > > =C2=A0 > > =C2=A0struct secvar_operations { > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0int (*get)(const char *= key, u64 key_len, u8 *data, u64 > > *data_size); > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0int (*get_next)(const c= har *key, u64 *key_len, u64 > > keybufsize); > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0int (*set)(const char *= key, u64 key_len, u8 *data, u64 > > data_size); > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0ssize_t (*format)(char *buf)= ; > > =C2=A0}; > > =C2=A0 > > =C2=A0#ifdef CONFIG_PPC_SECURE_BOOT > > diff --git a/arch/powerpc/kernel/secvar-sysfs.c > > b/arch/powerpc/kernel/secvar-sysfs.c > > index 462cacc0ca60..d3858eedd72c 100644 > > --- a/arch/powerpc/kernel/secvar-sysfs.c > > +++ b/arch/powerpc/kernel/secvar-sysfs.c > > @@ -21,26 +21,13 @@ static struct kset *secvar_kset; > > =C2=A0static ssize_t format_show(struct kobject *kobj, struct > > kobj_attribute *attr, > > =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=C2=A0= =C2=A0=C2=A0 char *buf) > > =C2=A0{ > > -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0ssize_t 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=A0const char *format; > > - > > -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0node =3D of_find_compatible_= node(NULL, NULL, "ibm,secvar- > > backend"); > > -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0if (!of_device_is_available(= node)) { > > -=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=A0rc =3D -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=A0goto out; > > -=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=A0char tmp[SECVAR_MAX_FORMAT_L= EN]; > > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0ssize_t len =3D secvar_ops->= format(tmp); > > =C2=A0 > > -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0rc =3D of_property_read_stri= ng(node, "format", &format); > > -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0if (rc) > > -=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=A0goto out; > > +=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=A0return -EIO; >=20 > AFAIKS this does have a functional change, it loses the return value. > Why not return len if it is < 0, and -EIO if len =3D=3D 0? In v2 mpe suggested the following: I'm not sure you should pass that raw error back to sysfs. Some of the values could be confusing, eg. if you return -EINVAL it looks like a parameter to the read() syscall was invalid. Might be better to just return -EIO. =20 Following that advice, I don't think we should return something other than -EIO, but we should at least pr_err() to document the error - this isn't something that should ever fail. >=20 > Thanks, > Nick