Discussion:
TPM support within Grub2
Daniel P. Smith
2018-07-01 23:09:30 UTC
Permalink
Greetings,

I have a measured boot implementation I have been working on that
introduces a DRTM relocator that I would like to eventually upstream.
This work does rely on the ability to access a TPM 1.2 chip from within
Grub2. I am aware of Matthew Garrett's pending patch to add core TPM
support[1] but that is limited to UEFI environments. My target
environment uses Coreboot with the TCG BIOS payload to launch the
environment. For TPM support I am using code picked out of the
TrustedGRUB2 fork[2]. As a precursor to upstreaming my DRTM relocator, I
would like to see if I could find a way to generically introduce TPM
support into Grub2 that support's Matthew's UEFI backend, TrustedGrub2's
TPM 1.2 raw I/O, as well as leave a path for TPM2 raw I/O. In both
implementations TPM support is include as an x86 device when in fact
they can also be found in ARM devices, which is on my wish list of
future devices I would like to support. With all of this in mind, I
wanted to open a discussion on the best way to implement generic TPM
support. In Matthew's approach TPM is implemented under
grub-core/commands while TrustedGRUB2 is split between grub-core/kern
and grub-core/tpm. IMHO TPM functionality should be divided into HW
interfaces, TPM command processing, and higher order TPM operations. If
the logic was segmented in this manner, what are other's opinions on
where segments of logic should reside within the Grub2 source tree?


[1] http://lists.gnu.org/archive/html/grub-devel/2017-07/msg00005.html
[2] https://github.com/Rohde-Schwarz-Cybersecurity/TrustedGRUB2
Daniel Kiper
2018-07-02 16:35:08 UTC
Permalink
Hi Daniel,
Post by Daniel P. Smith
Greetings,
I have a measured boot implementation I have been working on that
introduces a DRTM relocator that I would like to eventually upstream.
This work does rely on the ability to access a TPM 1.2 chip from within
Grub2. I am aware of Matthew Garrett's pending patch to add core TPM
support[1] but that is limited to UEFI environments. My target
environment uses Coreboot with the TCG BIOS payload to launch the
environment. For TPM support I am using code picked out of the
TrustedGRUB2 fork[2]. As a precursor to upstreaming my DRTM relocator, I
would like to see if I could find a way to generically introduce TPM
support into Grub2 that support's Matthew's UEFI backend, TrustedGrub2's
TPM 1.2 raw I/O, as well as leave a path for TPM2 raw I/O. In both
implementations TPM support is include as an x86 device when in fact
they can also be found in ARM devices, which is on my wish list of
future devices I would like to support. With all of this in mind, I
wanted to open a discussion on the best way to implement generic TPM
support. In Matthew's approach TPM is implemented under
grub-core/commands while TrustedGRUB2 is split between grub-core/kern
and grub-core/tpm. IMHO TPM functionality should be divided into HW
interfaces, TPM command processing, and higher order TPM operations. If
the logic was segmented in this manner, what are other's opinions on
where segments of logic should reside within the Grub2 source tree?
[1] http://lists.gnu.org/archive/html/grub-devel/2017-07/msg00005.html
[2] https://github.com/Rohde-Schwarz-Cybersecurity/TrustedGRUB2
This comes just in time. I am back from vacation and I am going to
revisit the issue (including the verifiers framework). I will take
deeper dive in it probably at the end of this week or at the beginning
of next one after clearing my backlog. In meantime I am CC-ing guys
who may be interested in that project too.

Stay tuned...

Daniel
Daniel Kiper
2018-07-16 12:06:12 UTC
Permalink
Post by Daniel Kiper
Hi Daniel,
Post by Daniel P. Smith
Greetings,
I have a measured boot implementation I have been working on that
introduces a DRTM relocator that I would like to eventually upstream.
This work does rely on the ability to access a TPM 1.2 chip from within
Grub2. I am aware of Matthew Garrett's pending patch to add core TPM
support[1] but that is limited to UEFI environments. My target
environment uses Coreboot with the TCG BIOS payload to launch the
environment. For TPM support I am using code picked out of the
TrustedGRUB2 fork[2]. As a precursor to upstreaming my DRTM relocator, I
would like to see if I could find a way to generically introduce TPM
support into Grub2 that support's Matthew's UEFI backend, TrustedGrub2's
TPM 1.2 raw I/O, as well as leave a path for TPM2 raw I/O. In both
implementations TPM support is include as an x86 device when in fact
they can also be found in ARM devices, which is on my wish list of
future devices I would like to support. With all of this in mind, I
wanted to open a discussion on the best way to implement generic TPM
support. In Matthew's approach TPM is implemented under
grub-core/commands while TrustedGRUB2 is split between grub-core/kern
and grub-core/tpm. IMHO TPM functionality should be divided into HW
interfaces, TPM command processing, and higher order TPM operations. If
the logic was segmented in this manner, what are other's opinions on
where segments of logic should reside within the Grub2 source tree?
[1] http://lists.gnu.org/archive/html/grub-devel/2017-07/msg00005.html
[2] https://github.com/Rohde-Schwarz-Cybersecurity/TrustedGRUB2
In general I am not against reorganization you are mentioning above.
Though I think that then you should rearange Matthew code and repost
it. Of course if Matthew does not object.

Another thing is the verifiers framework. It would be nice if you could
hook your work there. Though you have to remember about other users like
UEFI secure boot (https://lists.xen.org/archives/html/xen-devel/2017-07/msg00985.html;
I am going to revive work on this patch) or GPG signatures. So, please
take a look at that code at git://git.savannah.gnu.org/grub.git,
phcoder/verifiers branch. If it works for you I will post the patches,
with minor fixes and improvements which are worth doing, for review (of
course if Vladimir does not object). If you discover any issues with the
verifiers framework just drop me a line and then we will try to fix them.

