U-Boot Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Eddie James <eajames@linux.ibm.com>
To: Tim Harvey <tharvey@gateworks.com>,
	Ilias Apalodimas <ilias.apalodimas@linaro.org>
Cc: u-boot <u-boot@lists.denx.de>, Simon Glass <sjg@chromium.org>,
	Ruchika Gupta <ruchika.gupta@linaro.org>,
	Samuel Lee <slee@gateworks.com>
Subject: Re: tcg2_platform_get_log failing to read address and size of memory-region via ofnode_get_addr_size
Date: Wed, 27 Mar 2024 10:32:43 -0500	[thread overview]
Message-ID: <31360dde-ae73-41e9-a7b0-a99fd2eaff46@linux.ibm.com> (raw)
In-Reply-To: <CAJ+vNU0380ved3FWt_R4UVR3stFrb3B4dLTx=m6dp0377MK6hQ@mail.gmail.com>


On 3/26/24 11:15, Tim Harvey wrote:
> On Tue, Mar 26, 2024 at 2:24 AM Ilias Apalodimas
> <ilias.apalodimas@linaro.org> wrote:
>> Hi Tim,
>>
>> On Tue, 26 Mar 2024 at 03:15, Tim Harvey <tharvey@gateworks.com> wrote:
>>> Greetings,
>>>
>>> I'm unable to understand why tcg2_platform_get_log is failing to read
>>> a memory region.
>>>
>>> For example the following diffs:
>> I am not really sure what those nodes are supposed to do in sandbox.
>> Pehaps Eddie remembers.
>> What exactly are you trying to achieve here? Read the eventlog from TF-A?
>>
>
> Would you agree with removing the requirement for the event log?


No, the log is required, otherwise it's fairly meaningless work. You 
need the log in your OS to verify the contents of the TPM.

Here is the device tree reserved memory stuff we're using, perhaps it 
will help.

diff --git a/arch/arm/dts/ast2600-p10bmc.dts 
b/arch/arm/dts/ast2600-p10bmc.dts
index 1d0f88bf96..8fbfeaa0d7 100755
--- a/arch/arm/dts/ast2600-p10bmc.dts
+++ b/arch/arm/dts/ast2600-p10bmc.dts
@@ -13,6 +13,17 @@
                 reg = <0x80000000 0x40000000>;
         };

+       reserved-memory {
+               #address-cells = <1>;
+               #size-cells = <1>;
+               ranges;
+
+               event_log: tcg_event_log@b3d00000 {
+                       no-map;
+                       reg = <0xb3d00000 0x100000>;
+               };
+       };
+
         chosen {
                 stdout-path = &uart5;
         };
@@ -113,6 +124,7 @@
         tpm@2e {
                 compatible = "nuvoton,npct75x";
                 reg = <0x2e>;
+               memory-region = <&event_log>;
         };
  };


