From mboxrd@z Thu Jan 1 00:00:00 1970 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 phobos.denx.de (phobos.denx.de [85.214.62.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 719F5C433EF for ; Thu, 14 Jul 2022 16:04:15 +0000 (UTC) Received: from h2850616.stratoserver.net (localhost [IPv6:::1]) by phobos.denx.de (Postfix) with ESMTP id 843088403F; Thu, 14 Jul 2022 18:04:12 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=konsulko.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=u-boot-bounces@lists.denx.de Authentication-Results: phobos.denx.de; dkim=pass (1024-bit key; unprotected) header.d=konsulko.com header.i=@konsulko.com header.b="UgUeepVi"; dkim-atps=neutral Received: by phobos.denx.de (Postfix, from userid 109) id EAA4B83AC3; Thu, 14 Jul 2022 18:04:10 +0200 (CEST) Received: from mail-qv1-xf33.google.com (mail-qv1-xf33.google.com [IPv6:2607:f8b0:4864:20::f33]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits)) (No client certificate requested) by phobos.denx.de (Postfix) with ESMTPS id D5F7783AC3 for ; Thu, 14 Jul 2022 18:04:06 +0200 (CEST) Authentication-Results: phobos.denx.de; dmarc=pass (p=none dis=none) header.from=konsulko.com Authentication-Results: phobos.denx.de; spf=pass smtp.mailfrom=trini@konsulko.com Received: by mail-qv1-xf33.google.com with SMTP id r12so1771402qvm.3 for ; Thu, 14 Jul 2022 09:04:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=konsulko.com; s=google; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=6M/FNXVSD7qcuK7P6QjNLMGKn9eeq6dj8D8NApM5DQ4=; b=UgUeepVihArhSqPmHgcFkkks7h0LmJbf+BpxQCqqXy+3Eopb0ybVI+7m+QoF/JdO7h eE8LUlyFONh8O9VmVj43jaRyXxUqaXc6p9K9gYn+Czp1qLgV0aN//4vdPCyUoaDE1Yh8 terz401O1l5j4/GrFQ0DToD+7rb9huVVP4l/g= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=6M/FNXVSD7qcuK7P6QjNLMGKn9eeq6dj8D8NApM5DQ4=; b=fFj+X39+fnP0iBBABT3+QAoh2EUY5PyFfy1gRpqEla67HkWB95gYTTMnI4XhEFtcXy IUw7g/4NMyAvE6lXDL2p6HRPtxZjW5bV2dvH6VgtcBehodu24tKn2BKqxeKjJBT3HN6l kaAQzNA0oaAd0IsfP6oLqaLlW4x1bTbAT+SstSsJZC3Vbzxas4GKBri39aFEOJ7QmDqZ yuMx0feiU1LWg+KVWr0Wgw8jCUI8Lxq74FLidRvaD2/5LabwkIQM7nomLT9gB8t1y/9d SuFORusuQo9F0iPoH6aONp4/22vNhSxyzlMiZz7U7jVBg+riUkoTaHd2PxGF4ILgh08U 6crw== X-Gm-Message-State: AJIora8kTW3AKUjP3ewgHTXMVGqs5XgAql90hqH6wiHdjc2ZmofXGx84 Px0DMGNJ+dDhqK8UV1RnELV4Pg== X-Google-Smtp-Source: AGRyM1te3j0fPudaMtMJU5YFmrEm/9S0AdKgMABYZyXprBn2g91yEuc8tztqq+oqxkKSU8WiXfedgA== X-Received: by 2002:a05:6214:2427:b0:473:39c5:870a with SMTP id gy7-20020a056214242700b0047339c5870amr8272792qvb.109.1657814644213; Thu, 14 Jul 2022 09:04:04 -0700 (PDT) Received: from bill-the-cat (cpe-65-184-195-139.ec.res.rr.com. [65.184.195.139]) by smtp.gmail.com with ESMTPSA id u7-20020a05620a430700b006af50b6f10csm1555390qko.61.2022.07.14.09.04.02 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 14 Jul 2022 09:04:03 -0700 (PDT) Date: Thu, 14 Jul 2022 12:04:01 -0400 From: Tom Rini To: Ilias Apalodimas Cc: Simon Glass , Rob Herring , Sughosh Ganu , U-Boot Mailing List , Heinrich Schuchardt Subject: Re: [PATCH v6 3/7] tpm: Add the RNG child device Message-ID: <20220714160401.GA1146598@bill-the-cat> References: <20220713180946.GN1146598@bill-the-cat> <20220714111946.GV1146598@bill-the-cat> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="cjnLzlRs2WqML/Lk" Content-Disposition: inline In-Reply-To: X-Clacks-Overhead: GNU Terry Pratchett X-BeenThere: u-boot@lists.denx.de X-Mailman-Version: 2.1.39 Precedence: list List-Id: U-Boot discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: u-boot-bounces@lists.denx.de Sender: "U-Boot" X-Virus-Scanned: clamav-milter 0.103.6 at phobos.denx.de X-Virus-Status: Clean --cjnLzlRs2WqML/Lk Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Jul 14, 2022 at 06:47:28PM +0300, Ilias Apalodimas wrote: > Hi Simon, >=20 > [...] > > > > > > > > > > The driver needs a compatible string so it can be in th= e device tree. > > > > > > > > > > > > > > > > > > Why? I've tried to hint this on the previous iteration o= f the patch. > > > > > > > > > The RNG here is not a *device*. The TPM is the device an= d you are > > > > > > > > > guaranteed to have an RNG. The way to get a random numbe= r is send a > > > > > > > > > special command to the TPM. So all that we should do here= is leverage > > > > > > > > > the fact that the TPM is already in the device tree. > > > > > > > > > > > > > > > > > > And fwiw we should stick to try to stick to what the DT s= pec defines > > > > > > > > > as much as possible. I personally don't see this as a sp= ecial usecase > > > > > > > > > were deviating from the spec is justified. > > > > > > > > > > > > > > > > This is not a deviation from a spec. What spec? Also, I don= 't want to > > > > > > > > get into another discussion about what a device is. We can = disagree on > > > > > > > > that if you like. > > > > > > > > > > > > > > > > One reason is that U-Boot generally requires compatible str= ings, e.g. > > > > > > > > with of-platdata. But also we can refer to the rand device = =66rom > > > > > > > > elsewhere in the tree. I know that Linux does lots of ad-ho= c device > > > > > > > > creation and doesn't really have the concept of a uclass co= nsistently > > > > > > > > applied, but this is U-Boot. > > > > > > > > > > > > > > You are letting client/OS details define your binding. Doing = so > > > > > > > doesn't result in OS agnostic bindings. Sure, it would be nic= e if DT > > > > > > > nodes and drivers were always a nice clean 1:1 ratio, but h/w= is messy > > > > > > > sometimes and DT is not an abstraction layer. The general gui= dance on > > > > > > > whether there are child nodes for sub-blocks is do they have = their own > > > > > > > resources in DT or are the sub-blocks reusable on multiple de= vices. > > > > > > > Neither of those are the case here. > > > > > > > > > > > > > > Besides, we already have TPM device bindings defined. Requiri= ng > > > > > > > binding changes when adding a new client/OS feature is not go= od > > > > > > > practice either. > > > > > > > > > > > > I'm not sure what to do with this, but in general the practice = of > > > > > > implied subnodes is not friendly to U-Boot. Yet it seems like a= common > > > > > > feature of the bindings at present, for example GPIOs. > > > > > > > > > > > > The device tree is how U-Boot determines which random-number ge= nerator > > > > > > to use for a particular function. For example, for VBE, if we n= eed to > > > > > > generate some random numbers we'd like to specify which device = creates > > > > > > them. It can't just be 'use the TPM if you find one'. I'm not s= ure how > > > > > > that works in Linux? > > > > > > > > > > Why can't it be "use the TPM if you find one" since a TPM is a su= perset > > > > > of an RNG? > > > > > > > > You mean look through the available rand devices and choose the one > > > > whose parent is a TPM? > > > > > > > > Sure. There are lots of things you can do. But device tree is suppo= sed > > > > to provide the tree of devices and allow such things to be configur= ed > > > > deterministically. > > > > > > No, I mean pick the TPM device because by definition it is an RNG. > > > > I think that is what I said, or meant. The TPM is not a rand device, > > it is the child of the TPM which might be. >=20 > The design principle of the tpm1.2 says that it must have an rng [1]. > I think something similar is implied on 2.0 architecture as well [2]. > Looking at the cr50 description is says "TPM-like" [3] not TPM. I > assume an RNG exists internally since the TPM requires and RNG for > nonces, key generation etc. >=20 > Any idea what happens if you run tpm_getrandom() against a cr50? If > you get back garbage then we got a problem since you can't really tell > if it's garbage or a random seed. But if it returns something sane > along the lines of 'not supported' then I guess we can use that and > try the next RNG? >=20 > [1] https://trustedcomputinggroup.org/wp-content/uploads/TPM-Main-Part-1-= Design-Principles_v1.2_rev116_01032011.pdf > 4.2.5 random number generator > [2] https://trustedcomputinggroup.org/wp-content/uploads/TPM-Rev-2.0-Part= -1-Architecture-01.07-2014-03-13.pdf > 11.4.10 RNG module > [3] https://www.kernel.org/doc/Documentation/devicetree/bindings/security= /tpm/google%2Ccr50.txt What I'm saying is from what I understand a spec compliant TPM is an RNG, so we should be able to match on that existing compatible. What the cr50 does or doesn't do (or is or is not compliant about) would indeed make things more complex but I think also maybe helps the rest of us understand where you've been coming from. --=20 Tom --cjnLzlRs2WqML/Lk Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGzBAABCgAdFiEEGjx/cOCPqxcHgJu/FHw5/5Y0tywFAmLQPm0ACgkQFHw5/5Y0 tyx5Qgv+Ln0l3uUk8y2Kx4ao3RR7aX8Ru2zTiYIUigDVnnPId9cwMpBcXtUZDUTa 1wowPuP89Ws7JueKv+j0AGmYqQUY67s57LaLHmm+r/xxiKOWLsdqzXHBRe1m1mOx Qa5txWSdBPsbwDf8VGe7AG8D+jLlQbOM1MaCfykxtUB6RT9sVew+pKM1mBM9Py02 Hu6cRKulgo1mFrPgA37iy9cLwMwUzvsnGJivzEfe6V+RlV08GcPFnzAxAzIq3D7I r0qw7f9sN5c6JlNaOxGfTnUW7bMGXSL1fNYCsgZlshzlveOkbo7kMCVXRjt+4XTi tYCYeAP/F3Gz6HxhwXCDhxMqmIP8VqVBI7p2xh42we8eLsI/E9+Nym20s8aOV/45 WL0QHrXRJ4A5fJS9I/u61KbH/PHXAfCOPYa8HAXz1s1vboedDh6jtStW+erZCDRe xJVjOS/DTmQ4xarw2vZzZvlorxmYQ0wPJrmZxu+Kb3uHqLof/0/tSuvMBAEkni6k 4QSzBhWL =sck1 -----END PGP SIGNATURE----- --cjnLzlRs2WqML/Lk--