mbox series

[00/13] x86: Trenchboot secure dynamic launch Linux kernel support

Message ID 1600959521-24158-1-git-send-email-ross.philipson@oracle.com (mailing list archive)
Headers show
Series x86: Trenchboot secure dynamic launch Linux kernel support | expand

Message

Ross Philipson Sept. 24, 2020, 2:58 p.m. UTC
The Trenchboot project focus on boot security has led to the enabling of
the Linux kernel to be directly invocable by the x86 Dynamic Launch
instruction(s) for establishing a Dynamic Root of Trust for Measurement
(DRTM). The dynamic launch will be initiated by a boot loader with
associated support added to it, for example the first targeted boot
loader will be GRUB2. An integral part of establishing the DRTM involves
measuring everything that is intended to be run (kernel image, initrd,
etc) and everything that will configure that kernel to run (command
line, boot params, etc) into specific PCRs, the DRTM PCRs (17-22), in
the TPM. Another key aspect is the dynamic launch is rooted in hardware,
that is to say the hardware (CPU) is what takes the first measurement
for the chain of integrity measurements. On Intel this is done using
the GETSEC instruction provided by Intel's TXT and the SKINIT
instruction provided by AMD's AMD-V. Information on these technologies
can be readily found online. This patchset introduces Intel TXT support.

To enable the kernel to be launched by GETSEC, a stub must be built
into the setup section of the compressed kernel to handle the specific
state that the dynamic launch process leaves the BSP in. This is
analogous to the EFI stub that is found in the same area. Also this stub
must measure everything that is going to be used as early as possible.
This stub code and subsequent code must also deal with the specific
state that the dynamic launch leaves the APs in.

A quick note on terminology. The larger open source project itself is
called Trenchboot, which is hosted on Github (links below). The kernel
feature enabling the use of the x86 technology is referred to as "Secure
Launch" within the kernel code. As such the prefixes sl_/SL_ or
slaunch/SLAUNCH will be seen in the code. The stub code discussed above
is referred to as the SL stub.

The basic flow is:

 - Entry from the dynamic launch jumps to the SL stub
 - SL stub fixes up the world on the BSP
 - For TXT, SL stub wakes the APs, fixes up their worlds
 - For TXT, APs are left halted waiting for an NMI to wake them
 - SL stub jumps to startup_32
 - SL main runs to measure configuration and module information into the
   DRTM PCRs. It also locates the TPM event log.
 - Kernel boot proceeds normally from this point.
 - During early setup, slaunch_setup() runs to finish some validation
   and setup tasks.
 - The SMP bringup code is modified to wake the waiting APs. APs vector
   to rmpiggy and start up normally from that point.
 - Kernel boot finishes booting normally
 - SL securityfs module is present to allow reading and writing of the
   TPM event log.
 - SEXIT support to leave SMX mode is present on the kexec path and
   the various reboot paths (poweroff, reset, halt).

Links:

The Trenchboot project including documentation:

https://github.com/trenchboot

Intel TXT is documented in its own specification and in the SDM Instruction Set volume:

https://www.intel.com/content/dam/www/public/us/en/documents/guides/intel-txt-software-development-guide.pdf
https://software.intel.com/en-us/articles/intel-sdm

AMD SKINIT is documented in the System Programming manual:

https://www.amd.com/system/files/TechDocs/24593.pdf

GRUB2 pre-launch support patchset (WIP):

https://lists.gnu.org/archive/html/grub-devel/2020-05/msg00011.html

Thanks
Ross Philipson and Daniel P. Smith

Daniel P. Smith (4):
  x86: Add early TPM TIS/CRB interface support for Secure Launch
  x86: Add early TPM1.2/TPM2.0 interface support for Secure Launch
  x86: Add early general TPM interface support for Secure Launch
  x86: Secure Launch adding event log securityfs

