Re: [PATCH 0/2] add selftest for EFI_TCG2_PROTOCOL and Measured Boot
Hi Ilias, On Tue, 2 Nov 2021 at 10:28, Ilias Apalodimas wrote: > > Hi Simon. > > On Tue, 2 Nov 2021 at 16:55, Simon Glass wrote: > > > > Hi Masahisa, > > > > On Tue, 2 Nov 2021 at 02:03, Masahisa Kojima > > wrote: > > > > > > Hi Simon, > > > > > > On Mon, 25 Oct 2021 at 04:54, Simon Glass wrote: > > > > > > > > Hi Masahisa, > > > > > > > > On Fri, 22 Oct 2021 at 05:23, Masahisa Kojima > > > > wrote: > > > > > > > > > > This patch series adds the selftest for the EFI_TCG2_PROTOCOL and > > > > > Measured Boot flow. > > > > > This selftest is verified on qemu with swtpm. > > > > > > > > Is this in CI? Where are the instructions for doing this? > > > > > > Not yet included in CI. > > > For the instructions, Ilias is preparing the documentation at: > > > https://github.com/apalos/u-boot/commit/6edcf3c02996edf8c50a38632aac1091f8bcbf0b > > > > OK I see. > > > > > > > > > > > > > I have expressed my preference for expanding the in-tree emulator to > > > > handle this. > > > > > > For the measured boot selftest, I need to access the efi internal data > > > such as > > > SMBIOS table, that is why I chose the C based efi_selftest. > > > Tcg2 efi_selftest does not rely on the specific TPM backend. > > > > I don't understand this answer. I would still like to know how much > > code we would be talking about if we expand the TPM emulator in U-Boot > > for these extra features. From my understanding, the TPMs themselves > > are not that complicated and don't have a lot of code in them, > > particularly for the features we use. I am willing to believe that > > this might not be feasible, or be too much effort, but I have not seen > > anyone attempt it, or part of it, so I don't know. > > I don't have an exact answer for that either. It's definitely more > than the effort we need for the QEMU though. OK. How about implementing one thing so the test gets a little way along, to understand the effort? Or I could try it if you give instructions on how to run it. Because there is a benefit, it is not just all a cost. > > > With a TPM emulator > > we can encode any sort of test behaviour we want. It is much harder > > with QEMU. But I have not seen an answer for what is actually involved > > in doing this. > > QEMU just provides access to a standard (TIS compliant) TPM. So I > can't think of any tests that aren't already covered. Failures? > > > > > I know Ilias talked about bringing in swtpm to U-Boot. It seems like a > > lot of code so I am not sure if it is worth it. > > Just for clarification U-Boot is will get *zero* code for this wrt to > the TPM interface it self. The only thing you need is an MMIO TPM > driver for U-Boot, but that's not only usable in QEMU. There are > devices supported by U-Boot which have an MMIO based TPM (e.g the > synquacer box), so we need that driver regardless. Apart from that > patchset (which I'll resend within the week) you need a QEMU instance > with swtpm support described here [1] Yes I understand. > > > Perhaps it could be > > built against U-Boot sandbox as an option...I'm not sure. But the goal > > here is not to emulate a TPM, but to provide test coverage in an > > easily maintainable way. > > > > So to put my mind at ease, what would be involved in running this on > > sandbox? Are we talking hundreds of lines of code (which I think is > > worth it) or thousands (which is not)? > > Probably hundreds. I've responded here [2] with the basic > functionality that's missing. OK I can use that. So how do I to run this test on sandbox? - Simon > > [1] > https://github.com/apalos/u-boot/commit/6edcf3c02996edf8c50a38632aac1091f8bcbf0b > [2] > https://lore.kernel.org/u-boot/CAC_iWjLY-qH0ckQHh=WhvbVc2pa_a2COjr=g3cp8ZEdVxV6=a...@mail.gmail.com/ > > Regards > /Ilias > > > > > Regards, > > Simon > > > > > > > > > > Thanks, > > > Masahisa Kojima > > > > > > > > > > > > > > Regards, > > > > Simon > > > > > > > > > > > > > > > > > > This covers most of the functionalities, but there are some > > > > > limitations and TODO items. > > > > > > > > > > [Limitation] > > > > > - tcg2 selftest must run at the beginning of the efi_selftest because > > > > > some measurement occurs in efi_tcg2_register() and > > > > > boottime->image_load(). > > > > > Need to configure the efi_selftest with "setenv efi_selftest tcg2; > > > > > bootefi selftest" > > > > > - Skip ExitBootService measurement test > > > > >- EFI application can not read PCR after calling ExitBootService > > > > > - Skip EventLog Validation > > > > >- Measured Boot measures U-Boot version, so EventLog varies every > > > > > build having > > > > > different commit hash. > > > > > - Skip PCR[0] validation > > > > >- PCR[0] include U-Boot version measurement, this value varies > > > > > every build > > > > > having different commit hash. > > > > > - Skip PCR[7] validation > > > > >- Secure Boot Variables can not be updated through efi_selftest. > > > > > - The initial PCR value of PCR[17 - 22]
Re: [PATCH 0/2] add selftest for EFI_TCG2_PROTOCOL and Measured Boot
Hi Simon. On Tue, 2 Nov 2021 at 16:55, Simon Glass wrote: > > Hi Masahisa, > > On Tue, 2 Nov 2021 at 02:03, Masahisa Kojima > wrote: > > > > Hi Simon, > > > > On Mon, 25 Oct 2021 at 04:54, Simon Glass wrote: > > > > > > Hi Masahisa, > > > > > > On Fri, 22 Oct 2021 at 05:23, Masahisa Kojima > > > wrote: > > > > > > > > This patch series adds the selftest for the EFI_TCG2_PROTOCOL and > > > > Measured Boot flow. > > > > This selftest is verified on qemu with swtpm. > > > > > > Is this in CI? Where are the instructions for doing this? > > > > Not yet included in CI. > > For the instructions, Ilias is preparing the documentation at: > > https://github.com/apalos/u-boot/commit/6edcf3c02996edf8c50a38632aac1091f8bcbf0b > > OK I see. > > > > > > > > > I have expressed my preference for expanding the in-tree emulator to > > > handle this. > > > > For the measured boot selftest, I need to access the efi internal data such > > as > > SMBIOS table, that is why I chose the C based efi_selftest. > > Tcg2 efi_selftest does not rely on the specific TPM backend. > > I don't understand this answer. I would still like to know how much > code we would be talking about if we expand the TPM emulator in U-Boot > for these extra features. From my understanding, the TPMs themselves > are not that complicated and don't have a lot of code in them, > particularly for the features we use. I am willing to believe that > this might not be feasible, or be too much effort, but I have not seen > anyone attempt it, or part of it, so I don't know. I don't have an exact answer for that either. It's definitely more than the effort we need for the QEMU though. > With a TPM emulator > we can encode any sort of test behaviour we want. It is much harder > with QEMU. But I have not seen an answer for what is actually involved > in doing this. QEMU just provides access to a standard (TIS compliant) TPM. So I can't think of any tests that aren't already covered. > > I know Ilias talked about bringing in swtpm to U-Boot. It seems like a > lot of code so I am not sure if it is worth it. Just for clarification U-Boot is will get *zero* code for this wrt to the TPM interface it self. The only thing you need is an MMIO TPM driver for U-Boot, but that's not only usable in QEMU. There are devices supported by U-Boot which have an MMIO based TPM (e.g the synquacer box), so we need that driver regardless. Apart from that patchset (which I'll resend within the week) you need a QEMU instance with swtpm support described here [1] > Perhaps it could be > built against U-Boot sandbox as an option...I'm not sure. But the goal > here is not to emulate a TPM, but to provide test coverage in an > easily maintainable way. > > So to put my mind at ease, what would be involved in running this on > sandbox? Are we talking hundreds of lines of code (which I think is > worth it) or thousands (which is not)? Probably hundreds. I've responded here [2] with the basic functionality that's missing. [1] https://github.com/apalos/u-boot/commit/6edcf3c02996edf8c50a38632aac1091f8bcbf0b [2] https://lore.kernel.org/u-boot/CAC_iWjLY-qH0ckQHh=WhvbVc2pa_a2COjr=g3cp8ZEdVxV6=a...@mail.gmail.com/ Regards /Ilias > > Regards, > Simon > > > > > > Thanks, > > Masahisa Kojima > > > > > > > > > > Regards, > > > Simon > > > > > > > > > > > > > > This covers most of the functionalities, but there are some > > > > limitations and TODO items. > > > > > > > > [Limitation] > > > > - tcg2 selftest must run at the beginning of the efi_selftest because > > > > some measurement occurs in efi_tcg2_register() and > > > > boottime->image_load(). > > > > Need to configure the efi_selftest with "setenv efi_selftest tcg2; > > > > bootefi selftest" > > > > - Skip ExitBootService measurement test > > > >- EFI application can not read PCR after calling ExitBootService > > > > - Skip EventLog Validation > > > >- Measured Boot measures U-Boot version, so EventLog varies every > > > > build having > > > > different commit hash. > > > > - Skip PCR[0] validation > > > >- PCR[0] include U-Boot version measurement, this value varies every > > > > build > > > > having different commit hash. > > > > - Skip PCR[7] validation > > > >- Secure Boot Variables can not be updated through efi_selftest. > > > > - The initial PCR value of PCR[17 - 22] is all 0xff, I'm not sure > > > > it is expected or not. > > > > > > > > [TODO] > > > > - GPT measurement test > > > > - Secure Boot Variable test > > > > - Eventlog validation > > > > > > > > Masahisa Kojima (2): > > > > efi_loader: add missing const qualifier > > > > efi_selftest: add selftest for EFI_TCG2_PROTOCOL and Measured Boot > > > > > > > > include/efi_api.h | 2 +- > > > > lib/efi_loader/efi_boottime.c | 5 +- > > > > lib/efi_selftest/Makefile | 10 + > > > > .../efi_selftest_miniapp_measuredboot.c | 93 ++ > > > >
Re: [PATCH 0/2] add selftest for EFI_TCG2_PROTOCOL and Measured Boot
Hi Masahisa, On Tue, 2 Nov 2021 at 02:03, Masahisa Kojima wrote: > > Hi Simon, > > On Mon, 25 Oct 2021 at 04:54, Simon Glass wrote: > > > > Hi Masahisa, > > > > On Fri, 22 Oct 2021 at 05:23, Masahisa Kojima > > wrote: > > > > > > This patch series adds the selftest for the EFI_TCG2_PROTOCOL and > > > Measured Boot flow. > > > This selftest is verified on qemu with swtpm. > > > > Is this in CI? Where are the instructions for doing this? > > Not yet included in CI. > For the instructions, Ilias is preparing the documentation at: > https://github.com/apalos/u-boot/commit/6edcf3c02996edf8c50a38632aac1091f8bcbf0b OK I see. > > > > > I have expressed my preference for expanding the in-tree emulator to > > handle this. > > For the measured boot selftest, I need to access the efi internal data such as > SMBIOS table, that is why I chose the C based efi_selftest. > Tcg2 efi_selftest does not rely on the specific TPM backend. I don't understand this answer. I would still like to know how much code we would be talking about if we expand the TPM emulator in U-Boot for these extra features. From my understanding, the TPMs themselves are not that complicated and don't have a lot of code in them, particularly for the features we use. I am willing to believe that this might not be feasible, or be too much effort, but I have not seen anyone attempt it, or part of it, so I don't know. With a TPM emulator we can encode any sort of test behaviour we want. It is much harder with QEMU. But I have not seen an answer for what is actually involved in doing this. I know Ilias talked about bringing in swtpm to U-Boot. It seems like a lot of code so I am not sure if it is worth it. Perhaps it could be built against U-Boot sandbox as an option...I'm not sure. But the goal here is not to emulate a TPM, but to provide test coverage in an easily maintainable way. So to put my mind at ease, what would be involved in running this on sandbox? Are we talking hundreds of lines of code (which I think is worth it) or thousands (which is not)? Regards, Simon > > Thanks, > Masahisa Kojima > > > > > > Regards, > > Simon > > > > > > > > > > This covers most of the functionalities, but there are some > > > limitations and TODO items. > > > > > > [Limitation] > > > - tcg2 selftest must run at the beginning of the efi_selftest because > > > some measurement occurs in efi_tcg2_register() and > > > boottime->image_load(). > > > Need to configure the efi_selftest with "setenv efi_selftest tcg2; > > > bootefi selftest" > > > - Skip ExitBootService measurement test > > >- EFI application can not read PCR after calling ExitBootService > > > - Skip EventLog Validation > > >- Measured Boot measures U-Boot version, so EventLog varies every > > > build having > > > different commit hash. > > > - Skip PCR[0] validation > > >- PCR[0] include U-Boot version measurement, this value varies every > > > build > > > having different commit hash. > > > - Skip PCR[7] validation > > >- Secure Boot Variables can not be updated through efi_selftest. > > > - The initial PCR value of PCR[17 - 22] is all 0xff, I'm not sure > > > it is expected or not. > > > > > > [TODO] > > > - GPT measurement test > > > - Secure Boot Variable test > > > - Eventlog validation > > > > > > Masahisa Kojima (2): > > > efi_loader: add missing const qualifier > > > efi_selftest: add selftest for EFI_TCG2_PROTOCOL and Measured Boot > > > > > > include/efi_api.h | 2 +- > > > lib/efi_loader/efi_boottime.c | 5 +- > > > lib/efi_selftest/Makefile | 10 + > > > .../efi_selftest_miniapp_measuredboot.c | 93 ++ > > > lib/efi_selftest/efi_selftest_tcg2.c | 804 +- > > > 5 files changed, 910 insertions(+), 4 deletions(-) > > > create mode 100644 lib/efi_selftest/efi_selftest_miniapp_measuredboot.c > > > > > > -- > > > 2.17.1 > > >
Re: [PATCH 0/2] add selftest for EFI_TCG2_PROTOCOL and Measured Boot
Hi Simon, On Mon, 25 Oct 2021 at 04:54, Simon Glass wrote: > > Hi Masahisa, > > On Fri, 22 Oct 2021 at 05:23, Masahisa Kojima > wrote: > > > > This patch series adds the selftest for the EFI_TCG2_PROTOCOL and > > Measured Boot flow. > > This selftest is verified on qemu with swtpm. > > Is this in CI? Where are the instructions for doing this? Not yet included in CI. For the instructions, Ilias is preparing the documentation at: https://github.com/apalos/u-boot/commit/6edcf3c02996edf8c50a38632aac1091f8bcbf0b > > I have expressed my preference for expanding the in-tree emulator to > handle this. For the measured boot selftest, I need to access the efi internal data such as SMBIOS table, that is why I chose the C based efi_selftest. Tcg2 efi_selftest does not rely on the specific TPM backend. Thanks, Masahisa Kojima > > Regards, > Simon > > > > > > This covers most of the functionalities, but there are some > > limitations and TODO items. > > > > [Limitation] > > - tcg2 selftest must run at the beginning of the efi_selftest because > > some measurement occurs in efi_tcg2_register() and boottime->image_load(). > > Need to configure the efi_selftest with "setenv efi_selftest tcg2; > > bootefi selftest" > > - Skip ExitBootService measurement test > >- EFI application can not read PCR after calling ExitBootService > > - Skip EventLog Validation > >- Measured Boot measures U-Boot version, so EventLog varies every build > > having > > different commit hash. > > - Skip PCR[0] validation > >- PCR[0] include U-Boot version measurement, this value varies every > > build > > having different commit hash. > > - Skip PCR[7] validation > >- Secure Boot Variables can not be updated through efi_selftest. > > - The initial PCR value of PCR[17 - 22] is all 0xff, I'm not sure > > it is expected or not. > > > > [TODO] > > - GPT measurement test > > - Secure Boot Variable test > > - Eventlog validation > > > > Masahisa Kojima (2): > > efi_loader: add missing const qualifier > > efi_selftest: add selftest for EFI_TCG2_PROTOCOL and Measured Boot > > > > include/efi_api.h | 2 +- > > lib/efi_loader/efi_boottime.c | 5 +- > > lib/efi_selftest/Makefile | 10 + > > .../efi_selftest_miniapp_measuredboot.c | 93 ++ > > lib/efi_selftest/efi_selftest_tcg2.c | 804 +- > > 5 files changed, 910 insertions(+), 4 deletions(-) > > create mode 100644 lib/efi_selftest/efi_selftest_miniapp_measuredboot.c > > > > -- > > 2.17.1 > >
Re: [PATCH 0/2] add selftest for EFI_TCG2_PROTOCOL and Measured Boot
Hi Masahisa, On Fri, 22 Oct 2021 at 05:23, Masahisa Kojima wrote: > > This patch series adds the selftest for the EFI_TCG2_PROTOCOL and > Measured Boot flow. > This selftest is verified on qemu with swtpm. Is this in CI? Where are the instructions for doing this? I have expressed my preference for expanding the in-tree emulator to handle this. Regards, Simon > > This covers most of the functionalities, but there are some > limitations and TODO items. > > [Limitation] > - tcg2 selftest must run at the beginning of the efi_selftest because > some measurement occurs in efi_tcg2_register() and boottime->image_load(). > Need to configure the efi_selftest with "setenv efi_selftest tcg2; bootefi > selftest" > - Skip ExitBootService measurement test >- EFI application can not read PCR after calling ExitBootService > - Skip EventLog Validation >- Measured Boot measures U-Boot version, so EventLog varies every build > having > different commit hash. > - Skip PCR[0] validation >- PCR[0] include U-Boot version measurement, this value varies every build > having different commit hash. > - Skip PCR[7] validation >- Secure Boot Variables can not be updated through efi_selftest. > - The initial PCR value of PCR[17 - 22] is all 0xff, I'm not sure > it is expected or not. > > [TODO] > - GPT measurement test > - Secure Boot Variable test > - Eventlog validation > > Masahisa Kojima (2): > efi_loader: add missing const qualifier > efi_selftest: add selftest for EFI_TCG2_PROTOCOL and Measured Boot > > include/efi_api.h | 2 +- > lib/efi_loader/efi_boottime.c | 5 +- > lib/efi_selftest/Makefile | 10 + > .../efi_selftest_miniapp_measuredboot.c | 93 ++ > lib/efi_selftest/efi_selftest_tcg2.c | 804 +- > 5 files changed, 910 insertions(+), 4 deletions(-) > create mode 100644 lib/efi_selftest/efi_selftest_miniapp_measuredboot.c > > -- > 2.17.1 >
