| Message ID | 20191211202728.127996-1-stefanb@linux.vnet.ibm.com |
|---|---|
| Headers | show |
| Series | Add vTPM support to SLOF | expand |
Hey, It's been a while since the last attempt :) 33 is a lot! Comments below... On 12/12/2019 07:26, Stefan Berger wrote: > I am reposting this series of patches for adding vTPM support > to SLOF. The series has grown over time due to addition of > vTPM 2.0 support. The vTPM (1.2 & 2) SLOF code leans on the code I Where these versions are from? PAPR (I did not look deep though) or something else? Do we have to/want to implement anything but v2.0? What other pieces need SLOF to support v1.2 - grub, linux, qemu, aix, freebsd? > upstreamed to SeaBIOS and where Kevin O'Connor (cc'ed) has also made > changes to and given me permission to contribute the combined code to > SLOF under the BSD license. One goal is to keep the two code bases in > sync as much as possible. > > I expect that PAPR vTPM support will become available in QEMU 5.0. 01/33 refers to tpm-next+spapr.v3 and there is a newer v6 and now you say it is qemu 5.0, which statement is correct? 01/33 refers to libtpms/swtpm - are these standard libraries/tools available from distros (my ubuntu 18.04 does not have libtpms). Does qemu v5.0 depend on these? Or these can be added as submodules? Do we need both libraries? It must be documented then somewhere so you do not have to document it in 01/33. A few command line examples (one for qemu and one for swtpm) in the cover letter should be enough. In general, it is too many small patches and later patches change what earlier patch in the series did, such as 26/33, 31/33, please avoid that - it might represent how you developed those but it is useless when bisecting. Either add commit logs into 29/33, 30/33, 31/33, 33/33, or (better) merge them in one patch. Also please organize the series as: 1. prerequisites (03/33, 28/33,...) 2. vtpm v1.2 driver (if we still need it) 3. vtpm v2.0 (avoid reorganising code from the previous step) 4. implement menu item btw do we really want the menu? Can this (whatever the menu does) be done by the QEMU command line, some properties of the new tpm-spapr device? Thanks, > > The following series of patches adds TPM support to SLOF. > In particular it adds the following: > > - TPM drivers for hardware interface and CRQ interface > - TPM initialization > - TPM logging area and firmware API to transfer it to the OS > (measurements are visible in sysfs) > - Some measurement code (Static Core Root Of Trust) > - TPM menu (accessible via 't' key during boot if TPM is available) > - Firmware API extensions following Power Firmware Doc > (to make trusted grub work) > - TPM 2.0 support (logs are written in little endian format for TPM 2.0) > > Having a vTPM attached to a VM provides the following benefits: > > - enablement of trusted boot; this allow us to eventually extend the chain > of trust from the hypervisor to the guests > - enablement of attestation so that one can verify what software is > running on a machine > - provides TPM functionality to VMs, which includes a standardized > mechanism to store keys and other blobs > (Linux trusted keys, GNU TLS's TPM extensions) > > Necessarily, some of its parts are written in Forth, many are written > in 'C'. The extensions are known to work with QEMU for ppc64 running Linux. > > v3->v4: > - Added TPM 2.0 support > > v2->v3: > - Addressed Thomas Huth's comments. > - Rearranged patches and merged some patches. > - Followed some of the changes made by K. O'Connor (SeaBIOS). > > v1->v2: > - Addressed Nikunj's comments > - Since last post in August I added 3 more patches to the end of the series > and one in 13th place. > > Stefan Berger (33): > tpm: Add a TPM driver implementation > tpm: Add TPM initialization support > tpm: Add sha1 implementation > tpm: Add initial support for logging > tpm: Extend firmware API > tpm: Return value of actual log in sml-get-handover-size > tpm: Add sml related nodes to vdevice/vtpm node > tpm: Implement measurements of the master boot record > tpm: Add support for controlling the states of the TPM > tpm: Add support for a TPM menu to control the state of the TPM > tpm: Measure the static core root of trust for measurements > tpm: Add TPM firmware API call get-maximum-cmd-size > tpm: Add TPM firmware API call pass-through-to-tpm > tpm: Add TPM firmware API call get-state > tpm: Add TPM firmware API call get-failure-reason > tpm: Add TPM firmware API call reformat-sml-to-efi-alignment > tpm: Set the driver in pseudo failure state after handover > tpm: Add function to for getting version of TPM > tpm: Implement log related 32 bit endian conversion functions > tpm2: prepare tpmhw_transmit for TPM2 commands > tpm2: support TPM2 in tpm_set_failure > tpm2: Implement tpm20_startup() > tpm2: implement 2nd part of tpm20_start() > tpm2: Rework the logging and implement tpm20_extend() > tpm2: refactor tpm_unassert_physical_presence for TPM2 > tpm2: Prefix functions with tpm12_ and adapt for TPM 2 case > tpm2: Implement tpm20_process_cfg, tpm20_clear, and tpm20_clearcontrol > slof: Implement SLOF_get_keystroke > tpm2: Implement TPM 2 menu with choice to clear the TPM 2 > tpm2: implement tpm20_prepboot > tpm2: Use a table to convert the hash to the buffer size it needs. > tpm2: Implement TPM 2.0 menu item to activate and deactivte PCR banks > tpm2: Include vio-vtpm-cdriver.fs if IBM,vtpm20 is specified > > board-qemu/Makefile | 2 +- > board-qemu/slof/Makefile | 13 +- > board-qemu/slof/OF.fs | 3 + > board-qemu/slof/tree.fs | 6 + > board-qemu/slof/vio-vtpm-cdriver.fs | 184 +++ > board-qemu/slof/vtpm-sml.fs | 387 ++++++ > include/helpers.h | 4 + > lib/Makefile | 2 +- > lib/libtpm/Makefile | 50 + > lib/libtpm/Readme | 95 ++ > lib/libtpm/sha1.c | 197 +++ > lib/libtpm/sha1.h | 20 + > lib/libtpm/tcgbios.c | 1932 +++++++++++++++++++++++++++ > lib/libtpm/tcgbios.h | 54 + > lib/libtpm/tcgbios_int.h | 404 ++++++ > lib/libtpm/tpm.code | 234 ++++ > lib/libtpm/tpm.in | 36 + > lib/libtpm/tpm_drivers.c | 501 +++++++ > lib/libtpm/tpm_drivers.h | 104 ++ > slof/fs/packages/disk-label.fs | 10 +- > slof/fs/start-up.fs | 16 + > slof/helpers.c | 17 + > 22 files changed, 4265 insertions(+), 6 deletions(-) > create mode 100644 board-qemu/slof/vio-vtpm-cdriver.fs > create mode 100644 board-qemu/slof/vtpm-sml.fs > create mode 100644 lib/libtpm/Makefile > create mode 100644 lib/libtpm/Readme > create mode 100644 lib/libtpm/sha1.c > create mode 100644 lib/libtpm/sha1.h > create mode 100644 lib/libtpm/tcgbios.c > create mode 100644 lib/libtpm/tcgbios.h > create mode 100644 lib/libtpm/tcgbios_int.h > create mode 100644 lib/libtpm/tpm.code > create mode 100644 lib/libtpm/tpm.in > create mode 100644 lib/libtpm/tpm_drivers.c > create mode 100644 lib/libtpm/tpm_drivers.h >
On 12/18/19 6:05 PM, Alexey Kardashevskiy wrote: > Hey, > > It's been a while since the last attempt :) 33 is a lot! Comments below... > > On 12/12/2019 07:26, Stefan Berger wrote: >> I am reposting this series of patches for adding vTPM support >> to SLOF. The series has grown over time due to addition of >> vTPM 2.0 support. The vTPM (1.2 & 2) SLOF code leans on the code I > Where these versions are from? PAPR (I did not look deep though) or something else? Do we have to/want to implement There's a firmware document for Power vTPM support. That's where some of the Power relevant parts are from, such as API support. Otherwise the code, as said, is very much leaning on the contributions I made to SeaBIOS and where Kevin also made changes to. > anything but v2.0? What other pieces need SLOF to support v1.2 - grub, linux, qemu, aix, freebsd? The issue, at least for me, is the stack of patches... > > >> upstreamed to SeaBIOS and where Kevin O'Connor (cc'ed) has also made >> changes to and given me permission to contribute the combined code to >> SLOF under the BSD license. One goal is to keep the two code bases in >> sync as much as possible. >> >> I expect that PAPR vTPM support will become available in QEMU 5.0. > 01/33 refers to tpm-next+spapr.v3 and there is a newer v6 and now you say it is qemu 5.0, which statement is correct? Over the last few days I worked on subsequent submission to qemu-devel. v3 works fine with this series. The intention is that vTPM support for pSeries will go into QEMU 5.0. > > 01/33 refers to libtpms/swtpm - are these standard libraries/tools available from distros (my ubuntu 18.04 does not have > libtpms). Does qemu v5.0 depend on these? Or these can be added as submodules? Do we need both libraries? It must be > documented then somewhere so you do not have to document it in 01/33. A few command line examples (one for qemu and one > for swtpm) in the cover letter should be enough. It's swtpm that needs libtpms. Swtpm is either started by libvirt or has to be started manually as described here (file will be converted to .rst): https://github.com/qemu/qemu/blob/master/docs/specs/tpm.txt It's been packaged for Fedora and will appear in RHAV. Not all distros may have it, yet. > In general, it is too many small patches and later patches change what earlier patch in the series did, such as 26/33, > 31/33, please avoid that - it might represent how you developed those but it is useless when bisecting. > Either add commit logs into 29/33, 30/33, 31/33, 33/33, or (better) merge them in one patch. Sure, I can do that. > > Also please organize the series as: > 1. prerequisites (03/33, 28/33,...) > 2. vtpm v1.2 driver (if we still need it) > 3. vtpm v2.0 (avoid reorganising code from the previous step) > 4. implement menu item Ok, I will move the prerequisites to the top but would then like to build TPM 2 on top of TPM 1.2 support, meaning all TPM 1.2 patches come first, then we add TPM 2. > > btw do we really want the menu? Can this (whatever the menu does) be done by the QEMU command line, some properties of > the new tpm-spapr device? Thanks, There are aspects of TPM state that can only be controlled via a firmware menu after initialization of the TPM and before the firmware passes control to the OS loader. That's why physical machines have TPM menus in the firmware. Stefan
On 19/12/2019 11:27, Stefan Berger wrote: > On 12/18/19 6:05 PM, Alexey Kardashevskiy wrote: >> Hey, >> >> It's been a while since the last attempt :) 33 is a lot! Comments below... >> >> On 12/12/2019 07:26, Stefan Berger wrote: >>> I am reposting this series of patches for adding vTPM support >>> to SLOF. The series has grown over time due to addition of >>> vTPM 2.0 support. The vTPM (1.2 & 2) SLOF code leans on the code I >> Where these versions are from? PAPR (I did not look deep though) or something else? Do we have to/want to implement > > There's a firmware document for Power vTPM support. What is the name? Is it publicly available? All these questions need to be answered in commit logs or some documentation. > That's where some of the Power relevant parts are from, such as API > support. Otherwise the code, as said, is very much leaning on the contributions I made to SeaBIOS and where Kevin also > made changes to. > > >> anything but v2.0? What other pieces need SLOF to support v1.2 - grub, linux, qemu, aix, freebsd? > > > The issue, at least for me, is the stack of patches... Ditch the ones starting with "tpm:" and see what breaks? :) I really do not understand the problem - why do we need both versions if only v2 is ever going to be used. Or not. > > >> >> >>> upstreamed to SeaBIOS and where Kevin O'Connor (cc'ed) has also made >>> changes to and given me permission to contribute the combined code to >>> SLOF under the BSD license. One goal is to keep the two code bases in >>> sync as much as possible. >>> >>> I expect that PAPR vTPM support will become available in QEMU 5.0. >> 01/33 refers to tpm-next+spapr.v3 and there is a newer v6 and now you say it is qemu 5.0, which statement is correct? > > Over the last few days I worked on subsequent submission to qemu-devel. v3 works fine with this series. The intention is > that vTPM support for pSeries will go into QEMU 5.0. Then remove that part in the doc about building qemu and other lib, it only confuses. > >> >> 01/33 refers to libtpms/swtpm - are these standard libraries/tools available from distros (my ubuntu 18.04 does not have >> libtpms). Does qemu v5.0 depend on these? Or these can be added as submodules? Do we need both libraries? It must be >> documented then somewhere so you do not have to document it in 01/33. A few command line examples (one for qemu and one >> for swtpm) in the cover letter should be enough. > > It's swtpm that needs libtpms. Swtpm is either started by libvirt or has to be started manually as described here (file > will be converted to .rst): > > https://github.com/qemu/qemu/blob/master/docs/specs/tpm.txt > > It's been packaged for Fedora and will appear in RHAV. Not all distros may have it, yet. Ah ok. > > >> In general, it is too many small patches and later patches change what earlier patch in the series did, such as 26/33, >> 31/33, please avoid that - it might represent how you developed those but it is useless when bisecting. >> Either add commit logs into 29/33, 30/33, 31/33, 33/33, or (better) merge them in one patch. > > > Sure, I can do that. > > >> >> Also please organize the series as: >> 1. prerequisites (03/33, 28/33,...) >> 2. vtpm v1.2 driver (if we still need it) >> 3. vtpm v2.0 (avoid reorganising code from the previous step) >> 4. implement menu item > > Ok, I will move the prerequisites to the top but would then like to build TPM 2 on top of TPM 1.2 support, meaning all > TPM 1.2 patches come first, then we add TPM 2. > > >> >> btw do we really want the menu? Can this (whatever the menu does) be done by the QEMU command line, some properties of >> the new tpm-spapr device? Thanks, > > > There are aspects of TPM state that can only be controlled via a firmware menu after initialization of the TPM and > before the firmware passes control to the OS loader. That's why physical machines have TPM menus in the firmware. QEMU can put a property in the device tree, SLOF can read it and switch banks. Why does this have to be a SLOF menu rather than an xml option in libvirt? Physical machines do not have hypervisors but our VMs do. btw you posted patches from @linux.vnet.ibm.com domain but replying from @linux.ibm.com, this confuses the maillist's mailman. Just sayin' :) Thanks,
On 12/18/19 6:05 PM, Alexey Kardashevskiy wrote: > Hey, > > It's been a while since the last attempt :) 33 is a lot! Comments below... I have a series of patches now here with some of the concerns addressed. I would say it's bisectable but my concern is that reshuffling more code will cause issues that aren't there right now. So I would appreciate some tolerance for refactoring while building up TPM 2 support. https://github.com/stefanberger/SLOF-tpm/commits/SLOF-tpm.Dec2019.23 Stefan
On 24/12/2019 08:40, Stefan Berger wrote: > On 12/18/19 6:05 PM, Alexey Kardashevskiy wrote: >> Hey, >> >> It's been a while since the last attempt :) 33 is a lot! Comments >> below... > > I have a series of patches now here with some of the concerns addressed. > I would say it's bisectable but my concern is that reshuffling more code > will cause issues that aren't there right now. So I would appreciate > some tolerance for refactoring while building up TPM 2 support. > > > https://github.com/stefanberger/SLOF-tpm/commits/SLOF-tpm.Dec2019.23 imho you are overthinking this. This needs to be several prerequisite patches (one per lib/directory/driver/whatever), one patch for vtpm v1 (and I still eagerly want to hear why we want v1 at all), one patch for vtpm v2, one patch for the menu. "One patch" could be more if patch 1 adds some function on its own and consequent patches enhance patch 1 (such as add vtpm with 1 algo enabled in patch 1 and then add other hashing algorithms later) but I do not see this happening or very useful. Thanks,
On 12/23/19 6:41 PM, Alexey Kardashevskiy wrote: > > On 24/12/2019 08:40, Stefan Berger wrote: >> On 12/18/19 6:05 PM, Alexey Kardashevskiy wrote: >>> Hey, >>> >>> It's been a while since the last attempt :) 33 is a lot! Comments >>> below... >> I have a series of patches now here with some of the concerns addressed. >> I would say it's bisectable but my concern is that reshuffling more code >> will cause issues that aren't there right now. So I would appreciate >> some tolerance for refactoring while building up TPM 2 support. >> >> >> https://github.com/stefanberger/SLOF-tpm/commits/SLOF-tpm.Dec2019.23 > imho you are overthinking this. This needs to be several prerequisite > patches (one per lib/directory/driver/whatever), one patch for vtpm v1 What are prerequisites? Are these functions needed by lib/libtpm but are located in other directories? I have certainly not put the patches in random order, so they do compile at every step and functions needed in one step are introduced before it. > (and I still eagerly want to hear why we want v1 at all), one patch for The application stack for TSS 1.2 is (still) being packaged for ppc64le: https://packages.ubuntu.com/eoan/trousers https://koji.fedoraproject.org/koji/packageinfo?packageID=5471 https://software.opensuse.org/package/trousers https://packages.debian.org/search?keywords=trousers > vtpm v2, one patch for the menu. "One patch" could be more if patch 1 > adds some function on its own and consequent patches enhance patch 1 > (such as add vtpm with 1 algo enabled in patch 1 and then add other > hashing algorithms later) but I do not see this happening or very > useful. Thanks, I tried to make it small patches for easier digestion... > >
On 28/12/2019 08:13, Stefan Berger wrote: > On 12/23/19 6:41 PM, Alexey Kardashevskiy wrote: >> >> On 24/12/2019 08:40, Stefan Berger wrote: >>> On 12/18/19 6:05 PM, Alexey Kardashevskiy wrote: >>>> Hey, >>>> >>>> It's been a while since the last attempt :) 33 is a lot! Comments >>>> below... >>> I have a series of patches now here with some of the concerns addressed. >>> I would say it's bisectable but my concern is that reshuffling more code >>> will cause issues that aren't there right now. So I would appreciate >>> some tolerance for refactoring while building up TPM 2 support. >>> >>> >>> https://github.com/stefanberger/SLOF-tpm/commits/SLOF-tpm.Dec2019.23 >> imho you are overthinking this. This needs to be several prerequisite >> patches (one per lib/directory/driver/whatever), one patch for vtpm v1 > > What are prerequisites? Are these functions needed by lib/libtpm but are located in other directories? Yes. > I have certainly > not put the patches in random order, so they do compile at every step and functions needed in one step are introduced > before it. Good. >> (and I still eagerly want to hear why we want v1 at all), one patch for > > The application stack for TSS 1.2 is (still) being packaged for ppc64le: Ok. But what about v2.0? "trousers" does not support it? > > https://packages.ubuntu.com/eoan/trousers > > https://koji.fedoraproject.org/koji/packageinfo?packageID=5471 > > https://software.opensuse.org/package/trousers > > https://packages.debian.org/search?keywords=trousers > > > > >> vtpm v2, one patch for the menu. "One patch" could be more if patch 1 >> adds some function on its own and consequent patches enhance patch 1 >> (such as add vtpm with 1 algo enabled in patch 1 and then add other >> hashing algorithms later) but I do not see this happening or very >> useful. Thanks, > > I tried to make it small patches for easier digestion... Not seeing how helpers are actually used does not help much and bisectability suffers as well. Thanks,
On 12/27/19 11:11 PM, Alexey Kardashevskiy wrote: > > > On 28/12/2019 08:13, Stefan Berger wrote: >> On 12/23/19 6:41 PM, Alexey Kardashevskiy wrote: >>> >>> On 24/12/2019 08:40, Stefan Berger wrote: >>>> On 12/18/19 6:05 PM, Alexey Kardashevskiy wrote: >>>>> Hey, >>>>> >>>>> It's been a while since the last attempt :) 33 is a lot! Comments >>>>> below... >>>> I have a series of patches now here with some of the concerns >>>> addressed. >>>> I would say it's bisectable but my concern is that reshuffling more >>>> code >>>> will cause issues that aren't there right now. So I would appreciate >>>> some tolerance for refactoring while building up TPM 2 support. >>>> >>>> >>>> https://github.com/stefanberger/SLOF-tpm/commits/SLOF-tpm.Dec2019.23 >>> imho you are overthinking this. This needs to be several prerequisite >>> patches (one per lib/directory/driver/whatever), one patch for vtpm v1 >> >> What are prerequisites? Are these functions needed by lib/libtpm but >> are located in other directories? > > Yes. > >> I have certainly not put the patches in random order, so they do >> compile at every step and functions needed in one step are introduced >> before it. > > Good. > >>> (and I still eagerly want to hear why we want v1 at all), one patch for >> >> The application stack for TSS 1.2 is (still) being packaged for ppc64le: > > > Ok. But what about v2.0? "trousers" does not support it? There is different stack for TPM 2.0, actually there are two: - tss2 (IBM): https://koji.fedoraproject.org/koji/packageinfo?packageID=23163 - tpm2-tss (Intel): https://koji.fedoraproject.org/koji/buildinfo?buildID=1422031 > > >> >> https://packages.ubuntu.com/eoan/trousers >> >> https://koji.fedoraproject.org/koji/packageinfo?packageID=5471 >> >> https://software.opensuse.org/package/trousers >> >> https://packages.debian.org/search?keywords=trousers >> >> >> >> >>> vtpm v2, one patch for the menu. "One patch" could be more if patch 1 >>> adds some function on its own and consequent patches enhance patch 1 >>> (such as add vtpm with 1 algo enabled in patch 1 and then add other >>> hashing algorithms later) but I do not see this happening or very >>> useful. Thanks, >> >> I tried to make it small patches for easier digestion... > > > Not seeing how helpers are actually used does not help much and > bisectability suffers as well. Thanks, So then changing it to a series of patches that add prerequisites, then the low lever PAPR driver, then the SHA1 implementation, and then TPM 1.2 support followed by TPM 2.0 support, and then the combined menu for TPM 1.2 and TPM 2.0 will improve it for the review? The prerequisites are like two-liners for invoking FORTH functions from C. > > >
On 03/01/2020 01:20, Stefan Berger wrote: > On 12/27/19 11:11 PM, Alexey Kardashevskiy wrote: >> >> >> On 28/12/2019 08:13, Stefan Berger wrote: >>> On 12/23/19 6:41 PM, Alexey Kardashevskiy wrote: >>>> >>>> On 24/12/2019 08:40, Stefan Berger wrote: >>>>> On 12/18/19 6:05 PM, Alexey Kardashevskiy wrote: >>>>>> Hey, >>>>>> >>>>>> It's been a while since the last attempt :) 33 is a lot! Comments >>>>>> below... >>>>> I have a series of patches now here with some of the concerns >>>>> addressed. >>>>> I would say it's bisectable but my concern is that reshuffling more >>>>> code >>>>> will cause issues that aren't there right now. So I would appreciate >>>>> some tolerance for refactoring while building up TPM 2 support. >>>>> >>>>> >>>>> https://github.com/stefanberger/SLOF-tpm/commits/SLOF-tpm.Dec2019.23 >>>> imho you are overthinking this. This needs to be several prerequisite >>>> patches (one per lib/directory/driver/whatever), one patch for vtpm v1 >>> >>> What are prerequisites? Are these functions needed by lib/libtpm but >>> are located in other directories? >> >> Yes. >> >>> I have certainly not put the patches in random order, so they do >>> compile at every step and functions needed in one step are introduced >>> before it. >> >> Good. >> >>>> (and I still eagerly want to hear why we want v1 at all), one patch for >>> >>> The application stack for TSS 1.2 is (still) being packaged for ppc64le: >> >> >> Ok. But what about v2.0? "trousers" does not support it? > > > There is different stack for TPM 2.0, actually there are two: > > - tss2 (IBM): > https://koji.fedoraproject.org/koji/packageinfo?packageID=23163 > > - tpm2-tss (Intel): > https://koji.fedoraproject.org/koji/buildinfo?buildID=1422031 You are really not helping :) What if we decide to only support "tss2 (IBM)"? Would we still need v1.2? >>> https://packages.ubuntu.com/eoan/trousers >>> >>> https://koji.fedoraproject.org/koji/packageinfo?packageID=5471 >>> >>> https://software.opensuse.org/package/trousers >>> >>> https://packages.debian.org/search?keywords=trousers >>> >>> >>> >>> >>>> vtpm v2, one patch for the menu. "One patch" could be more if patch 1 >>>> adds some function on its own and consequent patches enhance patch 1 >>>> (such as add vtpm with 1 algo enabled in patch 1 and then add other >>>> hashing algorithms later) but I do not see this happening or very >>>> useful. Thanks, >>> >>> I tried to make it small patches for easier digestion... >> >> >> Not seeing how helpers are actually used does not help much and >> bisectability suffers as well. Thanks, > > > So then changing it to a series of patches that add prerequisites, then > the low lever PAPR driver, then the SHA1 implementation, and then TPM > 1.2 support followed by TPM 2.0 support, and then the combined menu for > TPM 1.2 and TPM 2.0 will improve it for the review? The prerequisites > are like two-liners for invoking FORTH functions from C. Kind of. But lets first clarify about v1.2/v2.0/ibm/intel/whatever. Thanks,
On 1/2/20 6:21 PM, Alexey Kardashevskiy wrote: > > On 03/01/2020 01:20, Stefan Berger wrote: >> On 12/27/19 11:11 PM, Alexey Kardashevskiy wrote: >>> >>> On 28/12/2019 08:13, Stefan Berger wrote: >>>> On 12/23/19 6:41 PM, Alexey Kardashevskiy wrote: >>>>> On 24/12/2019 08:40, Stefan Berger wrote: >>>>>> On 12/18/19 6:05 PM, Alexey Kardashevskiy wrote: >>>>>>> Hey, >>>>>>> >>>>>>> It's been a while since the last attempt :) 33 is a lot! Comments >>>>>>> below... >>>>>> I have a series of patches now here with some of the concerns >>>>>> addressed. >>>>>> I would say it's bisectable but my concern is that reshuffling more >>>>>> code >>>>>> will cause issues that aren't there right now. So I would appreciate >>>>>> some tolerance for refactoring while building up TPM 2 support. >>>>>> >>>>>> >>>>>> https://github.com/stefanberger/SLOF-tpm/commits/SLOF-tpm.Dec2019.23 >>>>> imho you are overthinking this. This needs to be several prerequisite >>>>> patches (one per lib/directory/driver/whatever), one patch for vtpm v1 >>>> What are prerequisites? Are these functions needed by lib/libtpm but >>>> are located in other directories? >>> Yes. >>> >>>> I have certainly not put the patches in random order, so they do >>>> compile at every step and functions needed in one step are introduced >>>> before it. >>> Good. >>> >>>>> (and I still eagerly want to hear why we want v1 at all), one patch for >>>> The application stack for TSS 1.2 is (still) being packaged for ppc64le: >>> >>> Ok. But what about v2.0? "trousers" does not support it? >> >> There is different stack for TPM 2.0, actually there are two: >> >> - tss2 (IBM): >> https://koji.fedoraproject.org/koji/packageinfo?packageID=23163 >> >> - tpm2-tss (Intel): >> https://koji.fedoraproject.org/koji/buildinfo?buildID=1422031 > > You are really not helping :) > > What if we decide to only support "tss2 (IBM)"? Would we still need v1.2? Recent Tss2 project also has TPM 1.2 support now, but it can be compiled out. So, it depends on what you want to have on this level as well. https://sourceforge.net/p/ibmtpm20tss/tss/ci/master/tree/ See utils12 directory. If you reject TPM 1.2 altogether there's of course no point in supporting it for anyone.
On 1/3/20 11:11 AM, Stefan Berger wrote: > On 1/2/20 6:21 PM, Alexey Kardashevskiy wrote: >> >> On 03/01/2020 01:20, Stefan Berger wrote: >>> On 12/27/19 11:11 PM, Alexey Kardashevskiy wrote: >>>> >>>> On 28/12/2019 08:13, Stefan Berger wrote: >>>>> On 12/23/19 6:41 PM, Alexey Kardashevskiy wrote: >>>>>> On 24/12/2019 08:40, Stefan Berger wrote: >>>>>>> On 12/18/19 6:05 PM, Alexey Kardashevskiy wrote: >>>>>>>> Hey, >>>>>>>> >>>>>>>> It's been a while since the last attempt :) 33 is a lot! Comments >>>>>>>> below... >>>>>>> I have a series of patches now here with some of the concerns >>>>>>> addressed. >>>>>>> I would say it's bisectable but my concern is that reshuffling more >>>>>>> code >>>>>>> will cause issues that aren't there right now. So I would >>>>>>> appreciate >>>>>>> some tolerance for refactoring while building up TPM 2 support. >>>>>>> >>>>>>> >>>>>>> https://github.com/stefanberger/SLOF-tpm/commits/SLOF-tpm.Dec2019.23 >>>>>>> >>>>>> imho you are overthinking this. This needs to be several >>>>>> prerequisite >>>>>> patches (one per lib/directory/driver/whatever), one patch for >>>>>> vtpm v1 >>>>> What are prerequisites? Are these functions needed by lib/libtpm but >>>>> are located in other directories? >>>> Yes. >>>> >>>>> I have certainly not put the patches in random order, so they do >>>>> compile at every step and functions needed in one step are introduced >>>>> before it. >>>> Good. >>>> >>>>>> (and I still eagerly want to hear why we want v1 at all), one >>>>>> patch for >>>>> The application stack for TSS 1.2 is (still) being packaged for >>>>> ppc64le: >>>> >>>> Ok. But what about v2.0? "trousers" does not support it? >>> >>> There is different stack for TPM 2.0, actually there are two: >>> >>> - tss2 (IBM): >>> https://koji.fedoraproject.org/koji/packageinfo?packageID=23163 >>> >>> - tpm2-tss (Intel): >>> https://koji.fedoraproject.org/koji/buildinfo?buildID=1422031 >> >> You are really not helping :) >> >> What if we decide to only support "tss2 (IBM)"? Would we still need >> v1.2? > > > Recent Tss2 project also has TPM 1.2 support now, but it can be > compiled out. So, it depends on what you want to have on this level as > well. > > https://sourceforge.net/p/ibmtpm20tss/tss/ci/master/tree/ > > See utils12 directory. If you reject TPM 1.2 altogether there's of > course no point in supporting it for anyone. > > Thoughts?
On 10/01/2020 11:48, Stefan Berger wrote: > On 1/3/20 11:11 AM, Stefan Berger wrote: >> On 1/2/20 6:21 PM, Alexey Kardashevskiy wrote: >>> >>> On 03/01/2020 01:20, Stefan Berger wrote: >>>> On 12/27/19 11:11 PM, Alexey Kardashevskiy wrote: >>>>> >>>>> On 28/12/2019 08:13, Stefan Berger wrote: >>>>>> On 12/23/19 6:41 PM, Alexey Kardashevskiy wrote: >>>>>>> On 24/12/2019 08:40, Stefan Berger wrote: >>>>>>>> On 12/18/19 6:05 PM, Alexey Kardashevskiy wrote: >>>>>>>>> Hey, >>>>>>>>> >>>>>>>>> It's been a while since the last attempt :) 33 is a lot! Comments >>>>>>>>> below... >>>>>>>> I have a series of patches now here with some of the concerns >>>>>>>> addressed. >>>>>>>> I would say it's bisectable but my concern is that reshuffling more >>>>>>>> code >>>>>>>> will cause issues that aren't there right now. So I would >>>>>>>> appreciate >>>>>>>> some tolerance for refactoring while building up TPM 2 support. >>>>>>>> >>>>>>>> >>>>>>>> https://github.com/stefanberger/SLOF-tpm/commits/SLOF-tpm.Dec2019.23 >>>>>>>> >>>>>>> imho you are overthinking this. This needs to be several >>>>>>> prerequisite >>>>>>> patches (one per lib/directory/driver/whatever), one patch for >>>>>>> vtpm v1 >>>>>> What are prerequisites? Are these functions needed by lib/libtpm but >>>>>> are located in other directories? >>>>> Yes. >>>>> >>>>>> I have certainly not put the patches in random order, so they do >>>>>> compile at every step and functions needed in one step are introduced >>>>>> before it. >>>>> Good. >>>>> >>>>>>> (and I still eagerly want to hear why we want v1 at all), one >>>>>>> patch for >>>>>> The application stack for TSS 1.2 is (still) being packaged for >>>>>> ppc64le: >>>>> >>>>> Ok. But what about v2.0? "trousers" does not support it? >>>> >>>> There is different stack for TPM 2.0, actually there are two: >>>> >>>> - tss2 (IBM): >>>> https://koji.fedoraproject.org/koji/packageinfo?packageID=23163 >>>> >>>> - tpm2-tss (Intel): >>>> https://koji.fedoraproject.org/koji/buildinfo?buildID=1422031 >>> >>> You are really not helping :) >>> >>> What if we decide to only support "tss2 (IBM)"? Would we still need >>> v1.2? >> >> >> Recent Tss2 project also has TPM 1.2 support now, but it can be >> compiled out. So, it depends on what you want to have on this level as >> well. >> >> https://sourceforge.net/p/ibmtpm20tss/tss/ci/master/tree/ >> >> See utils12 directory. If you reject TPM 1.2 altogether there's of >> course no point in supporting it for anyone. >> >> > Thoughts? None really. I still do not understand what we will miss if we drop everything but TPM v2.0. Like, what actual distro does not have v2.0 today and we want to support, or there is something better in v1.2 which is missing in v2.0, practical stuff like this. Thanks,
On 1/9/20 11:08 PM, Alexey Kardashevskiy wrote: > > On 10/01/2020 11:48, Stefan Berger wrote: >> On 1/3/20 11:11 AM, Stefan Berger wrote: >>> On 1/2/20 6:21 PM, Alexey Kardashevskiy wrote: >>>> On 03/01/2020 01:20, Stefan Berger wrote: >>>>> On 12/27/19 11:11 PM, Alexey Kardashevskiy wrote: >>>>>> On 28/12/2019 08:13, Stefan Berger wrote: >>>>>>> On 12/23/19 6:41 PM, Alexey Kardashevskiy wrote: >>>>>>>> On 24/12/2019 08:40, Stefan Berger wrote: >>>>>>>>> On 12/18/19 6:05 PM, Alexey Kardashevskiy wrote: >>>>>>>>>> Hey, >>>>>>>>>> >>>>>>>>>> It's been a while since the last attempt :) 33 is a lot! Comments >>>>>>>>>> below... >>>>>>>>> I have a series of patches now here with some of the concerns >>>>>>>>> addressed. >>>>>>>>> I would say it's bisectable but my concern is that reshuffling more >>>>>>>>> code >>>>>>>>> will cause issues that aren't there right now. So I would >>>>>>>>> appreciate >>>>>>>>> some tolerance for refactoring while building up TPM 2 support. >>>>>>>>> >>>>>>>>> >>>>>>>>> https://github.com/stefanberger/SLOF-tpm/commits/SLOF-tpm.Dec2019.23 >>>>>>>>> >>>>>>>> imho you are overthinking this. This needs to be several >>>>>>>> prerequisite >>>>>>>> patches (one per lib/directory/driver/whatever), one patch for >>>>>>>> vtpm v1 >>>>>>> What are prerequisites? Are these functions needed by lib/libtpm but >>>>>>> are located in other directories? >>>>>> Yes. >>>>>> >>>>>>> I have certainly not put the patches in random order, so they do >>>>>>> compile at every step and functions needed in one step are introduced >>>>>>> before it. >>>>>> Good. >>>>>> >>>>>>>> (and I still eagerly want to hear why we want v1 at all), one >>>>>>>> patch for >>>>>>> The application stack for TSS 1.2 is (still) being packaged for >>>>>>> ppc64le: >>>>>> Ok. But what about v2.0? "trousers" does not support it? >>>>> There is different stack for TPM 2.0, actually there are two: >>>>> >>>>> - tss2 (IBM): >>>>> https://koji.fedoraproject.org/koji/packageinfo?packageID=23163 >>>>> >>>>> - tpm2-tss (Intel): >>>>> https://koji.fedoraproject.org/koji/buildinfo?buildID=1422031 >>>> You are really not helping :) >>>> >>>> What if we decide to only support "tss2 (IBM)"? Would we still need >>>> v1.2? >>> >>> Recent Tss2 project also has TPM 1.2 support now, but it can be >>> compiled out. So, it depends on what you want to have on this level as >>> well. >>> >>> https://sourceforge.net/p/ibmtpm20tss/tss/ci/master/tree/ >>> >>> See utils12 directory. If you reject TPM 1.2 altogether there's of >>> course no point in supporting it for anyone. >>> >>> >> Thoughts? > None really. I still do not understand what we will miss if we drop > everything but TPM v2.0. Like, what actual distro does not have v2.0 > today and we want to support, or there is something better in v1.2 which > is missing in v2.0, practical stuff like this. Thanks, There's nothing better in v1.2 than V2.0 except you may have apps or libraries using v1.2, that's about it. Stefan
I am reposting this series of patches for adding vTPM support to SLOF. The series has grown over time due to addition of vTPM 2.0 support. The vTPM (1.2 & 2) SLOF code leans on the code I upstreamed to SeaBIOS and where Kevin O'Connor (cc'ed) has also made changes to and given me permission to contribute the combined code to SLOF under the BSD license. One goal is to keep the two code bases in sync as much as possible. I expect that PAPR vTPM support will become available in QEMU 5.0. The following series of patches adds TPM support to SLOF. In particular it adds the following: - TPM drivers for hardware interface and CRQ interface - TPM initialization - TPM logging area and firmware API to transfer it to the OS (measurements are visible in sysfs) - Some measurement code (Static Core Root Of Trust) - TPM menu (accessible via 't' key during boot if TPM is available) - Firmware API extensions following Power Firmware Doc (to make trusted grub work) - TPM 2.0 support (logs are written in little endian format for TPM 2.0) Having a vTPM attached to a VM provides the following benefits: - enablement of trusted boot; this allow us to eventually extend the chain of trust from the hypervisor to the guests - enablement of attestation so that one can verify what software is running on a machine - provides TPM functionality to VMs, which includes a standardized mechanism to store keys and other blobs (Linux trusted keys, GNU TLS's TPM extensions) Necessarily, some of its parts are written in Forth, many are written in 'C'. The extensions are known to work with QEMU for ppc64 running Linux. v3->v4: - Added TPM 2.0 support v2->v3: - Addressed Thomas Huth's comments. - Rearranged patches and merged some patches. - Followed some of the changes made by K. O'Connor (SeaBIOS). v1->v2: - Addressed Nikunj's comments - Since last post in August I added 3 more patches to the end of the series and one in 13th place. Stefan Berger (33): tpm: Add a TPM driver implementation tpm: Add TPM initialization support tpm: Add sha1 implementation tpm: Add initial support for logging tpm: Extend firmware API tpm: Return value of actual log in sml-get-handover-size tpm: Add sml related nodes to vdevice/vtpm node tpm: Implement measurements of the master boot record tpm: Add support for controlling the states of the TPM tpm: Add support for a TPM menu to control the state of the TPM tpm: Measure the static core root of trust for measurements tpm: Add TPM firmware API call get-maximum-cmd-size tpm: Add TPM firmware API call pass-through-to-tpm tpm: Add TPM firmware API call get-state tpm: Add TPM firmware API call get-failure-reason tpm: Add TPM firmware API call reformat-sml-to-efi-alignment tpm: Set the driver in pseudo failure state after handover tpm: Add function to for getting version of TPM tpm: Implement log related 32 bit endian conversion functions tpm2: prepare tpmhw_transmit for TPM2 commands tpm2: support TPM2 in tpm_set_failure tpm2: Implement tpm20_startup() tpm2: implement 2nd part of tpm20_start() tpm2: Rework the logging and implement tpm20_extend() tpm2: refactor tpm_unassert_physical_presence for TPM2 tpm2: Prefix functions with tpm12_ and adapt for TPM 2 case tpm2: Implement tpm20_process_cfg, tpm20_clear, and tpm20_clearcontrol slof: Implement SLOF_get_keystroke tpm2: Implement TPM 2 menu with choice to clear the TPM 2 tpm2: implement tpm20_prepboot tpm2: Use a table to convert the hash to the buffer size it needs. tpm2: Implement TPM 2.0 menu item to activate and deactivte PCR banks tpm2: Include vio-vtpm-cdriver.fs if IBM,vtpm20 is specified board-qemu/Makefile | 2 +- board-qemu/slof/Makefile | 13 +- board-qemu/slof/OF.fs | 3 + board-qemu/slof/tree.fs | 6 + board-qemu/slof/vio-vtpm-cdriver.fs | 184 +++ board-qemu/slof/vtpm-sml.fs | 387 ++++++ include/helpers.h | 4 + lib/Makefile | 2 +- lib/libtpm/Makefile | 50 + lib/libtpm/Readme | 95 ++ lib/libtpm/sha1.c | 197 +++ lib/libtpm/sha1.h | 20 + lib/libtpm/tcgbios.c | 1932 +++++++++++++++++++++++++++ lib/libtpm/tcgbios.h | 54 + lib/libtpm/tcgbios_int.h | 404 ++++++ lib/libtpm/tpm.code | 234 ++++ lib/libtpm/tpm.in | 36 + lib/libtpm/tpm_drivers.c | 501 +++++++ lib/libtpm/tpm_drivers.h | 104 ++ slof/fs/packages/disk-label.fs | 10 +- slof/fs/start-up.fs | 16 + slof/helpers.c | 17 + 22 files changed, 4265 insertions(+), 6 deletions(-) create mode 100644 board-qemu/slof/vio-vtpm-cdriver.fs create mode 100644 board-qemu/slof/vtpm-sml.fs create mode 100644 lib/libtpm/Makefile create mode 100644 lib/libtpm/Readme create mode 100644 lib/libtpm/sha1.c create mode 100644 lib/libtpm/sha1.h create mode 100644 lib/libtpm/tcgbios.c create mode 100644 lib/libtpm/tcgbios.h create mode 100644 lib/libtpm/tcgbios_int.h create mode 100644 lib/libtpm/tpm.code create mode 100644 lib/libtpm/tpm.in create mode 100644 lib/libtpm/tpm_drivers.c create mode 100644 lib/libtpm/tpm_drivers.h