[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [PATCH v2 6/6] ibmvtpm: Add support for trusted boot using a vTPM 2.
From: |
Stefan Berger |
Subject: |
Re: [PATCH v2 6/6] ibmvtpm: Add support for trusted boot using a vTPM 2.0 |
Date: |
Wed, 14 Dec 2022 22:05:16 -0500 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.5.1 |
On 12/14/22 09:20, Daniel Kiper wrote:
On Tue, Dec 13, 2022 at 01:18:34PM -0500, Stefan Berger wrote:
On 12/13/22 11:35, Daniel Kiper wrote:
On Thu, Dec 01, 2022 at 04:12:01PM -0500, Stefan Berger wrote:
Add support for trusted boot using a vTPM 2.0 on the IBM IEEE1275
PowerPC platform. With this patch grub now measures text and binary data
into the TPM's PCRs 8 and 9 in the same way as the x86_64 platform
does.
+}
+
+grub_err_t
+grub_tpm_measure (unsigned char *buf, grub_size_t size, grub_uint8_t pcr,
+ const char *description)
+{
+ grub_err_t err = tpm_init ();
This should happen on module load. Then code in tpm_init() and here should
be much simpler.
I tried moving this into GRUB_MOD_INIT() but at that point it doesn't
succeed to find the device it seems. I have to repeat the tpm_init ()
call then later on in this function here when an actual measurement is
to be done and then it is able to find the device. I'd rather leave it
as-is now.
Hmmm... It looks like a bug in a firmware or initial TPM communication
fails/timeouts for some reason. Do not you loose some initial
tpm_init() , which also calls tpm_get_tpm_version(), don't even talk to the TPM
but they only access the OpenFirmware device tree and don't seem to find what
they are looking for when run that early.
measurements this way? Could you check what will happen when you call
No measurements are lost from what I can tell. The late initialization seems to
find the OF node it needs.
tpm_init() from GRUB_MOD_INIT 10, 50, 100 times?
I tried it now with this loop here. Well, not unexpected but the loop doesn't
change anything in this case since no timing is involved -- 'found', which I
print later on, stays at 0. Something related to the OpenFirmware tree seems to
not be initialized at this point.
GRUB_MOD_INIT (ibmvtpm)
{
grub_ieee1275_phandle_t vtpm;
int i;
for (i = 0; i < 100; i++) {
if (!grub_ieee1275_finddevice ("/vdevice/vtpm", &vtpm))
found++;
}
}
Stefan
It looked like this:
GRUB_MOD_INIT (ibmvtpm)
{
init_success = tpm_init ();
}
GRUB_MOD_FINI (ibmvtpm)
{
if (tpm_ihandle != IEEE1275_IHANDLE_INVALID)
grub_ieee1275_close (tpm_ihandle);
}
LGTM... Weird...
Daniel
- Re: [PATCH v2 2/6] ieee1275: drop len -= 1 quirk in heap_init, (continued)
[PATCH v2 3/6] ieee1275: support runtime memory claiming, Stefan Berger, 2022/12/01
[PATCH v2 5/6] Add memtool module with memory allocation stress-test, Stefan Berger, 2022/12/01