And another thing... Could not we reuse Philip TPM 2.0 work in GRUB2 somehow?

Daniel
Daniel P. Smith
2018-07-16 16:33:42 UTC
Permalink
Post by Daniel Kiper
Post by Daniel Kiper
Hi Daniel,
Post by Daniel P. Smith
Greetings,
I have a measured boot implementation I have been working on that
introduces a DRTM relocator that I would like to eventually upstream.
This work does rely on the ability to access a TPM 1.2 chip from within
Grub2. I am aware of Matthew Garrett's pending patch to add core TPM
support[1] but that is limited to UEFI environments. My target
environment uses Coreboot with the TCG BIOS payload to launch the
environment. For TPM support I am using code picked out of the
TrustedGRUB2 fork[2]. As a precursor to upstreaming my DRTM relocator, I
would like to see if I could find a way to generically introduce TPM
support into Grub2 that support's Matthew's UEFI backend, TrustedGrub2's
TPM 1.2 raw I/O, as well as leave a path for TPM2 raw I/O. In both
implementations TPM support is include as an x86 device when in fact
they can also be found in ARM devices, which is on my wish list of
future devices I would like to support. With all of this in mind, I
wanted to open a discussion on the best way to implement generic TPM
support. In Matthew's approach TPM is implemented under
grub-core/commands while TrustedGRUB2 is split between grub-core/kern
and grub-core/tpm. IMHO TPM functionality should be divided into HW
interfaces, TPM command processing, and higher order TPM operations. If
the logic was segmented in this manner, what are other's opinions on
where segments of logic should reside within the Grub2 source tree?
[1] http://lists.gnu.org/archive/html/grub-devel/2017-07/msg00005.html
[2] https://github.com/Rohde-Schwarz-Cybersecurity/TrustedGRUB2
In general I am not against reorganization you are mentioning above.
Though I think that then you should rearange Matthew code and repost
it. Of course if Matthew does not object.
I can align Matthew's code or if he would like, he is more than welcome
to collaborate on the solution.
Post by Daniel Kiper
Another thing is the verifiers framework. It would be nice if you could
hook your work there. Though you have to remember about other users like
UEFI secure boot (https://lists.xen.org/archives/html/xen-devel/2017-07/msg00985.html;
I am going to revive work on this patch) or GPG signatures. So, please
take a look at that code at git://git.savannah.gnu.org/grub.git,
phcoder/verifiers branch. If it works for you I will post the patches,
with minor fixes and improvements which are worth doing, for review (of
course if Vladimir does not object). If you discover any issues with the
verifiers framework just drop me a line and then we will try to fix them.
Yes, I figured I would be using the verifier framework. The only
suggestion I would have based on my work is that I am going to have to
establish a TPM event log since I will be doing raw IO with the TPM. I
think it would be useful if the verifier framework had an event log
component that verifier modules could log events that they want to have
passed to the OS kernel being booted. For an example of how to pass the
log along to the OS kernel, for TrenchBoot the plan is to pass via the
setup data boot protocol field of Linux. For mutliboot kernels, the log
could easily be passed as a mb module. Let me know what you think.
Post by Daniel Kiper
And another thing... Could not we reuse Philip TPM 2.0 work in GRUB2 somehow?
Phil's work is dealing with the TSS/TIS software layers which provide
higher abstractions over the TPM. For TPM2 in the absence of or distrust
in the EFI firmware, it is possible to do a raw IO interface directly
with the TPM. An example of doing that can be seen in tboot, which if
you look is a bit more complex than the TPM 1.2 interface.
Post by Daniel Kiper
Daniel
v/r,
dps
Daniel Kiper
2018-07-17 13:04:11 UTC
Permalink
Post by Daniel P. Smith
Post by Daniel Kiper
Post by Daniel Kiper
Hi Daniel,
Post by Daniel P. Smith
Greetings,
I have a measured boot implementation I have been working on that
introduces a DRTM relocator that I would like to eventually upstream.
This work does rely on the ability to access a TPM 1.2 chip from within
Grub2. I am aware of Matthew Garrett's pending patch to add core TPM
support[1] but that is limited to UEFI environments. My target
environment uses Coreboot with the TCG BIOS payload to launch the
environment. For TPM support I am using code picked out of the
TrustedGRUB2 fork[2]. As a precursor to upstreaming my DRTM relocator, I
would like to see if I could find a way to generically introduce TPM
support into Grub2 that support's Matthew's UEFI backend, TrustedGrub2's
TPM 1.2 raw I/O, as well as leave a path for TPM2 raw I/O. In both
implementations TPM support is include as an x86 device when in fact
they can also be found in ARM devices, which is on my wish list of
future devices I would like to support. With all of this in mind, I
wanted to open a discussion on the best way to implement generic TPM
support. In Matthew's approach TPM is implemented under
grub-core/commands while TrustedGRUB2 is split between grub-core/kern
and grub-core/tpm. IMHO TPM functionality should be divided into HW
interfaces, TPM command processing, and higher order TPM operations. If
the logic was segmented in this manner, what are other's opinions on
where segments of logic should reside within the Grub2 source tree?
[1] http://lists.gnu.org/archive/html/grub-devel/2017-07/msg00005.html
[2] https://github.com/Rohde-Schwarz-Cybersecurity/TrustedGRUB2
In general I am not against reorganization you are mentioning above.
Though I think that then you should rearange Matthew code and repost
it. Of course if Matthew does not object.
I can align Matthew's code or if he would like, he is more than welcome
to collaborate on the solution.
Both options work for me.
Post by Daniel P. Smith
Post by Daniel Kiper
Another thing is the verifiers framework. It would be nice if you could
hook your work there. Though you have to remember about other users like
UEFI secure boot (https://lists.xen.org/archives/html/xen-devel/2017-07/msg00985.html;
I am going to revive work on this patch) or GPG signatures. So, please
take a look at that code at git://git.savannah.gnu.org/grub.git,
phcoder/verifiers branch. If it works for you I will post the patches,
with minor fixes and improvements which are worth doing, for review (of
course if Vladimir does not object). If you discover any issues with the
verifiers framework just drop me a line and then we will try to fix them.
Yes, I figured I would be using the verifier framework. The only
Great!
Post by Daniel P. Smith
suggestion I would have based on my work is that I am going to have to
establish a TPM event log since I will be doing raw IO with the TPM. I
think it would be useful if the verifier framework had an event log
component that verifier modules could log events that they want to have
passed to the OS kernel being booted. For an example of how to pass the
If you need that may I ask you to add this functionality on top of
existing verifiers framework? I think that you can start your work
with the branch which I posted earlier. In a week or two I will post
its updated version on the list for review.
Post by Daniel P. Smith
log along to the OS kernel, for TrenchBoot the plan is to pass via the
setup data boot protocol field of Linux. For mutliboot kernels, the log
OK.
Post by Daniel P. Smith
could easily be passed as a mb module. Let me know what you think.
If you consider a module then I would like to ask you to add a header at
the beginning of the log which clearly identifies its type. This way the
OS boot will not depend on the module order or something like that. If
that does not work for you then you can add a tag similar to module but
with an extra member identifying the type of provided data.

By the way, I think that we should focus on Multiboot2 protocol only.
Post by Daniel P. Smith
Post by Daniel Kiper
And another thing... Could not we reuse Philip TPM 2.0 work in GRUB2 somehow?
Phil's work is dealing with the TSS/TIS software layers which provide
higher abstractions over the TPM. For TPM2 in the absence of or distrust
in the EFI firmware, it is possible to do a raw IO interface directly
with the TPM. An example of doing that can be seen in tboot, which if
you look is a bit more complex than the TPM 1.2 interface.
OK but IIRC there were also low level drivers in it. If it is true then
we could steal them.

WRT EFI and TPM. I think that by default TPM (2.0) GRUB2 drivers should
use EFI infrastructure to control the TPM. Though there should be an option
to skip the EFI stuff and drive the TPM directly.

Daniel
Matthew Garrett
2018-07-17 18:10:32 UTC
Permalink
Post by Daniel P. Smith
Post by Daniel Kiper
In general I am not against reorganization you are mentioning above.
Though I think that then you should rearange Matthew code and repost
it. Of course if Matthew does not object.
I can align Matthew's code or if he would like, he is more than welcome
to collaborate on the solution.
There's a lot of user demand for TPM2 support in grub, so my preference
would be:

1) Review and merge the verifiers framework
2) Update the current TPM2 code to match and review and merge that
3) Ensure that the functionality matches user expectations and then
develop a more generic midlayer based on that to support additional TPM
backends

My concern about doing (3) before (2) is that it may take multiple
attempts to develop something that works for us, and delay being able to
provide functionality that people would like to take advantage of. I
think some real-world use would make the process easier.
--
Matthew Garrett | ***@srcf.ucam.org
Daniel Kiper
2018-07-18 09:03:17 UTC
Permalink
Post by Matthew Garrett
Post by Daniel P. Smith
Post by Daniel Kiper
In general I am not against reorganization you are mentioning above.
Though I think that then you should rearange Matthew code and repost
it. Of course if Matthew does not object.
I can align Matthew's code or if he would like, he is more than welcome
to collaborate on the solution.
There's a lot of user demand for TPM2 support in grub, so my preference
1) Review and merge the verifiers framework
OK, as I said earlier I will post it with some comments and minor
fixes in a week or two.
Post by Matthew Garrett
2) Update the current TPM2 code to match and review and merge that
3) Ensure that the functionality matches user expectations and then
develop a more generic midlayer based on that to support additional TPM
backends
My concern about doing (3) before (2) is that it may take multiple
attempts to develop something that works for us, and delay being able to
provide functionality that people would like to take advantage of. I
think some real-world use would make the process easier.
This option works for me too. If Daniel S. is OK with that we can proceed.

Daniel
Javier Martinez Canillas
2018-07-18 16:08:46 UTC
Permalink
Post by Daniel Kiper
Post by Matthew Garrett
Post by Daniel P. Smith
Post by Daniel Kiper
In general I am not against reorganization you are mentioning above.
Though I think that then you should rearange Matthew code and repost
it. Of course if Matthew does not object.
I can align Matthew's code or if he would like, he is more than welcome
to collaborate on the solution.
There's a lot of user demand for TPM2 support in grub, so my preference
1) Review and merge the verifiers framework
OK, as I said earlier I will post it with some comments and minor
fixes in a week or two.
Post by Matthew Garrett
2) Update the current TPM2 code to match and review and merge that
3) Ensure that the functionality matches user expectations and then
develop a more generic midlayer based on that to support additional TPM
backends
My concern about doing (3) before (2) is that it may take multiple
attempts to develop something that works for us, and delay being able to
provide functionality that people would like to take advantage of. I
think some real-world use would make the process easier.
This option works for me too. If Daniel S. is OK with that we can proceed.
FWIW I agree too, specially since Matthew's patches have been in the list
for more than a year now, so I don't see a reason to hold the TPM support
much longer just to make it more generic.

I think (3) can be built on top of the current patch-set once this lands,
while providing UEFI TPM support to users in the meantime.
Post by Daniel Kiper
Daniel
Best regards,
--
Javier Martinez Canillas
Software Engineer - Desktop Hardware Enablement
Red Hat
Daniel P. Smith
2018-07-18 20:30:34 UTC
Permalink
Post by Daniel Kiper
Post by Matthew Garrett
Post by Daniel P. Smith
Post by Daniel Kiper
In general I am not against reorganization you are mentioning above.
Though I think that then you should rearange Matthew code and repost
it. Of course if Matthew does not object.
I can align Matthew's code or if he would like, he is more than welcome
to collaborate on the solution.
There's a lot of user demand for TPM2 support in grub, so my preference
1) Review and merge the verifiers framework
OK, as I said earlier I will post it with some comments and minor
fixes in a week or two.
Post by Matthew Garrett
2) Update the current TPM2 code to match and review and merge that
3) Ensure that the functionality matches user expectations and then
develop a more generic midlayer based on that to support additional TPM
backends
My concern about doing (3) before (2) is that it may take multiple
attempts to develop something that works for us, and delay being able to
provide functionality that people would like to take advantage of. I
think some real-world use would make the process easier.
This option works for me too. If Daniel S. is OK with that we can proceed.
I appreciate being asked to review though I think Phil's sign off
probably carries more weight than mine. I did review the patches when
Matthew posted (which they look good) and there is interest in on my
part to see them go in sooner than later.
Post by Daniel Kiper
Daniel
Daniel Kiper
2018-07-20 11:37:31 UTC
Permalink
Post by Daniel P. Smith
Post by Daniel Kiper
Post by Matthew Garrett
Post by Daniel P. Smith
Post by Daniel Kiper
In general I am not against reorganization you are mentioning above.
Though I think that then you should rearange Matthew code and repost
it. Of course if Matthew does not object.
I can align Matthew's code or if he would like, he is more than welcome
to collaborate on the solution.
There's a lot of user demand for TPM2 support in grub, so my preference
1) Review and merge the verifiers framework
OK, as I said earlier I will post it with some comments and minor
fixes in a week or two.
Post by Matthew Garrett
2) Update the current TPM2 code to match and review and merge that
3) Ensure that the functionality matches user expectations and then
develop a more generic midlayer based on that to support additional TPM
backends
My concern about doing (3) before (2) is that it may take multiple
attempts to develop something that works for us, and delay being able to
provide functionality that people would like to take advantage of. I
think some real-world use would make the process easier.
This option works for me too. If Daniel S. is OK with that we can proceed.
I appreciate being asked to review though I think Phil's sign off
probably carries more weight than mine. I did review the patches when
Matthew posted (which they look good) and there is interest in on my
part to see them go in sooner than later.
OK, so, I am taking a stab at verifiers framework first and then
Mathew's TPM2 patches. Stay tuned... Next news in a week or two.

Daniel

Philip Tricca
2018-07-17 17:22:01 UTC
Permalink
Post by Daniel P. Smith
Post by Daniel Kiper
Post by Daniel Kiper
Hi Daniel,
Post by Daniel P. Smith
Greetings,
I have a measured boot implementation I have been working on that
introduces a DRTM relocator that I would like to eventually upstream.
This work does rely on the ability to access a TPM 1.2 chip from within
Grub2. I am aware of Matthew Garrett's pending patch to add core TPM
support[1] but that is limited to UEFI environments. My target
environment uses Coreboot with the TCG BIOS payload to launch the
environment. For TPM support I am using code picked out of the
TrustedGRUB2 fork[2]. As a precursor to upstreaming my DRTM relocator, I
would like to see if I could find a way to generically introduce TPM
support into Grub2 that support's Matthew's UEFI backend, TrustedGrub2's
TPM 1.2 raw I/O, as well as leave a path for TPM2 raw I/O. In both
implementations TPM support is include as an x86 device when in fact
they can also be found in ARM devices, which is on my wish list of
future devices I would like to support. With all of this in mind, I
wanted to open a discussion on the best way to implement generic TPM
support. In Matthew's approach TPM is implemented under
grub-core/commands while TrustedGRUB2 is split between grub-core/kern
and grub-core/tpm. IMHO TPM functionality should be divided into HW
interfaces, TPM command processing, and higher order TPM operations. If
the logic was segmented in this manner, what are other's opinions on
where segments of logic should reside within the Grub2 source tree?
[1] http://lists.gnu.org/archive/html/grub-devel/2017-07/msg00005.html
[2] https://github.com/Rohde-Schwarz-Cybersecurity/TrustedGRUB2
In general I am not against reorganization you are mentioning above.
Though I think that then you should rearange Matthew code and repost
it. Of course if Matthew does not object.
I can align Matthew's code or if he would like, he is more than welcome
to collaborate on the solution.
Post by Daniel Kiper
Another thing is the verifiers framework. It would be nice if you could
hook your work there. Though you have to remember about other users like
UEFI secure boot (https://lists.xen.org/archives/html/xen-devel/2017-07/msg00985.html;
I am going to revive work on this patch) or GPG signatures. So, please
take a look at that code at git://git.savannah.gnu.org/grub.git,
phcoder/verifiers branch. If it works for you I will post the patches,
with minor fixes and improvements which are worth doing, for review (of
course if Vladimir does not object). If you discover any issues with the
verifiers framework just drop me a line and then we will try to fix them.
Yes, I figured I would be using the verifier framework. The only
suggestion I would have based on my work is that I am going to have to
establish a TPM event log since I will be doing raw IO with the TPM. I
think it would be useful if the verifier framework had an event log
component that verifier modules could log events that they want to have
passed to the OS kernel being booted. For an example of how to pass the
log along to the OS kernel, for TrenchBoot the plan is to pass via the
setup data boot protocol field of Linux. For mutliboot kernels, the log
could easily be passed as a mb module. Let me know what you think.
Post by Daniel Kiper
And another thing... Could not we reuse Philip TPM 2.0 work in GRUB2 somehow?
Phil's work is dealing with the TSS/TIS software layers which provide
higher abstractions over the TPM.
This is false. The APIs from the TSS are ignorant of and unrelated to
the TIS. Further, the "System API" has a 1:1 correspondence with
TPM2 commands effectively providing no abstraction beyond the
serialization of C types to / from the TPM2 command / response byte
stream. This is why we recommend that only firmware and "expert"
applications use it directly.

Philip
Daniel P. Smith
2018-07-18 20:22:54 UTC
Permalink
Post by Philip Tricca
Post by Daniel P. Smith
Post by Daniel Kiper
Post by Daniel Kiper
Hi Daniel,
Post by Daniel P. Smith
Greetings,
I have a measured boot implementation I have been working on that
introduces a DRTM relocator that I would like to eventually upstream.
This work does rely on the ability to access a TPM 1.2 chip from within
Grub2. I am aware of Matthew Garrett's pending patch to add core TPM
support[1] but that is limited to UEFI environments. My target
environment uses Coreboot with the TCG BIOS payload to launch the
environment. For TPM support I am using code picked out of the
TrustedGRUB2 fork[2]. As a precursor to upstreaming my DRTM relocator, I
would like to see if I could find a way to generically introduce TPM
support into Grub2 that support's Matthew's UEFI backend, TrustedGrub2's
TPM 1.2 raw I/O, as well as leave a path for TPM2 raw I/O. In both
implementations TPM support is include as an x86 device when in fact
they can also be found in ARM devices, which is on my wish list of
future devices I would like to support. With all of this in mind, I
wanted to open a discussion on the best way to implement generic TPM
support. In Matthew's approach TPM is implemented under
grub-core/commands while TrustedGRUB2 is split between grub-core/kern
and grub-core/tpm. IMHO TPM functionality should be divided into HW
interfaces, TPM command processing, and higher order TPM operations. If
the logic was segmented in this manner, what are other's opinions on
where segments of logic should reside within the Grub2 source tree?
[1] http://lists.gnu.org/archive/html/grub-devel/2017-07/msg00005.html
[2] https://github.com/Rohde-Schwarz-Cybersecurity/TrustedGRUB2
In general I am not against reorganization you are mentioning above.
Though I think that then you should rearange Matthew code and repost
it. Of course if Matthew does not object.
I can align Matthew's code or if he would like, he is more than welcome
to collaborate on the solution.
Post by Daniel Kiper
Another thing is the verifiers framework. It would be nice if you could
hook your work there. Though you have to remember about other users like
UEFI secure boot (https://lists.xen.org/archives/html/xen-devel/2017-07/msg00985.html;
I am going to revive work on this patch) or GPG signatures. So, please
take a look at that code at git://git.savannah.gnu.org/grub.git,
phcoder/verifiers branch. If it works for you I will post the patches,
with minor fixes and improvements which are worth doing, for review (of
course if Vladimir does not object). If you discover any issues with the
verifiers framework just drop me a line and then we will try to fix them.
Yes, I figured I would be using the verifier framework. The only
suggestion I would have based on my work is that I am going to have to
establish a TPM event log since I will be doing raw IO with the TPM. I
think it would be useful if the verifier framework had an event log
component that verifier modules could log events that they want to have
passed to the OS kernel being booted. For an example of how to pass the
log along to the OS kernel, for TrenchBoot the plan is to pass via the
setup data boot protocol field of Linux. For mutliboot kernels, the log
could easily be passed as a mb module. Let me know what you think.
Post by Daniel Kiper
And another thing... Could not we reuse Philip TPM 2.0 work in GRUB2 somehow?
Phil's work is dealing with the TSS/TIS software layers which provide
higher abstractions over the TPM.
This is false. The APIs from the TSS are ignorant of and unrelated to
the TIS. Further, the "System API" has a 1:1 correspondence with
TPM2 commands effectively providing no abstraction beyond the
serialization of C types to / from the TPM2 command / response byte
stream. This is why we recommend that only firmware and "expert"
applications use it directly.
It was a misnomer to throw TIS in that statement since TSS is really the
software part, bad habit on my part to refer to them collectively. I was
just making a short collective statement that TSS as a whole provides a
set of layers to provide higher abstractions and yes one of those layers
is the one is the C code that implements the hardware interface. My
apologies for the vague statement.
Post by Philip Tricca
Philip
v/r,
dps
Philip Tricca
2018-07-17 16:57:56 UTC
Permalink
Post by Daniel Kiper
Post by Daniel Kiper
Hi Daniel,
Post by Daniel P. Smith
Greetings,
I have a measured boot implementation I have been working on that
introduces a DRTM relocator that I would like to eventually upstream.
This work does rely on the ability to access a TPM 1.2 chip from within
Grub2. I am aware of Matthew Garrett's pending patch to add core TPM
support[1] but that is limited to UEFI environments. My target
environment uses Coreboot with the TCG BIOS payload to launch the
environment. For TPM support I am using code picked out of the
TrustedGRUB2 fork[2]. As a precursor to upstreaming my DRTM relocator, I
would like to see if I could find a way to generically introduce TPM
support into Grub2 that support's Matthew's UEFI backend, TrustedGrub2's
TPM 1.2 raw I/O, as well as leave a path for TPM2 raw I/O. In both
implementations TPM support is include as an x86 device when in fact
they can also be found in ARM devices, which is on my wish list of
future devices I would like to support. With all of this in mind, I
wanted to open a discussion on the best way to implement generic TPM
support. In Matthew's approach TPM is implemented under
grub-core/commands while TrustedGRUB2 is split between grub-core/kern
and grub-core/tpm. IMHO TPM functionality should be divided into HW
interfaces, TPM command processing, and higher order TPM operations. If
the logic was segmented in this manner, what are other's opinions on
where segments of logic should reside within the Grub2 source tree?
[1] http://lists.gnu.org/archive/html/grub-devel/2017-07/msg00005.html
[2] https://github.com/Rohde-Schwarz-Cybersecurity/TrustedGRUB2
In general I am not against reorganization you are mentioning above.
Though I think that then you should rearange Matthew code and repost
it. Of course if Matthew does not object.
Another thing is the verifiers framework. It would be nice if you could
hook your work there. Though you have to remember about other users like
UEFI secure boot (https://lists.xen.org/archives/html/xen-devel/2017-07/msg00985.html;
I am going to revive work on this patch) or GPG signatures. So, please
take a look at that code at git://git.savannah.gnu.org/grub.git,
phcoder/verifiers branch. If it works for you I will post the patches,
with minor fixes and improvements which are worth doing, for review (of
course if Vladimir does not object). If you discover any issues with the
verifiers framework just drop me a line and then we will try to fix them.
And another thing... Could not we reuse Philip TPM 2.0 work in GRUB2 somehow?
It's possible to use at least one of the APIs we've been developing in
Grub2 but I'm not sure the patches under review require this. It's been
a year now since I've reviewed these patches but AFAIK they don't
require any TPM2 functions beyond what the UEFI TrEE protocol exposes.

