-
Notifications
You must be signed in to change notification settings - Fork 8
[documentation] adding background information about trenchboot #11
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Closed
Closed
Changes from all commits
Commits
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,78 @@ | ||
| # 1) Background Info | ||
| ### 1.1) What is Trust? | ||
| Trust is when the computer does something on our behalf we have to trust it with our data. A trusted component is that which always behaves in an expected manner. To make a component "trusted", you must establish some root of trust. A Root of Trust Measurement is the process of measuring (hashing) components on a system to validate their integrity. When establishing a root of trust, there are two primary schools of thought: Static Root of Trust Measurements and Dynamic Root of Trust Measurements. | ||
|
|
||
| ### 1.2) SRTM | ||
| SRTM takes place at system boot from firmware / bios. This process requires measurements of the entire boot sequence at once. This is both a good and a bad thing, because any changes to the any part of the process (including even bios settings) would cause the entire system to need to be remeasured. SRTM Starts with Core Root of Trust (CRTM), and works its way up the chain where each link verifies the next. In other words, SRTM starts by measuring the bios boot block and then moves on to measure the rest of the bios. | ||
|
|
||
| ### 1.3) DRTM | ||
| DRTM aims to address shortcomings of SRTM. DRTM creates trusted environment from an untrusted state. Essentially what this means is that regardless of weather or not computer was booted from trusted software, it uses hardware to ensure that no malicious software has been run. For this reason, DRTM takes place after boot, as opposed to SRTM, which takes place pre-boot. Intel’s solution for DRTM is TXT, which utilizes special instructions on the processor (SMX). AMD's solution for DRTM is called SVM. Trenchboot provides a solution for setting up DRTM for an arbitrary platform | ||
|
|
||
| ### 1.4) Typical Measured Launch Process | ||
| The process for carrying out DTRM depends on your system. \ | ||
| [Intel TXT Spec](https://software.intel.com/content/www/us/en/develop/articles/intel-trusted-execution-technology-intel-txt-enabling-guide.html) \ | ||
| [AMD SVM Spec](https://www.amd.com/system/files/TechDocs/24593.pdf) | ||
|
|
||
| ### 1.5) Why TrenchBoot? | ||
| - Managing each of these components individually can be confusing | ||
| - Most DTRM systems are platform dependent | ||
| - Most DTRM systems can only measure what was loaded into memory with it at the time it was started | ||
| - Most DTRM systems support only one attestation action | ||
|
|
||
|
|
||
| # 2) TrenchBoot Architecture | ||
| ### 2.1 Architecture Overview | ||
| *The full architecture overview can be found at [https://github.com/TrenchBoot/documentation/blob/master/documentation/Architecture.md](https://github.com/TrenchBoot/documentation/blob/master/documentation/Architecture.md)* | ||
|  \ | ||
| This diagram shows a general overview of the overall architecture of a TrenchBoot system. In Bootstrap phase the system environment is measured and that information stored in the dynamic PCRs, using whatever method is appropriate for the given hardware. The intermediate phase analyzes the information collected in the bootstrap phase to decide if it wants to continue booting and pass control to the target OS, or if it wants to stop immediately. If desired, additional evidence/measurements can be gathered in this phase. Once the integrity of the system is verified the TrenchBoot kernel passes off control to the actual desired OS to initiate the runtime phase. | ||
|
|
||
| ### 2.2 Bootstrap Phase - GRUB | ||
| Typically, when attempting to establish a DRTM, TBoot is loaded in order to carry out TXT on Intel, or SEV is used on AMD. TrenchBoot instead utilizes its own system, which is a custom version of GRUB that has commands built in to carry out a TrenchBoot "Secure Launch". This customized grub introduces the slaunch and slaunch_module commands. A working example of the TrenchBoot GRUB can be found at [https://github.com/3mdeb/meta-trenchboot](https://github.com/3mdeb/meta-trenchboot). The custom GRUB is however unfinished and while it is running on AMD, it is not yet functional with Intel processors. | ||
|
|
||
| ### 2.3 Intermediate Phase - Linux Kernel / U-ROOT (Initramfs) | ||
| The intermediate phase processes information collected in the bootstrap phase and converts it into normalized data. This data is eventually used to determine whether or not to boot into the target OS. The kernel and u-root initramfs together make up Trenchboot's "Security Engine", which is an intermediate mini-OS that serves to process data gathered by that bootstrap phase. During the intermediate phase, the kernel and initramfs work together to measure block devices, individual files, SMBUS/DMI information and provides unseal based, external device and network based attestation. Trenchboot calls this functionality secure launch (aka slaunch). The table in section 4 lists the specific repo and branch to use when building the kernel or u-root. | ||
|
|
||
| # 3) Practical usage | ||
| ### 3.1 Trenchboot GRUB TXT Config with Serial Communication | ||
| *Note: ACM modules can be downloaded from [http://mirror.openxt.org/](http://mirror.openxt.org/)* | ||
|
|
||
| menuentry 'TrenchBoot' { | ||
| savedefault | ||
| load_video | ||
| set gfxpayload=keep | ||
| insmod gzio | ||
| insmod part_msdos | ||
| insmod ext2 | ||
| set root='hd0,msdos1' | ||
| multiboot2 /boot/slboot.gz loglvl=all serial=115200,8n1,0x3f8 logging=serial,memory | ||
| module2 /boot/vmlinuz-trenchboot root=UUID=<your block uuid> ro intel_iommu=on loglevel=7 console=ttyS0,115200 nokaslr | ||
| module2 /boot/<your acm>.bin | ||
| module2 /boot/initramfs-trenchboot.cpio | ||
| } | ||
|
|
||
| ### 3.2 Testing the System | ||
| QEMU has been tested to boot fully into u-root while simulating the Trenchboot kernel. | ||
| QEMU For external u-root \ | ||
| `qemu-systemx86_64 -kernel <kernel repo>/arch/x86/boot/bzImage -initrd /tmp/initramfs.linux_amd64.cpio -append console=ttyS0,38400 -serial file:serial.out` \ | ||
| QEMU with u-root built-in \ | ||
| `qemu-systemx86_64 -kernel <kernel location>` | ||
|
|
||
| # 4) State of TrenchBoot | ||
| | Name | Purpose | Functionality | Repo | ||
| |----------|-----|---|---| | ||
| | Linux | Kernel | The custom TrenchBoot linux kernel does include working code that allows u-root to function properly. This kernel also functions as a regular kernel in that when it is launched without SLBoot, the data required to begin the measured launch process is simply not exposed. | link: [here](https://github.com/TrenchBoot/linux) working branch: linux-sl-5.5 | ||
| | U-root | initramfs/initrd | By default launching u-root should show “u-root” in big bubble letters along with a shell. The u-root the command to launch into a MLE is sluinit which can be configured to be called automatically. | link: [here](https://github.com/TrenchBoot/u-root/) working branch: for-upstream | ||
| | Grub | *expirmental built-in* secure multiboot preboot module | The custom GRUB seems to be unfinished but soon aims to implement the slaunch and slaunch_module commands. | link: [here](https://github.com/TrenchBoot/grub) working branch: trenchboot_support_2.04 | ||
|
|
||
| # 5) Various Github and further documentation links | ||
| > (AMD only project), contains Trenchboot working custom GRUB and u-root with tpm2 tools | ||
| 3mdeb, meta-trenchboot (2020, April 17), Github Repository, \ | ||
| https://github.com/3mdeb/meta-trenchboot | ||
|
|
||
| > LKML Trenchboot doc | ||
| Philipson, R. (2020, March 25) [RFC PATCH 00/12] x86: Trenchboot secure late launch Linux kernel support \ | ||
| https://lkml.org/lkml/2020/3/25/982 | ||
|
|
||
| > TrenchBoot informative talk | ||
| The Linux Foundation. (2019, October 1). TrenchBoot - How to Nicely Boot System with Intel TXT and AMD SVM [Video]. YouTube. \ | ||
| https://www.youtube.com/watch?v=DbpCU9iSi4g | ||
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@garnetgrimm it would be way easier to review if the document would be wrapped at 80 characters