Ross Philipson (9):
  x86: Secure Launch Kconfig
  x86: Secure Launch main header file
  x86: Add early SHA support for Secure Launch early measurements
  x86: Secure Launch kernel early boot stub
  x86: Secure Launch kernel late boot stub
  x86: Secure Launch SMP bringup support
  kexec: Secure Launch kexec SEXIT support
  reboot: Secure Launch SEXIT support on reboot paths
  tpm: Allow locality 2 to be set when initializing the TPM for Secure
    Launch

 Documentation/x86/boot.rst                    |   9 +
 arch/x86/Kconfig                              |  36 ++
 arch/x86/boot/compressed/Makefile             |   8 +
 arch/x86/boot/compressed/early_sha1.c         | 104 ++++
 arch/x86/boot/compressed/early_sha1.h         |  17 +
 arch/x86/boot/compressed/early_sha256.c       |   6 +
 arch/x86/boot/compressed/early_sha512.c       |   6 +
 arch/x86/boot/compressed/head_64.S            |  34 +
 arch/x86/boot/compressed/kernel_info.S        |   7 +
 arch/x86/boot/compressed/sl_main.c            | 390 ++++++++++++
 arch/x86/boot/compressed/sl_stub.S            | 606 ++++++++++++++++++
 arch/x86/boot/compressed/tpm/crb.c            | 304 +++++++++
 arch/x86/boot/compressed/tpm/crb.h            |  20 +
 arch/x86/boot/compressed/tpm/tis.c            | 215 +++++++
 arch/x86/boot/compressed/tpm/tis.h            |  46 ++
 arch/x86/boot/compressed/tpm/tpm.c            | 145 +++++
 arch/x86/boot/compressed/tpm/tpm.h            |  48 ++
 arch/x86/boot/compressed/tpm/tpm1.h           | 112 ++++
 arch/x86/boot/compressed/tpm/tpm1_cmds.c      |  99 +++
 arch/x86/boot/compressed/tpm/tpm2.h           |  89 +++
 arch/x86/boot/compressed/tpm/tpm2_auth.c      |  44 ++
 arch/x86/boot/compressed/tpm/tpm2_auth.h      |  21 +
 arch/x86/boot/compressed/tpm/tpm2_cmds.c      | 145 +++++
 arch/x86/boot/compressed/tpm/tpm2_constants.h |  66 ++
 arch/x86/boot/compressed/tpm/tpm_buff.c       | 121 ++++
 arch/x86/boot/compressed/tpm/tpm_common.h     | 127 ++++
 arch/x86/boot/compressed/tpm/tpmbuff.h        |  34 +
 arch/x86/boot/compressed/tpm/tpmio.c          |  51 ++
 arch/x86/include/asm/realmode.h               |   3 +
 arch/x86/kernel/Makefile                      |   1 +
 arch/x86/kernel/asm-offsets.c                 |  16 +
 arch/x86/kernel/reboot.c                      |  10 +
 arch/x86/kernel/setup.c                       |   3 +
 arch/x86/kernel/slaunch.c                     | 856 ++++++++++++++++++++++++++
 arch/x86/kernel/smpboot.c                     |  86 +++
 arch/x86/realmode/rm/header.S                 |   3 +
 arch/x86/realmode/rm/trampoline_64.S          |  37 ++
 drivers/char/tpm/tpm-chip.c                   |  13 +-
 drivers/iommu/intel/dmar.c                    |   4 +
 include/linux/sha512.h                        |  21 +
 include/linux/slaunch.h                       | 544 ++++++++++++++++
 kernel/kexec_core.c                           |   4 +
 lib/sha1.c                                    |   4 +
 lib/sha512.c                                  | 209 +++++++
 44 files changed, 4722 insertions(+), 2 deletions(-)
 create mode 100644 arch/x86/boot/compressed/early_sha1.c
 create mode 100644 arch/x86/boot/compressed/early_sha1.h
 create mode 100644 arch/x86/boot/compressed/early_sha256.c
 create mode 100644 arch/x86/boot/compressed/early_sha512.c
 create mode 100644 arch/x86/boot/compressed/sl_main.c
 create mode 100644 arch/x86/boot/compressed/sl_stub.S
 create mode 100644 arch/x86/boot/compressed/tpm/crb.c
 create mode 100644 arch/x86/boot/compressed/tpm/crb.h
 create mode 100644 arch/x86/boot/compressed/tpm/tis.c
 create mode 100644 arch/x86/boot/compressed/tpm/tis.h
 create mode 100644 arch/x86/boot/compressed/tpm/tpm.c
 create mode 100644 arch/x86/boot/compressed/tpm/tpm.h
 create mode 100644 arch/x86/boot/compressed/tpm/tpm1.h
 create mode 100644 arch/x86/boot/compressed/tpm/tpm1_cmds.c
 create mode 100644 arch/x86/boot/compressed/tpm/tpm2.h
 create mode 100644 arch/x86/boot/compressed/tpm/tpm2_auth.c
 create mode 100644 arch/x86/boot/compressed/tpm/tpm2_auth.h
 create mode 100644 arch/x86/boot/compressed/tpm/tpm2_cmds.c
 create mode 100644 arch/x86/boot/compressed/tpm/tpm2_constants.h
 create mode 100644 arch/x86/boot/compressed/tpm/tpm_buff.c
 create mode 100644 arch/x86/boot/compressed/tpm/tpm_common.h
 create mode 100644 arch/x86/boot/compressed/tpm/tpmbuff.h
 create mode 100644 arch/x86/boot/compressed/tpm/tpmio.c
 create mode 100644 arch/x86/kernel/slaunch.c
 create mode 100644 include/linux/sha512.h
 create mode 100644 include/linux/slaunch.h
 create mode 100644 lib/sha512.c