>
> I have another question that perhaps you may have some feedback on.
> The tpm commands such as pcr_extend, pcr_read currently require a
> 32-byte SHA256 digest and I wish to extend that as my TPM supports
> only SHA1. The tpm2_pcr_extend and tpm2_pcr_read functions were
> extended to function to allow the digest type and length to be passed
> in and I'm wondering what the best way to extend the tpm extend/read
> commands would be to support that.
>
> The tcg2_create_digest function creates a digest based on the
> capabilities of the tpm and the tcg2_pcr_extend loops over those
> calling tpm2_pcr_extend for each digtest supported (and same for
> tcg2_pcr_read looping over tpm2_pcr_read) and I'm assuming TPM's can
> support multiple algos so I suppose a parameter needs to be added to
> the pcr_read and pcr_extend commands. Would you agree with that?
>
> Best Regards,
>
> Tim
>
>> Thanks
>> /Ilias
>>> diff --git a/arch/arm/dts/imx8mm-venice-gw73xx.dtsi
>>> b/arch/arm/dts/imx8mm-venice-gw73xx.dtsi
>>> index 7b2130dbdb21..57b3c227ceaf 100644
>>> --- a/arch/arm/dts/imx8mm-venice-gw73xx.dtsi
>>> +++ b/arch/arm/dts/imx8mm-venice-gw73xx.dtsi
>>> @@ -112,6 +112,7 @@
>>> compatible = "tcg,tpm_tis-spi";
>>> reg = <0x1>;
>>> spi-max-frequency = <36000000>;
>>> + memory-region = <&event_log>;
>>> };
>>> };
>>> diff --git a/arch/arm/dts/imx8mm-venice-gw700x.dtsi
>>> b/arch/arm/dts/imx8mm-venice-gw700x.dtsi
>>> index c305e325d007..697fd1148785 100644
>>> --- a/arch/arm/dts/imx8mm-venice-gw700x.dtsi
>>> +++ b/arch/arm/dts/imx8mm-venice-gw700x.dtsi
>>> @@ -13,6 +13,17 @@
>>> reg = <0x0 0x40000000 0 0x80000000>;
>>> };
>>>
>>> + reserved-memory {
>>> + #address-cells = <2>;
>>> + #size-cells = <2>;
>>> + ranges;
>>> +
>>> + event_log: tcg_event_log {
>>> + no-map;
>>> + reg = <0 0x40000000 0x2000>;
>>> + };
>>> + };
>>> +
>>> gpio-keys {
>>> compatible = "gpio-keys";
>>>
>>> And at runtime:
>>> u-boot=> fdt addr $fdtcontroladdr
>>> u-boot=> fdt list 
>>> /soc@0/bus@30800000/spba-bus@30800000/spi@30830000/tpm@1/
>>> tpm@1 {
>>> compatible = "tcg,tpm_tis-spi";
>>> reg = <0x00000001>;
>>> spi-max-frequency = <0x02255100>;
>>> memory-region = <0x00000025>;
>>> };
>>> u-boot=> fdt list /reserved-memory/
>>> reserved-memory {
>>> #address-cells = <0x00000002>;
>>> #size-cells = <0x00000002>;
>>> ranges;
>>> tcg_event_log {
>>> };
>>> };
>>> u-boot=> fdt list /reserved-memory/tcg_event_log
>>> tcg_event_log {
>>> no-map;
>>> reg = <0x00000000 0x40000000 0x00002000>;
>>> phandle = <0x00000025>;
>>> };
>>>
>>> So why does the following code in tcg2_platform_get_log() return 
>>> -ENOMEM?
>>>
>>> if (dev_read_phandle_with_args(dev, "memory-region", NULL, 0,
>>> 0, &args))
>>> return -ENODEV;
>>>
>>> a = ofnode_get_addr_size(args.node, "reg", &s);
>>> if (a == FDT_ADDR_T_NONE)
>>> return -ENOMEM;
>>>
>>> debugging shows that dev_read_phandle_with_args returns non-zero but
>>> args.args_count is 0.
>>>
>>> I feel like the construct of using dev_read_phandle_with_args followed
>>> by the ofnode_get_addr_size is just wrong but I don't understand why
>>> nor do I understand how my dt changes differ from what is in
>>> arch/sandbox/dts/test.dts (other than its using address-size=1 which
>>> doesn't appear to be the issue in my testing). The abstraction of the
>>> ofnode and fdt stuff always trip me up... very confusing.
>>>
>>> Can anyone explain the issue here?
>>>
>>> Best Regards,
>>>
>>> Tim

  parent reply	other threads:[~2024-03-27 15:32 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-26  1:15 tcg2_platform_get_log failing to read address and size of memory-region via ofnode_get_addr_size Tim Harvey
2024-03-26  9:23 ` Ilias Apalodimas
2024-03-26 16:15   ` Tim Harvey
2024-03-27 15:22     ` Eddie James
2024-03-27 15:46       ` Ilias Apalodimas
2024-03-27 16:32         ` Tim Harvey
2024-03-27 17:05           ` Ilias Apalodimas
2024-03-27 21:48             ` Tim Harvey
2024-03-28  8:33               ` Ilias Apalodimas
2024-03-27 15:32     ` Eddie James [this message]
2024-03-27 16:00     ` Ilias Apalodimas

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=31360dde-ae73-41e9-a7b0-a99fd2eaff46@linux.ibm.com \
    --to=eajames@linux.ibm.com \
    --cc=ilias.apalodimas@linaro.org \
    --cc=ruchika.gupta@linaro.org \
    --cc=sjg@chromium.org \
    --cc=slee@gateworks.com \
    --cc=tharvey@gateworks.com \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox