Re: TPM support within Grub2
On 07/18/2018 12:27 PM, Javier Martinez Canillas wrote: > On 07/17/2018 06:57 PM, Philip Tricca wrote: >> On Mon, Jul 16, 2018 at 02:06:12PM +0200, Daniel Kiper wrote: >>> On Mon, Jul 02, 2018 at 06:35:08PM +0200, Daniel Kiper wrote: Hi Daniel, On Sun, Jul 01, 2018 at 07:09:30PM -0400, Daniel P. Smith wrote: > 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/msg5.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. > >> 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 abst
Re: TPM support within Grub2
On 07/18/2018 05:03 AM, Daniel Kiper wrote: > On Tue, Jul 17, 2018 at 07:10:32PM +0100, Matthew Garrett wrote: >> On Mon, Jul 16, 2018 at 12:33:42PM -0400, Daniel P. Smith wrote: >>> On 07/16/2018 08:06 AM, Daniel Kiper wrote: 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 > > OK, as I said earlier I will post it with some comments and minor > fixes in a week or two. > >> 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. > Daniel > ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: TPM support within Grub2
On 07/17/2018 01:22 PM, Philip Tricca wrote: > On Mon, Jul 16, 2018 at 12:33:42PM -0400, Daniel P. Smith wrote: >> On 07/16/2018 08:06 AM, Daniel Kiper wrote: >>> On Mon, Jul 02, 2018 at 06:35:08PM +0200, Daniel Kiper wrote: Hi Daniel, On Sun, Jul 01, 2018 at 07:09:30PM -0400, Daniel P. Smith wrote: > 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/msg5.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. >> >>> 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. >> >>> 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. > Philip > v/r, dps ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
[PATCH 4/9] btrfs: Avoid a rescan for a device which was already not found.
Resend because I forgot to put grub-devel in cc
-
On 07/12/2018 04:02 PM, Daniel Kiper wrote:
> On Tue, Jun 19, 2018 at 08:22:19PM +0200, Goffredo Baroncelli wrote:
>> Forward because this patch still doesn't reach the mailing list
>
> Could you fix that somehow? It is confusing.
I don't know which could be the problem. The only idea which I have, is that
the patch #4 is the only one which was never changed; gmail prevent two equal
emails to reach the inbox two times. I suspect that these two thing are related
>
>> --
>>
>> If a device is not found, record this failure by storing NULL in
>> data->devices_attached[]. This way we avoid unnecessary devices rescan,
>> and speedup the reads in case of a degraded array.
>>
>> Signed-off-by: Goffredo Baroncelli
>> ---
>> grub-core/fs/btrfs.c | 19 +--
>> 1 file changed, 9 insertions(+), 10 deletions(-)
>>
>> diff --git a/grub-core/fs/btrfs.c b/grub-core/fs/btrfs.c
>> index 8d07e2d72..70bcb0fdc 100644
>> --- a/grub-core/fs/btrfs.c
>> +++ b/grub-core/fs/btrfs.c
>> @@ -588,7 +588,7 @@ find_device_iter (const char *name, void *data)
>> }
>>
>> static grub_device_t
>> -find_device (struct grub_btrfs_data *data, grub_uint64_t id, int do_rescan)
>> +find_device (struct grub_btrfs_data *data, grub_uint64_t id)
>> {
>>struct find_device_ctx ctx = {
>> .data = data,
>> @@ -600,12 +600,9 @@ find_device (struct grub_btrfs_data *data,
>> grub_uint64_t id, int do_rescan)
>>for (i = 0; i < data->n_devices_attached; i++)
>> if (id == data->devices_attached[i].id)
>>return data->devices_attached[i].dev;
>> - if (do_rescan)
>> -grub_device_iterate (find_device_iter, &ctx);
>> - if (!ctx.dev_found)
>> -{
>> - return NULL;
>> -}
>> +
>> + grub_device_iterate (find_device_iter, &ctx);
>> +
[...]
>
> The commit message or code is wrong. NULL is never stored into
> data->devices_attached[]. Am I missing something?
The original code searches a device (using 'id' as key) in the array
data->devices_attached[]; if the device is found, the device info are
returned.
Otherwise find_device() searches the device using grub_device_iterate().
If ctx.dev_found is NULL, the device is not found and the function returns NULL.
Otherwise find_device() stores the pair "ctx.dev_found" and "id"
in data->devices_attached[] array for further searches.
Finally find_device() returns the value found.
My patch removes the check: if the device is not found, find_devices() stores
the pair "NULL" and "id". So data->devices_attached[] array acts as cache both
for the "founded" and "not founded" devices.
>
> Daniel
>
> ___
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel
>
--
gpg @keyserver.linux.it: Goffredo Baroncelli
Key fingerprint BBF5 1610 0B64 DAC6 5F7D 17B2 0EDA 9B37 8B82 E0B5
___
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
Re: TPM support within Grub2
On 07/17/2018 06:57 PM, Philip Tricca wrote: > On Mon, Jul 16, 2018 at 02:06:12PM +0200, Daniel Kiper wrote: >> On Mon, Jul 02, 2018 at 06:35:08PM +0200, Daniel Kiper wrote: >>> Hi Daniel, >>> >>> On Sun, Jul 01, 2018 at 07:09:30PM -0400, Daniel P. Smith wrote: 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/msg5.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. > 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. > Regards, > Philip > Best regards, -- Javier Martinez Canillas Software Engineer - Desktop Hardware Enablement Red Hat ___ Grub-d
Re: TPM support within Grub2
On 07/18/2018 11:03 AM, Daniel Kiper wrote: > On Tue, Jul 17, 2018 at 07:10:32PM +0100, Matthew Garrett wrote: >> On Mon, Jul 16, 2018 at 12:33:42PM -0400, Daniel P. Smith wrote: >>> On 07/16/2018 08:06 AM, Daniel Kiper wrote: 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 > > OK, as I said earlier I will post it with some comments and minor > fixes in a week or two. > >> 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. > Daniel Best regards, -- Javier Martinez Canillas Software Engineer - Desktop Hardware Enablement Red Hat ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
Re: TPM support within Grub2
On Tue, Jul 17, 2018 at 07:10:32PM +0100, Matthew Garrett wrote: > On Mon, Jul 16, 2018 at 12:33:42PM -0400, Daniel P. Smith wrote: > > On 07/16/2018 08:06 AM, Daniel Kiper wrote: > > > 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 OK, as I said earlier I will post it with some comments and minor fixes in a week or two. > 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 ___ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