I have had a few people ask about combining Grub2s support for LUKS
volumes with the key usage policy from the TPM2 as a way to ensure the
integrity of the firmware before releasing a key used to decrypt the
LUKS volume. In this case using some of the APIs / libraries we've been
developing (https://github.com/tpm2-software/tpm2-tss) would make sense
since the TrEE protocol doesn't expose any of the interfaces we would
require: key creation & loading, policy sessions etc.

There would be a small amout of development work to implement an adapter
to sit between the tss2-sys library and the TrEE 'SubmitCommand'
function though. We have a standard API for this and have used it as the
basis for our support on Linux and Windows so I don't expect a UEFI
implementation to be much work if it becomes necessary. I do not however
believe this is required for the work under review.

Regards,
Philip
Javier Martinez Canillas
2018-07-18 16:27:15 UTC
Permalink
Post by Philip Tricca
Post by Daniel Kiper
Post by Daniel Kiper
Hi Daniel,
Post by Daniel P. Smith
Greetings,
I have a measured boot implementation I have been working on that
introduces a DRTM relocator that I would like to eventually upstream.
This work does rely on the ability to access a TPM 1.2 chip from within
Grub2. I am aware of Matthew Garrett's pending patch to add core TPM
support[1] but that is limited to UEFI environments. My target
environment uses Coreboot with the TCG BIOS payload to launch the
environment. For TPM support I am using code picked out of the
TrustedGRUB2 fork[2]. As a precursor to upstreaming my DRTM relocator, I
would like to see if I could find a way to generically introduce TPM
support into Grub2 that support's Matthew's UEFI backend, TrustedGrub2's
TPM 1.2 raw I/O, as well as leave a path for TPM2 raw I/O. In both
implementations TPM support is include as an x86 device when in fact
they can also be found in ARM devices, which is on my wish list of
future devices I would like to support. With all of this in mind, I
wanted to open a discussion on the best way to implement generic TPM
support. In Matthew's approach TPM is implemented under
grub-core/commands while TrustedGRUB2 is split between grub-core/kern
and grub-core/tpm. IMHO TPM functionality should be divided into HW
interfaces, TPM command processing, and higher order TPM operations. If
the logic was segmented in this manner, what are other's opinions on
where segments of logic should reside within the Grub2 source tree?
[1] http://lists.gnu.org/archive/html/grub-devel/2017-07/msg00005.html
[2] https://github.com/Rohde-Schwarz-Cybersecurity/TrustedGRUB2
In general I am not against reorganization you are mentioning above.
Though I think that then you should rearange Matthew code and repost
it. Of course if Matthew does not object.
Another thing is the verifiers framework. It would be nice if you could
hook your work there. Though you have to remember about other users like
UEFI secure boot (https://lists.xen.org/archives/html/xen-devel/2017-07/msg00985.html;
I am going to revive work on this patch) or GPG signatures. So, please
take a look at that code at git://git.savannah.gnu.org/grub.git,
phcoder/verifiers branch. If it works for you I will post the patches,
with minor fixes and improvements which are worth doing, for review (of
course if Vladimir does not object). If you discover any issues with the
verifiers framework just drop me a line and then we will try to fix them.
And another thing... Could not we reuse Philip TPM 2.0 work in GRUB2 somehow?
It's possible to use at least one of the APIs we've been developing in
Grub2 but I'm not sure the patches under review require this. It's been
a year now since I've reviewed these patches but AFAIK they don't
require any TPM2 functions beyond what the UEFI TrEE protocol exposes.
That's correct.
Post by Philip Tricca
I have had a few people ask about combining Grub2s support for LUKS
volumes with the key usage policy from the TPM2 as a way to ensure the
integrity of the firmware before releasing a key used to decrypt the
LUKS volume. In this case using some of the APIs / libraries we've been
developing (https://github.com/tpm2-software/tpm2-tss) would make sense
since the TrEE protocol doesn't expose any of the interfaces we would
require: key creation & loading, policy sessions etc.
There would be a small amout of development work to implement an adapter
to sit between the tss2-sys library and the TrEE 'SubmitCommand'
function though. We have a standard API for this and have used it as the
basis for our support on Linux and Windows so I don't expect a UEFI
implementation to be much work if it becomes necessary. I do not however
believe this is required for the work under review.
I wonder if we want something like the System API in GRUB2 or just a set of
TPM2 commands implemented using the EFI_TCG2_SUBMIT_COMMAND as you said. Is
what Microsoft is doing in its lsvmload [0] to implement its Shielded VM [1].

The lsvmload is an EFI binary that's executed before the boot-loader and it
is used just to unseal a key to unlock an encrypted partition where the real
boot-loader is stored.

[0]: https://github.com/Microsoft/lsvmtools/blob/master/lsvmutils/tpm2.c
[1]: https://events.static.linuxfound.org/sites/events/files/slides/LinuxCon%20Mike%20Brasher.pdf

Something like this can also be built on top of Matthew's current patch-set.
Post by Philip Tricca
Regards,
Philip
Best regards,
--
Javier Martinez Canillas
Software Engineer - Desktop Hardware Enablement
Red Hat
Daniel P. Smith
2018-07-18 20:39:09 UTC
Permalink
Post by Javier Martinez Canillas
Post by Philip Tricca
Post by Daniel Kiper
Post by Daniel Kiper
Hi Daniel,
Post by Daniel P. Smith
Greetings,
I have a measured boot implementation I have been working on that
introduces a DRTM relocator that I would like to eventually upstream.
This work does rely on the ability to access a TPM 1.2 chip from within
Grub2. I am aware of Matthew Garrett's pending patch to add core TPM
support[1] but that is limited to UEFI environments. My target
environment uses Coreboot with the TCG BIOS payload to launch the
environment. For TPM support I am using code picked out of the
TrustedGRUB2 fork[2]. As a precursor to upstreaming my DRTM relocator, I
would like to see if I could find a way to generically introduce TPM
support into Grub2 that support's Matthew's UEFI backend, TrustedGrub2's
TPM 1.2 raw I/O, as well as leave a path for TPM2 raw I/O. In both
implementations TPM support is include as an x86 device when in fact
they can also be found in ARM devices, which is on my wish list of
future devices I would like to support. With all of this in mind, I
wanted to open a discussion on the best way to implement generic TPM
support. In Matthew's approach TPM is implemented under
grub-core/commands while TrustedGRUB2 is split between grub-core/kern
and grub-core/tpm. IMHO TPM functionality should be divided into HW
interfaces, TPM command processing, and higher order TPM operations. If
the logic was segmented in this manner, what are other's opinions on
where segments of logic should reside within the Grub2 source tree?
[1] http://lists.gnu.org/archive/html/grub-devel/2017-07/msg00005.html
[2] https://github.com/Rohde-Schwarz-Cybersecurity/TrustedGRUB2
In general I am not against reorganization you are mentioning above.
Though I think that then you should rearange Matthew code and repost
it. Of course if Matthew does not object.
Another thing is the verifiers framework. It would be nice if you could
hook your work there. Though you have to remember about other users like
UEFI secure boot (https://lists.xen.org/archives/html/xen-devel/2017-07/msg00985.html;
I am going to revive work on this patch) or GPG signatures. So, please
take a look at that code at git://git.savannah.gnu.org/grub.git,
phcoder/verifiers branch. If it works for you I will post the patches,
with minor fixes and improvements which are worth doing, for review (of
course if Vladimir does not object). If you discover any issues with the
verifiers framework just drop me a line and then we will try to fix them.
And another thing... Could not we reuse Philip TPM 2.0 work in GRUB2 somehow?
It's possible to use at least one of the APIs we've been developing in
Grub2 but I'm not sure the patches under review require this. It's been
a year now since I've reviewed these patches but AFAIK they don't
require any TPM2 functions beyond what the UEFI TrEE protocol exposes.
That's correct.
Post by Philip Tricca
I have had a few people ask about combining Grub2s support for LUKS
volumes with the key usage policy from the TPM2 as a way to ensure the
integrity of the firmware before releasing a key used to decrypt the
LUKS volume. In this case using some of the APIs / libraries we've been
developing (https://github.com/tpm2-software/tpm2-tss) would make sense
since the TrEE protocol doesn't expose any of the interfaces we would
require: key creation & loading, policy sessions etc.
There would be a small amout of development work to implement an adapter
to sit between the tss2-sys library and the TrEE 'SubmitCommand'
function though. We have a standard API for this and have used it as the
basis for our support on Linux and Windows so I don't expect a UEFI
implementation to be much work if it becomes necessary. I do not however
believe this is required for the work under review.
I wonder if we want something like the System API in GRUB2 or just a set of
TPM2 commands implemented using the EFI_TCG2_SUBMIT_COMMAND as you said. Is
what Microsoft is doing in its lsvmload [0] to implement its Shielded VM [1].
For me the issue is that I am working in coreboot environments where
UEFI is not present. Second, until OEM's stop including the kitchen sink
in their UEFI builds, I hold UEFI suspect and would like to reduce the
chance that it can interfere with my interactions with the TPM. So when
I get to TPM2, I will likely be looking to just do the I/O operations
and marshaling directly. This is getting to what I was suggesting in the
initial email that layer the abstractions so efi kernel can use TrEE by
default and for either override or for non-efi have the i386 kernel
handle raw I/O. Then a tpm lib or command module can expose TPM
operations that things like LUKS or TrenchBoot can leverage.
Post by Javier Martinez Canillas
The lsvmload is an EFI binary that's executed before the boot-loader and it
is used just to unseal a key to unlock an encrypted partition where the real
boot-loader is stored.
[0]: https://github.com/Microsoft/lsvmtools/blob/master/lsvmutils/tpm2.c
[1]: https://events.static.linuxfound.org/sites/events/files/slides/LinuxCon%20Mike%20Brasher.pdf
Something like this can also be built on top of Matthew's current patch-set.
Post by Philip Tricca
Regards,
Philip
Best regards,
Philip Tricca
2018-07-19 14:55:19 UTC
Permalink
Post by Javier Martinez Canillas
Post by Philip Tricca
Post by Daniel Kiper
Post by Daniel Kiper
Hi Daniel,
Post by Daniel P. Smith
Greetings,
I have a measured boot implementation I have been working on that
introduces a DRTM relocator that I would like to eventually upstream.
This work does rely on the ability to access a TPM 1.2 chip from within
Grub2. I am aware of Matthew Garrett's pending patch to add core TPM
support[1] but that is limited to UEFI environments. My target
environment uses Coreboot with the TCG BIOS payload to launch the
environment. For TPM support I am using code picked out of the
TrustedGRUB2 fork[2]. As a precursor to upstreaming my DRTM relocator, I
would like to see if I could find a way to generically introduce TPM
support into Grub2 that support's Matthew's UEFI backend, TrustedGrub2's
TPM 1.2 raw I/O, as well as leave a path for TPM2 raw I/O. In both
implementations TPM support is include as an x86 device when in fact
they can also be found in ARM devices, which is on my wish list of
future devices I would like to support. With all of this in mind, I
wanted to open a discussion on the best way to implement generic TPM
support. In Matthew's approach TPM is implemented under
grub-core/commands while TrustedGRUB2 is split between grub-core/kern
and grub-core/tpm. IMHO TPM functionality should be divided into HW
interfaces, TPM command processing, and higher order TPM operations. If
the logic was segmented in this manner, what are other's opinions on
where segments of logic should reside within the Grub2 source tree?
[1] http://lists.gnu.org/archive/html/grub-devel/2017-07/msg00005.html
[2] https://github.com/Rohde-Schwarz-Cybersecurity/TrustedGRUB2
In general I am not against reorganization you are mentioning above.
Though I think that then you should rearange Matthew code and repost
it. Of course if Matthew does not object.
Another thing is the verifiers framework. It would be nice if you could
hook your work there. Though you have to remember about other users like
UEFI secure boot (https://lists.xen.org/archives/html/xen-devel/2017-07/msg00985.html;
I am going to revive work on this patch) or GPG signatures. So, please
take a look at that code at git://git.savannah.gnu.org/grub.git,
phcoder/verifiers branch. If it works for you I will post the patches,
with minor fixes and improvements which are worth doing, for review (of
course if Vladimir does not object). If you discover any issues with the
verifiers framework just drop me a line and then we will try to fix them.
And another thing... Could not we reuse Philip TPM 2.0 work in GRUB2 somehow?
It's possible to use at least one of the APIs we've been developing in
Grub2 but I'm not sure the patches under review require this. It's been
a year now since I've reviewed these patches but AFAIK they don't
require any TPM2 functions beyond what the UEFI TrEE protocol exposes.
That's correct.
Post by Philip Tricca
I have had a few people ask about combining Grub2s support for LUKS
volumes with the key usage policy from the TPM2 as a way to ensure the
integrity of the firmware before releasing a key used to decrypt the
LUKS volume. In this case using some of the APIs / libraries we've been
developing (https://github.com/tpm2-software/tpm2-tss) would make sense
since the TrEE protocol doesn't expose any of the interfaces we would
require: key creation & loading, policy sessions etc.
There would be a small amout of development work to implement an adapter
to sit between the tss2-sys library and the TrEE 'SubmitCommand'
function though. We have a standard API for this and have used it as the
basis for our support on Linux and Windows so I don't expect a UEFI
implementation to be much work if it becomes necessary. I do not however
believe this is required for the work under review.
I wonder if we want something like the System API in GRUB2 or just a set of
TPM2 commands implemented using the EFI_TCG2_SUBMIT_COMMAND as you said.
I've been threatening to implement this for a while now. The majority of
the work involved will be in the build and the implementation of a new
TCTI module that sits on top of the TrEE protocol driver. The system API
code (tss2-sys) would remain unchanged.
Post by Javier Martinez Canillas
Is
what Microsoft is doing in its lsvmload [0] to implement its Shielded VM [1].
Hadn't seen this. Thanks.

Philip
Post by Javier Martinez Canillas
The lsvmload is an EFI binary that's executed before the boot-loader and it
is used just to unseal a key to unlock an encrypted partition where the real
boot-loader is stored.
[0]: https://github.com/Microsoft/lsvmtools/blob/master/lsvmutils/tpm2.c
[1]: https://events.static.linuxfound.org/sites/events/files/slides/LinuxCon%20Mike%20Brasher.pdf
Something like this can also be built on top of Matthew's current patch-set.
Post by Philip Tricca
Regards,
Philip
Best regards,
--
Javier Martinez Canillas
Software Engineer - Desktop Hardware Enablement
Red Hat
Continue reading on narkive:
Loading...