Comments

Jarkko Sakkinen Sept. 25, 2020, 5:30 a.m. UTC | #1
On Thu, Sep 24, 2020 at 10:58:28AM -0400, Ross Philipson wrote:
> The Trenchboot project focus on boot security has led to the enabling of
> the Linux kernel to be directly invocable by the x86 Dynamic Launch
> instruction(s) for establishing a Dynamic Root of Trust for Measurement
> (DRTM). The dynamic launch will be initiated by a boot loader with

What is "the dynamic launch"?

> associated support added to it, for example the first targeted boot
> loader will be GRUB2. An integral part of establishing the DRTM involves
> measuring everything that is intended to be run (kernel image, initrd,
> etc) and everything that will configure that kernel to run (command
> line, boot params, etc) into specific PCRs, the DRTM PCRs (17-22), in
> the TPM. Another key aspect is the dynamic launch is rooted in hardware,
> that is to say the hardware (CPU) is what takes the first measurement
> for the chain of integrity measurements. On Intel this is done using
> the GETSEC instruction provided by Intel's TXT and the SKINIT
> instruction provided by AMD's AMD-V. Information on these technologies
> can be readily found online. This patchset introduces Intel TXT support.

Why not both Intel and AMD? You should explain this in the cover letter.

I'd be more motivated to review and test a full all encompassing x86
solution. It would increase the patch set size but would also give it
a better test coverage, which I think would be a huge plus in such a
complex patch set.

> To enable the kernel to be launched by GETSEC, a stub must be built
> into the setup section of the compressed kernel to handle the specific
> state that the dynamic launch process leaves the BSP in. This is
> analogous to the EFI stub that is found in the same area. Also this stub

How is it analogous?

> must measure everything that is going to be used as early as possible.
> This stub code and subsequent code must also deal with the specific
> state that the dynamic launch leaves the APs in.

What is "the specific state"?

> A quick note on terminology. The larger open source project itself is
> called Trenchboot, which is hosted on Github (links below). The kernel
> feature enabling the use of the x86 technology is referred to as "Secure
> Launch" within the kernel code. As such the prefixes sl_/SL_ or
> slaunch/SLAUNCH will be seen in the code. The stub code discussed above
> is referred to as the SL stub.

Is this only for Trenchboot? I'm a bit lost. What is it anyway?

> The basic flow is:
> 
>  - Entry from the dynamic launch jumps to the SL stub
>  - SL stub fixes up the world on the BSP

What is "SL"?

>  - For TXT, SL stub wakes the APs, fixes up their worlds
>  - For TXT, APs are left halted waiting for an NMI to wake them
>  - SL stub jumps to startup_32
>  - SL main runs to measure configuration and module information into the
>    DRTM PCRs. It also locates the TPM event log.
>  - Kernel boot proceeds normally from this point.
>  - During early setup, slaunch_setup() runs to finish some validation
>    and setup tasks.

What are "some" validation and setup tasks?

>  - The SMP bringup code is modified to wake the waiting APs. APs vector
>    to rmpiggy and start up normally from that point.
>  - Kernel boot finishes booting normally
>  - SL securityfs module is present to allow reading and writing of the
>    TPM event log.

What is SL securityfs module? Why is it needed? We already have
securityfs file for the event log. Why it needs to be writable?

>  - SEXIT support to leave SMX mode is present on the kexec path and
>    the various reboot paths (poweroff, reset, halt).

What SEXIT do and why it is required on the kexec path?

/Jarkko
Daniel P. Smith Sept. 25, 2020, 9:32 p.m. UTC | #2
On 9/25/20 1:30 AM, Jarkko Sakkinen wrote:
> On Thu, Sep 24, 2020 at 10:58:28AM -0400, Ross Philipson wrote:
>> The Trenchboot project focus on boot security has led to the enabling of
>> the Linux kernel to be directly invocable by the x86 Dynamic Launch
>> instruction(s) for establishing a Dynamic Root of Trust for Measurement
>> (DRTM). The dynamic launch will be initiated by a boot loader with
> 
> What is "the dynamic launch"?

Dynamic launch is the term used to reference the event/process of
restarting a system without reboot to establish the DRTM. It is defined
in the TCG Glossary[1], is discussed in detail in the TCG D-RTM
Architecture specification[2], and covered in minimal detail in sections
9.5.5 and 34.2 of the TCG TPM2.0 Architecture specification[3].

[1]
https://trustedcomputinggroup.org/wp-content/uploads/TCG-Glossary-V1.1-Rev-1.0.pdf
[2]
https://trustedcomputinggroup.org/wp-content/uploads/TCG_D-RTM_Architecture_v1-0_Published_06172013.pdf
[3]
https://trustedcomputinggroup.org/wp-content/uploads/TCG_TPM2_r1p59_Part1_Architecture_pub.pdf

>> associated support added to it, for example the first targeted boot
>> loader will be GRUB2. An integral part of establishing the DRTM involves
>> measuring everything that is intended to be run (kernel image, initrd,
>> etc) and everything that will configure that kernel to run (command
>> line, boot params, etc) into specific PCRs, the DRTM PCRs (17-22), in
>> the TPM. Another key aspect is the dynamic launch is rooted in hardware,
>> that is to say the hardware (CPU) is what takes the first measurement
>> for the chain of integrity measurements. On Intel this is done using
>> the GETSEC instruction provided by Intel's TXT and the SKINIT
>> instruction provided by AMD's AMD-V. Information on these technologies
>> can be readily found online. This patchset introduces Intel TXT support.
> 
> Why not both Intel and AMD? You should explain this in the cover letter.

The work for this is split across different teams with different
resourcing levels resulting in one organization working Intel and
another working AMD. This then raised the concern over submitting a
single patch set developed by two groups pseudo-independently. In this
situation the result would be patches being submitted from one
organization that had no direct development or testing and therefore
could not sign off on a subset of the patches being submitted.

> I'd be more motivated to review and test a full all encompassing x86
> solution. It would increase the patch set size but would also give it
> a better test coverage, which I think would be a huge plus in such a
> complex patch set.

We would not disagree with those sentiments but see the previous
response about the conflict that exists.

>> To enable the kernel to be launched by GETSEC, a stub must be built
>> into the setup section of the compressed kernel to handle the specific
>> state that the dynamic launch process leaves the BSP in. This is
>> analogous to the EFI stub that is found in the same area. Also this stub
> 
> How is it analogous?

It is analogous as we used it as the pattern to follow for adding a
configurable entry point to the kernel. There was a discussion on this
when we published the RFC patches[4].

[4] https://lkml.org/lkml/2020/3/25/982

>> must measure everything that is going to be used as early as possible.
>> This stub code and subsequent code must also deal with the specific
>> state that the dynamic launch leaves the APs in.
> 
> What is "the specific state"?

The details are a bit more than I would prefer to explain here, I would
recommend reading section 2.3 and 2.4 of Intel's TXT Software
Development Guide[5] for all the details of the state and the prescribed
initialization sequence.

[5]
https://www.intel.com/content/dam/www/public/us/en/documents/guides/intel-txt-software-development-guide.pdf

>> A quick note on terminology. The larger open source project itself is
>> called Trenchboot, which is hosted on Github (links below). The kernel
>> feature enabling the use of the x86 technology is referred to as "Secure
>> Launch" within the kernel code. As such the prefixes sl_/SL_ or
>> slaunch/SLAUNCH will be seen in the code. The stub code discussed above
>> is referred to as the SL stub.
> 
> Is this only for Trenchboot? I'm a bit lost. What is it anyway?

TrenchBoot is a meta-project that is working to bring a unified approach
to using DRTM across CPU implementations and open source projects.
Currently we are working to integrate a dynamic launch preamble (the
code that sets up for calling the dynamic launch CPU instruction) in
GRUB, building an open AMD Secure Loader that aligns with how Intel's
SINIT ACM hands off to an MLE, bring the first directly launchable
implementation to Linux (Secure Launch) with Xen being the next directly
launchable implementation, providing the u-root project a secure launch
initramfs init routine to demonstrate a policy driven measurement and
attestation framework that can be used in conjunction with a Secure
Launch kernel.


>> The basic flow is:
>>
>>  - Entry from the dynamic launch jumps to the SL stub
>>  - SL stub fixes up the world on the BSP
> 
> What is "SL"?

As mentioned above, it is just shorthand for Secure Launch.

>>  - For TXT, SL stub wakes the APs, fixes up their worlds
>>  - For TXT, APs are left halted waiting for an NMI to wake them
>>  - SL stub jumps to startup_32
>>  - SL main runs to measure configuration and module information into the
>>    DRTM PCRs. It also locates the TPM event log.
>>  - Kernel boot proceeds normally from this point.
>>  - During early setup, slaunch_setup() runs to finish some validation
>>    and setup tasks.
> 
> What are "some" validation and setup tasks?

The validation and setup steps are to ensure the environment was setup
in a manner that we expected as outlined in the Intel TXT Software
Development guide[4]. At this point these are,
- Ensure that SENTER completed successfully and was not initiated by TBOOT.
- Check that the private MMIO register bank is available.
- Fetch values needed from the TXT heap for later operations.
- Verify the PMR values cover the MLE and other memory regions that need
to be secure.
- Reserve certain TXT specific areas of physical memory.
- Fetch the copy of the DMAR table from the TXT heap to provide to the
IOMMU driver later.

>>  - The SMP bringup code is modified to wake the waiting APs. APs vector
>>    to rmpiggy and start up normally from that point.
>>  - Kernel boot finishes booting normally
>>  - SL securityfs module is present to allow reading and writing of the
>>    TPM event log.
> 
> What is SL securityfs module? Why is it needed? We already have
> securityfs file for the event log. Why it needs to be writable?

The securityfs nodes provides access to the TXT registers to inspect the
details from the dynamic launch and access to the DRTM event log. The
DRTM event log is setup by the DRTM process and is a different/separate
event log from the SRTM/UEFI event log. We need write access for use
cases where the Secure Launch kernel is being used as an intermediate
launch kernel where additional measurements about the final target
environment are being collected.

>>  - SEXIT support to leave SMX mode is present on the kexec path and
>>    the various reboot paths (poweroff, reset, halt).
> 
> What SEXIT do and why it is required on the kexec path?

The SEXIT instruction "exits" SMX mode. The why is because when in SMX
mode the CPU has a set of behaviors different than what is typically
expected, especially for SMP management. As good custodians, this
ensures that the system is in a usable state for a follow-on kernel that
is not SMX/Secure Launch aware. From a security use case perspective,
leaving SMX mode disables access to localities 1-3 of the TPM. This
essentially "locks" the values in the DRTM PCRs from further
modification/extends until another dynamic launch event is fired which
will in turn result in the DRTM PCRs being reset.

> /Jarkko
>
Jarkko Sakkinen Sept. 27, 2020, 11:59 p.m. UTC | #3
On Fri, Sep 25, 2020 at 05:32:50PM -0400, Daniel P. Smith wrote:
> The work for this is split across different teams with different
> resourcing levels resulting in one organization working Intel and
> another working AMD. This then raised the concern over submitting a
> single patch set developed by two groups pseudo-independently. In this
> situation the result would be patches being submitted from one
> organization that had no direct development or testing and therefore
> could not sign off on a subset of the patches being submitted.

Not sure if internal team structures qualify as a techical argument for
upstream code.

> > I'd be more motivated to review and test a full all encompassing x86
> > solution. It would increase the patch set size but would also give it
> > a better test coverage, which I think would be a huge plus in such a
> > complex patch set.
> 
> We would not disagree with those sentiments but see the previous
> response about the conflict that exists.

At minimum, you have to make the case that the AMD support is easy to
tackle in to the framework of things you have later on.

/Jarkko