mirror of
https://github.com/Dasharo/docs.git
synced 2026-03-06 14:46:22 -08:00
muxPi docs minor corrections
Signed-off-by: Przemysław Sulewski <przemyslaw.sulewski@3mdeb.com>
This commit is contained in:
Przemysław Sulewski
+1
-1
@@ -140,7 +140,7 @@ MD031:
|
||||
# MD033/no-inline-html - Inline HTML
|
||||
MD033:
|
||||
# Allowed elements
|
||||
allowed_elements: ["br"]
|
||||
allowed_elements: ["br", "center", "img", "script"]
|
||||
|
||||
# MD034/no-bare-urls - Bare URL used
|
||||
MD034: true
|
||||
|
||||
@@ -7,7 +7,7 @@ This repository contains source code for Dasharo documentation webpage
|
||||
```shell
|
||||
virtualenv -p $(which python3) venv
|
||||
source venv/bin/activate
|
||||
pip install mkdocs mkdocs-material
|
||||
pip install -r requirements.txt
|
||||
mkdocs build
|
||||
```
|
||||
|
||||
@@ -36,11 +36,15 @@ There should be no TBD or TODO visible on website.
|
||||
|
||||
# pre-commit hooks
|
||||
|
||||
- [Install pre-commit](https://pre-commit.com/index.html#install)
|
||||
- [Install pre-commit](https://pre-commit.com/index.html#install), if you
|
||||
followed [local build](#local-build) procedure `pre-commit` should be
|
||||
installed
|
||||
|
||||
- [Install go](https://go.dev/doc/install)
|
||||
|
||||
- Install hooks into repo:
|
||||
|
||||
```
|
||||
```bash
|
||||
pre-commit install --hook-type commit-msg
|
||||
```
|
||||
|
||||
@@ -52,3 +56,12 @@ pre-commit install --hook-type commit-msg
|
||||
```bash
|
||||
pre-commit run --all-files
|
||||
```
|
||||
|
||||
## To skip verification
|
||||
|
||||
In some cases it may be needed to skip `pre-commit` tests, to do that please
|
||||
use:
|
||||
|
||||
```bash
|
||||
git commit --no-verify
|
||||
```
|
||||
|
||||
@@ -0,0 +1,37 @@
|
||||
# Dasharo Tools Suite
|
||||
|
||||
## Introduction
|
||||
|
||||
Dasharo Tools Suite (DTS) is a set of tools for deploying, updating and
|
||||
maintaining firmware on Dasharo supported devices. DTS is integrated into the
|
||||
firmware in Dasharo supported devices and can be used to update the firmware
|
||||
even when no OS is installed.
|
||||
|
||||
## Requirements
|
||||
|
||||
- Dasharo device with DTS functionality integrated
|
||||
- Wired network connection
|
||||
- Secure Boot disabled
|
||||
|
||||
## Launching DTS
|
||||
|
||||
To access Dasharo Tools Suite:
|
||||
|
||||
- Attach a wired network cable to the device's Ethernet port
|
||||
- Power on the device, holding down the Boot Menu entry key
|
||||
- In the Boot Menu, select the `iPXE Network Boot` option
|
||||
- In the Network Boot menu, select the `Dasharo Tools Suite` option
|
||||
- Login as `root` (no password)
|
||||
|
||||
The DTS shell will now appear.
|
||||
|
||||
## Using DTS
|
||||
|
||||
Within DTS, you may use the `flashrom` and `fwupdmgr` utilities to update,
|
||||
downgrade, or reinstall your firmware.
|
||||
|
||||
To update your firmware to the latest version:
|
||||
|
||||
```bash
|
||||
fwupdmgr update
|
||||
```
|
||||
@@ -10,15 +10,16 @@ for Dasharo developers.
|
||||
|
||||
### Vendor field
|
||||
|
||||
The Vendor field, for firmware with initial release date after 13 January 2021, is set as follows:
|
||||
The Vendor field, for firmware with initial release date after 13 January 2021,
|
||||
is set as follows:
|
||||
|
||||
```
|
||||
```bash
|
||||
3mdeb
|
||||
```
|
||||
|
||||
For firmware with initial release date before 13 January 2021:
|
||||
|
||||
```
|
||||
```bash
|
||||
3mdeb Embedded Systems Consulting
|
||||
```
|
||||
|
||||
@@ -35,10 +36,11 @@ Dasharo ([major_framework]+[minor_framework]) v[version]
|
||||
- `minor_framework` is the secondary framework, a supporting component for the
|
||||
primary framework, e.g. a coreboot payload. May not always be used, e.g. if
|
||||
`edk2` is used as the primary framework.
|
||||
- `version` means version according to official [Dasharo Versioning](../versioning) documentation.
|
||||
- `version` means version according to official
|
||||
[Dasharo Versioning](../versioning) documentation.
|
||||
|
||||
*For [TianoCore UEFIPayloadPkg](https://github.com/Dasharo/edk2/tree/workstation/master/UefiPayloadPkg),
|
||||
we use the simpler and more recognizable UEFI name.*
|
||||
_For [TianoCore UEFIPayloadPkg](https://github.com/Dasharo/edk2/tree/workstation/master/UefiPayloadPkg),
|
||||
we use the simpler and more recognizable UEFI name._
|
||||
|
||||
Examples:
|
||||
|
||||
|
||||
@@ -5,7 +5,9 @@ branch structure:
|
||||
|
||||
* `master` - follows upstream project master branch
|
||||
* `<platform>/release` - contains all code releases for given `<platform>`,
|
||||
list of supported platforms is in [Hardware Compatibility List](../variants/hardware-compatibility-list.md) section
|
||||
list of supported platforms is in
|
||||
[Hardware Compatibility List](../variants/hardware-compatibility-list.md)
|
||||
section
|
||||
* `<platform>/rel_vX.Y.Z` - release branch for version X.Y.Z
|
||||
* `<platform>/develop` - contains most recent development and is periodically
|
||||
synced with `master` branch
|
||||
|
||||
@@ -1,5 +1,6 @@
|
||||
Ecosystem Overview
|
||||
------------------
|
||||
# Ecosystem Overview
|
||||
|
||||
---
|
||||
|
||||
Dasharo ecosystem contain multiple components on various levels of
|
||||
organization. This section overview role of every component.
|
||||
@@ -18,11 +19,11 @@ organization. This section overview role of every component.
|
||||
development infrastructure, build environment, CI/CD and build publishing
|
||||
methods. We also cover how production interacts with Dasharo Transparent
|
||||
Validation System.
|
||||
* Customer Infrastructure - Some customers may have the need of replicating part of
|
||||
Dasharo Production process and infrastructure in their own environment, which
|
||||
leads to repositories synchronization, different CI/CD setup and other needs.
|
||||
This section describes interaction with Customer Infrastructure and which part
|
||||
of Dasharo Production is deployable on the customer site.
|
||||
* Customer Infrastructure - Some customers may have the need of replicating part
|
||||
of Dasharo Production process and infrastructure in their own environment,
|
||||
which leads to repositories synchronization, different CI/CD setup and other
|
||||
needs. This section describes interaction with Customer Infrastructure and
|
||||
which part of Dasharo Production is deployable on the customer site.
|
||||
* Transparent Validation - Dasharo Transparent Validation (DTV) is a set of
|
||||
software, firmware and hardware components with the goal of simplifying and
|
||||
improving long term maintenance of Dasharo firmware. In this section we
|
||||
|
||||
@@ -3,14 +3,15 @@
|
||||
Each features on below roadmap should be placed in public issue tracker, so it
|
||||
can be publicly referenced. Some places where issues can be discussed:
|
||||
|
||||
* [Dasharo Github issues repo](https://github.com/Dasharo/dasharo-issues/issues) - especially issues
|
||||
tagged `enhancement`.
|
||||
* [Dasharo Github issues repo](https://github.com/Dasharo/dasharo-issues/issues)
|
||||
- especially issues tagged `enhancement`.
|
||||
* coreboot issues tracker
|
||||
* edk2 bugzilla
|
||||
|
||||
## Backlog
|
||||
|
||||
* [TrenchBoot Roadmap](https://github.com/TrenchBoot/documentation/blob/master/roadmap/Roadmap.pdf) firmware related issues.
|
||||
* [TrenchBoot Roadmap](https://github.com/TrenchBoot/documentation/blob/master/roadmap/Roadmap.pdf)
|
||||
firmware related issues.
|
||||
* Dasharo Reference OS on USB stick to simplify firmware deployment
|
||||
* fwupd/LVFS for firmware deployment
|
||||
* ipxe for firmware deployment
|
||||
|
||||
Executable
BIN
Binary file not shown.
|
After Width: | Height: | Size: 16 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 2.6 MiB |
Executable
BIN
Binary file not shown.
|
After Width: | Height: | Size: 33 KiB |
+2
-2
@@ -1,6 +1,6 @@
|
||||
<img src="images/logo/logo-bar.svg" width="1000" height="500">
|
||||
# <img src="images/logo/logo-bar.svg" width="1000" height="500">
|
||||
|
||||
## About
|
||||
# About
|
||||
|
||||
Dasharo is open-source firmware distribution focusing on clean and simple code,
|
||||
long-term maintenance, transparent validation, privacy-respecting
|
||||
|
||||
@@ -8,7 +8,11 @@ If you can't find the answer to your questions feel free to contact us through
|
||||
[Community Channels](../index.md#community) or submit issue through [Dasharo
|
||||
Github](https://github.com/Dasharo/dasharo-issues).
|
||||
|
||||
## What to do when flashrom returns `Could not get I/O privileges (Operation not permitted)`?
|
||||
## Flashrom
|
||||
|
||||
Following sections explain how to deal with most common `flashrom` errors.
|
||||
|
||||
### `Could not get I/O privileges (Operation not permitted)`
|
||||
|
||||
If you see a flashrom error like this:
|
||||
|
||||
@@ -21,7 +25,7 @@ Error: Programmer initialization failed.
|
||||
It means you have insufficient privileges to perform initialization. Please use
|
||||
`sudo` before `flashrom` command.
|
||||
|
||||
## What to do when flashrom returns `/dev/mem mmap failed: Operation not permitted`?
|
||||
### `/dev/mem mmap failed: Operation not permitted`
|
||||
|
||||
``` console
|
||||
/dev/mem mmap failed: Operation not permitted
|
||||
@@ -82,7 +86,7 @@ If the above does not resolve the problem, the kernel may be compiled with stric
|
||||
devmem, which prohibits accessing the IOMEM. You should then take different
|
||||
Linux system.
|
||||
|
||||
## What to do when flashrom returns `Transaction error between offset ...`?
|
||||
### `Transaction error between offset ...`?
|
||||
|
||||
``` console
|
||||
SPI Configuration is locked down.
|
||||
|
||||
@@ -13,8 +13,8 @@ This is because knowing hashes of firmware components, we can calculate expected
|
||||
TPM PCRs values. By knowing good PCR values and being able to predict further
|
||||
values after firmware update, we are gaining the following advantages:
|
||||
|
||||
* We can easily confirm if the firmware is valid by reading TPM PCRs and compare to
|
||||
reference integrity measures (RIM), RIM can be calculated by build exactly
|
||||
* We can easily confirm if the firmware is valid by reading TPM PCRs and compare
|
||||
to reference integrity measures (RIM), RIM can be calculated by build exactly
|
||||
the same version of OSF.
|
||||
|
||||
**NOTE**: Please note that depending on your threat model using TPM chip with
|
||||
@@ -87,8 +87,8 @@ Some more detailed notes related to `coreboot-sdk` issues are presented below.
|
||||
3. `coreboot-sdk` is based on moving target Debian sid. It is close to impossible
|
||||
to build the same Docker images at 2 different points in time.
|
||||
4. coreboot-sdk enforce given version of ACPI spec - this may not always be
|
||||
a good thing to use the most recent compiler and update code accordingly since it
|
||||
can easily break OSes.
|
||||
a good thing to use the most recent compiler and update code accordingly
|
||||
since it can easily break OSes.
|
||||
|
||||
#### Why we care?
|
||||
|
||||
@@ -123,7 +123,8 @@ Open-source firmware development and build environment SHOULD have:
|
||||
of Yocto or Buildroot. Another path could be Nix or Guix, which is currently
|
||||
pursued in the community [OSFW #guix-buildstack channel](http://osfw.slack.com/)
|
||||
- this is a private channel; feel free to ping anyone from 3mdeb Team to join.
|
||||
2. coreboot toolchain is built by its own build system, which would be hard to couple with Dockerfile or something else.
|
||||
2. coreboot toolchain is built by its own build system, which would be hard to
|
||||
couple with Dockerfile or something else.
|
||||
3. Docker images can be signed using `docker trust` commands as described
|
||||
[here](https://docs.docker.com/engine/security/trust/#signing-images-with-docker-content-trust).
|
||||
4. Other idea would be to use `wget` and `dpkg -i` for every needed package in
|
||||
|
||||
@@ -1,5 +1,6 @@
|
||||
`[OSFI002]` Trusted computing
|
||||
-------------------------
|
||||
# `[OSFI002]` Trusted computing
|
||||
|
||||
---
|
||||
|
||||
# `[OSFI0020]` CRTM what it stand for?
|
||||
|
||||
|
||||
@@ -0,0 +1,299 @@
|
||||
---
|
||||
template: giscus.html
|
||||
---
|
||||
|
||||
# Trenchboot as Anti Evil Maid
|
||||
|
||||
## Abstract
|
||||
|
||||
The firmware is the heart of the security of a given system and should always
|
||||
be up-to-date to maintain the computer's security. However, being up to date
|
||||
does not prevent the firmware vulnerabilities from appearing. The Static Root
|
||||
of Trust (SRT) like Unified Extensible Firmware Interface (UEFI) Secure Boot
|
||||
and measured boot provided by the firmware is not always sufficient to
|
||||
establish a secure environment for an operating system. If the firmware is
|
||||
compromised, it could inject malicious software into operating system
|
||||
components and prevent the machine owner from detecting it. Silicon vendors
|
||||
implement alternative technologies to establish a Dynamic Root of Trust (DRT)
|
||||
to provide a secure environment for operating system launch and integrity
|
||||
measurements. Either from SRT or DRT, these integrity measurements can be used
|
||||
for operating system attestation. However, DRT technologies are designed to
|
||||
provide the ability to establish a secure environment for integrity
|
||||
measurements at any arbitrary point of time instead of relying on the firmware,
|
||||
which requires machine reset to establish the aforementioned secure
|
||||
environment.
|
||||
|
||||
The usage of DRT technologies like Intel Trusted Execution Technology (TXT) or
|
||||
AMD Secure Startup becomes more and more significant, for example, Dynamic Root
|
||||
of Trust for Measurement (DRTM) requirements of
|
||||
|
||||
[Microsoft Secured Core PCs][ms_sec_core]. DRTM hasn't found its place in
|
||||
open-source projects yet, but that gradually changes. The demand on having
|
||||
firmware independent Roots of Trust is increasing, and projects that satisfy
|
||||
this demand are growing, for instance, [TrenchBoot][tb_org]. TrenchBoot is a
|
||||
framework that allows individuals and projects to build security engines to
|
||||
perform launch integrity actions for their systems. The framework builds upon
|
||||
Boot Integrity Technologies (BITs) that establish one or more Roots of Trust
|
||||
(RoT) from which a degree of confidence that integrity actions were not
|
||||
subverted. The project has grown a lot thanks to the previous
|
||||
[NLnet NGI0 PET grant][nlnet_open_drtm] and now it looks for further expansion
|
||||
into extensive use of the DRT technologies in open-source and security-oriented
|
||||
operating systems like [Qubes OS][qubes_os_org].
|
||||
[Qubes OS Anti Evil Maid (AEM)][it_aem] software heavily depends on the
|
||||
availability of the DRTM technologies to prevent the
|
||||
[Evil Maid attacks][em_attacks]. However, the project hasn't evolved much since
|
||||
the beginning of 2018 and froze on the support of TPM 1.2 with Intel TXT in
|
||||
legacy boot mode (BIOS). Because of that, the usage of this security software
|
||||
is effectively limited to older Intel machines only. TPM 1.2 implemented SHA1
|
||||
hashing algorithm, which is nowadays considered weak in the era of
|
||||
forever-increasing computer performance and quantum computing. The solution to
|
||||
this problem comes with a newer TPM 2.0 with more agile cryptographic
|
||||
algorithms and SHA256 implementation by default. Qubes OS AEM software suffers
|
||||
from the following:
|
||||
|
||||
1. Lack of TPM 2.0 support to handle more secure hashes and safer design of the
|
||||
TPM firmware according to a newer specification.
|
||||
2. Lack of UEFI mode support. All modern systems boot in UEFI mode only. Legacy
|
||||
boot modes are being deprecated and dropped from the PC firmware. The AEM
|
||||
usage is not possible on most if not all modern machines.
|
||||
3. Qubes OS AEM has never supported AMD processors with AMD Secure Startup
|
||||
technology. Implementing AMD support would make a significant impact and
|
||||
broaden the usage of DRTM technologies.
|
||||
|
||||
The initial AEM implementation relied on the [Trusted Boot][tboot_wiki],
|
||||
Intel's reference implementation of Intel TXT. It never had any plans to
|
||||
support AMD processors. TrenchBoot is filling this gap, supporting both Intel
|
||||
and AMD hardware which makes it an ideal target to replace Trusted Boot in
|
||||
Qubes OS AEM implementation. Furthermore, the project grant would be used to
|
||||
implement the missing pieces in the Qubes OS AEM software to cover the AMD and
|
||||
Intel support for both TPM 1.2 and TPM 2.0.
|
||||
|
||||
## Compare your own project with existing or historical efforts
|
||||
|
||||
3mdeb is a licensed provider for quality coreboot consulting services since
|
||||
2016. We are well-known in the open-source community for maintaining the
|
||||
firmware of the PC Engines APU series platform since 2016. Delivering
|
||||
high-quality firmware releases each month and providing technical support on PC
|
||||
Engines and OPNSense forums. 3mdeb embedded systems developers are experienced
|
||||
engineers accustomed to operating systems development. Our developers have
|
||||
contributed to the [fwupd support for Qubes OS][qubes_fwupd]. 3mdeb is also
|
||||
regularly co-organizing mini-conference events with Qubes OS maintainer Marek
|
||||
Marczykowski-Górecki, where various topics related to Qubes OS security are
|
||||
discussed. Among them, the Anti Evil Maid was frequently presented by 3mdeb
|
||||
engineers:
|
||||
|
||||
- [Anti Evil Maid for Intel coreboot-based platform][aem_intel]
|
||||
- [Anti Evil Maid for modern AMD UEFI-based platform][aem_amd]
|
||||
|
||||
A similar approach was already tried by Assured Information Security (AIS) to
|
||||
boot [Xen in UEFI mode with Intel TXT DRTM technology][ais_aem]. However, this
|
||||
is only a tiny portion of the work covered by our proposal. Additionally,
|
||||
Qubes OS does not launch using Xen.efi like in the AIS work but uses
|
||||
[Multiboot2 protocol with GRUB2][qubes_mb2] instead, making this approach
|
||||
unusable. Moreover, the Xen.efi approach is much more complex and assumes usage
|
||||
of Trusted Boot, limiting the feature to Intel hardware only.
|
||||
|
||||
## What are the significant technical challenges you expect to solve
|
||||
|
||||
First of all, Qubes OS AEM software consists of software packages providing
|
||||
Trusted Boot and the [Qubes OS TPM scripts][aem_scripts]. These software
|
||||
packages would need to replace the Trusted Boot with TrenchBoot supported GRUB2
|
||||
and Xen. Secondly, the TPM scripts require adding support for TPM 2.0
|
||||
equivalent functionality. AEM requires access to non-volatile RAM inside TPM,
|
||||
which is defined differently in the TPM 2.0 specification compared to TPM 1.2.
|
||||
|
||||
Another challenge would be to make Xen possible to boot in UEFI boot mode
|
||||
without Boot Services defined in UEFI specification. Boot Services are a set of
|
||||
functions exposed in UEFI structures that are used to help with handling the
|
||||
boot process. However, the main principle of DRTM technologies is to not depend
|
||||
on any external code that is not a part of the operating system software to be
|
||||
executed after DRTM. UEFI Boot Services are a part of the firmware of which
|
||||
DRTM tries to be independent. The whole security concept of DRTM depends on
|
||||
cutting the ties with firmware. Thus the work includes implementing the
|
||||
capability in Xen not to use the UEFI Boot Services, which GRUB2 would
|
||||
terminate before DRTM is executed. Xen also contains an option not to use the
|
||||
UEFI Runtime Services. Runtime Services is a set of functions available
|
||||
throughout the whole machine lifetime, which means some firmware
|
||||
functionalities are available even when the operating system is launched.
|
||||
|
||||
Removing the Boot Services from Xen brings certain drawbacks to the system
|
||||
because the Boot Services hold essential information like memory map, TPM event
|
||||
log, graphics framebuffer, etc. This information must be extracted by GRUB
|
||||
before Boot Services are terminated and passed to the Xen. The proposed
|
||||
solution is to pass this information via the Multiboot2 tags defined in the
|
||||
specification for this particular Boot Services information.
|
||||
|
||||
Another challenge would be to get the work merged in the upstream repositories.
|
||||
It would ensure the long-term support and maintenance of the solution and
|
||||
availability. Providing software packages to be used out of the box is crucial
|
||||
for technology availability.
|
||||
|
||||
## Requested support
|
||||
|
||||
1. Phase 1: TrenchBoot Intel TXT and TPM 1.2 support
|
||||
|
||||
+ Add TPM 1.2 support for Intel TXT in TrenchBoot GRUB2
|
||||
|
||||
The TrenchBoot support hasn't been implemented and verified with TPM
|
||||
1.2 on Intel TXT path. This requirement ensures that the TPM 1.2 is also
|
||||
supported for older Intel hardware with Intel TXT.
|
||||
|
||||
+ Xen Secure Launch - Intel TXT support in Xen for TrenchBoot
|
||||
|
||||
Due to the requirements of Intel TXT and how it is utilized, it is
|
||||
impossible to use the Xen boot protocols defined in the UEFI or
|
||||
Multiboot2 specifications. This task aims to create a custom Intel TXT
|
||||
entry point for Xen, which would hand off to the standard Multiboot2
|
||||
entry point and enable the direct launch of Xen by GRUB via DRTM on
|
||||
Intel hardware. Additionally, there is no support for launching Xen
|
||||
with Intel TXT other than Trusted Boot. It has to be ported from
|
||||
Trusted Boot specific code:
|
||||
|
||||
* constructing MLE header
|
||||
* waking up APs
|
||||
* restoring MTRRs
|
||||
* reserving the TXT memory
|
||||
* reenabling SMIs
|
||||
* handling TXT shutdown and S3 resume/suspend
|
||||
* TPM event log finding
|
||||
|
||||
+ Test the solution on Intel hardware with TPM 1.2 with legacy boot mode
|
||||
|
||||
2. Phase 2 - Qubes OS AEM TPM 2.0 support:
|
||||
|
||||
+ Extend the AEM scripts to detect TPM version on the platform
|
||||
|
||||
As TPM 1.2 and TPM 2.0 use different software stacks and tools, it is
|
||||
necessary to distinguish the TPM module family and use the appropriate
|
||||
software. The task will implement the logic to distinguish the TPM
|
||||
families.
|
||||
|
||||
+ Extend the AEM scripts to use the appropriate software stack for TPM 2.0
|
||||
|
||||
While AEM fully supports TPM 1.2, there is no support for TPM 2.0 at
|
||||
all. When the TPM family is determined, the script should use the
|
||||
appropriate software stack for the given TPM. The task implements the
|
||||
AEM TPM 1.2 equivalent functionalities using TPM 2.0 software stack and
|
||||
as a result allowing the use of TPM 2.0 with Qubes OS AEM. It will
|
||||
require implementing the access to TPM 2.0 NVRAM, sealing and unsealing
|
||||
the secret data, and generating TOTP.
|
||||
|
||||
+ Test the solution on Intel hardware with TPM 2.0 with legacy boot mode
|
||||
|
||||
3. Phase 3 - Qubes OS AEM AMD support:
|
||||
|
||||
+ Rebase and refresh TrenchBoot GRUB2 for QubesOS
|
||||
|
||||
Some work to implement TrenchBoot support for Qubes OS on AMD hardware
|
||||
has been done. GRUB2 with TrenchBoot support has been added to Qubes
|
||||
building system on [3mdeb fork](https://github.com/3mdeb/qubes-grub2/tree/trenchboot_support)
|
||||
The task aims to refresh the work and align with the upstream
|
||||
[Qubes OS GRUB2 repository](https://github.com/QubesOS/qubes-grub2)
|
||||
|
||||
+ Clean up the Secure Kernel Loader (formerly LandingZone) package support
|
||||
for QubesOS
|
||||
|
||||
Since the initial work done by 3mdeb engineers for AMD AEM in Qubes OS,
|
||||
a lot of time has passed, and Secure Kernel Loader - SKL (formerly
|
||||
Landing Zone) has improved a lot and added new features. SKL is an
|
||||
open-source module written by TrenchBoot developers required by AMD
|
||||
Secure Startup technology to perform DRTM launch. The task aims to
|
||||
refresh the previous work and update the SKL package for Qubes OS to
|
||||
the newest revision.
|
||||
|
||||
+ TrenchBoot Secure Kernel Loader (SKL) improvements for AMD server CPUs with
|
||||
multiple nodes
|
||||
|
||||
While SKL was extensively tested on System on Chip and single CPU
|
||||
platforms, it was not tested on workstation/server segment CPUs which
|
||||
are more complex. For example, one server CPU package may contain two
|
||||
independent CPUs inside called nodes. Each node will enable protection
|
||||
on the SKL during DRTM execution, and this protection must be disabled
|
||||
on each node when TrenchBoot DRTM tasks are done. The task implements
|
||||
the correct support for server CPUs in TrenchBoot SKL.
|
||||
|
||||
+ Test the solution on AMD hardware with TPM 2.0 and TPM 1.2 with legacy boot
|
||||
mode
|
||||
|
||||
4. Phase 4 - Xen UEFI boot mode with DRTM:
|
||||
|
||||
+ TrenchBoot support for UEFI boot mode for AMD in GRUB
|
||||
|
||||
While TrenchBoot DRTM was extensively tested on Intel hardware with
|
||||
UEFI firmware and Linux, it was not on AMD platforms. This task ensures
|
||||
that DRTM works with UEFI boot mode on AMD processors in GRUB2 and
|
||||
Linux without UEFI Boot Services.
|
||||
|
||||
+ TrenchBoot support for UEFI boot mode in Xen
|
||||
|
||||
When UEFI boot mode with TrenchBoot is working with GRUB2 and Linux,
|
||||
all that is missing to fully support AMD and Intel hardware with Qubes
|
||||
OS AEM is the Xen support to boot in UEFI mode without Boot Services.
|
||||
This requires a significant amount of work to ensure that all
|
||||
information that Xen would obtain from UEFI Boot Services would still
|
||||
be available. The information has to be passed by GRUB2 to Xen via
|
||||
Multiboot2 protocol:
|
||||
|
||||
* EFI memory map
|
||||
* Framebuffer information
|
||||
* PCI devices information with their option ROMs
|
||||
|
||||
Additionally "EFI boot services not terminated" Multiboot2 tag must not
|
||||
be passed to Xen by GRUB2 on DRTM launch when GRUB2 will terminate Boot
|
||||
Services. Xen should detect such situations and act according to the
|
||||
state of Boot Services. Xen will be implemented to:
|
||||
|
||||
* parse the EFI memory map, framebuffer information, and PCI devices
|
||||
information passed by GRUB2
|
||||
* do not expose the "EFI boot services" Multiboot2 tag indicating that
|
||||
Xen can be executed without UEFI Boot Services presence
|
||||
* allocate the memory space for the trampoline used to launch other
|
||||
processors or use the allocation done by GRUB2 if necessary
|
||||
* do not go error path when Boot Services are not present and skip all
|
||||
calls to UEFI Boot Services by using the information provided by
|
||||
GRUB2
|
||||
|
||||
+ Test the solution on AMD and Intel hardware with TPM 2.0 and TPM 1.2 with
|
||||
legacy and UEFI boot mode
|
||||
|
||||
## Projects or organizations relevant to this project before?
|
||||
|
||||
1. [Qubes OS](https://www.qubes-os.org/)
|
||||
2. [Xen Hypervisor](https://xenproject.org/)
|
||||
3. [GNU GRUB](https://www.gnu.org/software/grub/)
|
||||
4. [TrenchBoot](https://trenchboot.org/)
|
||||
5. [Invisible Things Lab](https://invisiblethingslab.com/)
|
||||
6. [Apertus Solutions](https://apertussolutions.com/)
|
||||
7. [Oracle](https://www.oracle.com/)
|
||||
8. [3mdeb](https://3mdeb.com/)
|
||||
|
||||
## The ecosystem of the project
|
||||
|
||||
3mdeb has a good relationship with the maintainers of relevant projects which
|
||||
will participate in the review of the work:
|
||||
|
||||
- Marek Marczykowski-Górecki (Invisible Things Lab CTO) - Qubes OS maintainer
|
||||
- Andrew Cooper (Citrix) - Xen Hypervisor Maintainer
|
||||
- Daniel Kiper (Oracle) - GRUB2 Maintainer
|
||||
- Daniel Smith (Apertus Solutions) - TrenchBoot founder and maintainer
|
||||
|
||||
## Review
|
||||
|
||||
Further reviews and suggestions are welcome. You can do it in two ways:
|
||||
|
||||
- using Giscus on the bottom of this page
|
||||
- contributing to this repository directly via Pull Request
|
||||
|
||||
[ms_sec_core]: https://docs.microsoft.com/en-us/windows-hardware/design/device-experiences/oem-highly-secure#what-makes-a-secured-core-pc
|
||||
[tb_org]: https://trenchboot.org/
|
||||
[nlnet_open_drtm]: https://nlnet.nl/project/OpenDRTM/
|
||||
[qubes_os_org]: https://www.qubes-os.org/
|
||||
[it_aem]: https://blog.invisiblethings.org/2011/09/07/anti-evil-maid.html
|
||||
[em_attacks]: http://theinvisiblethings.blogspot.com/2009/10/evil-maid-goes-after-truecrypt.html
|
||||
[tboot_wiki]: https://sourceforge.net/p/tboot/wiki/Home/
|
||||
[qubes_fwupd]: https://blog.3mdeb.com/2020/2020-07-14-qubesos-fwupd-core/
|
||||
[aem_intel]: https://www.youtube.com/watch?v=YE2FbFlszI4
|
||||
[aem_amd]: https://www.youtube.com/watch?v=rM0vRi6qABE
|
||||
[ais_aem]: https://www.youtube.com/watch?v=6NScGNSg3ks
|
||||
[qubes_mb2]: https://github.com/QubesOS/qubes-issues/issues/4902
|
||||
[aem_scripts]: https://github.com/QubesOS/qubes-antievilmaid/blob/master/sbin/
|
||||
@@ -1,7 +1,8 @@
|
||||
# muxPi board validation
|
||||
|
||||
> In case of any troubles, first it is recommended to read
|
||||
[comprehend Theory of Operations](theory-of-operations.md) for muxPi devices.
|
||||
[comprehend Theory of Operations](theory-of-operations.md) for muxPi
|
||||
devices.
|
||||
|
||||
## Necessary components preparation
|
||||
|
||||
@@ -19,9 +20,9 @@
|
||||
|
||||
1. Prepare microSD card (minimum 8GB) for NanoPi NEO operating system.
|
||||
1. Download and extract image -
|
||||
[link](https://cloud.3mdeb.com/index.php/s/n42rLcAQ5cWcxgW/download)
|
||||
1. Flash image into microSD card ([Etcher](https://www.balena.io/etcher/) tool
|
||||
could be helpful)
|
||||
[link](https://cloud.3mdeb.com/index.php/s/n42rLcAQ5cWcxgW/download)
|
||||
1. Flash image into microSD card ([Etcher](https://www.balena.io/etcher/)
|
||||
tool could be helpful)
|
||||
|
||||
## muxPi setup
|
||||
|
||||
@@ -32,29 +33,35 @@ could be helpful)
|
||||
1. Plug microUSB<->USB cable to muxPi and your machine.
|
||||
1. Plug in power supply.
|
||||
1. Make sure that jumpers are correctly set according to image:
|
||||
|
||||
|
||||
1. Connect to NanoPi using terminal
|
||||
|
||||
|
||||
sudo minicom -D /dev/ttyUSB0 -o -b 115200`
|
||||
1. Connect to NanoPi using terminal:
|
||||
|
||||
```bash
|
||||
sudo minicom -D /dev/ttyUSB0 -o -b 115200`
|
||||
```
|
||||
|
||||
1. Save ip address:
|
||||
|
||||
ifconfig
|
||||
```bash
|
||||
ifconfig
|
||||
```
|
||||
|
||||
1. Connect to NanoPi via ssh (with password: `fa`):
|
||||
|
||||
```bash
|
||||
ssh root@192.168.4.XXX
|
||||
```
|
||||
```bash
|
||||
ssh root@192.168.4.XXX
|
||||
```
|
||||
|
||||
1. Or via serial connection
|
||||
> NOTE: Connecting with MuxPi through serial will automatically login as non
|
||||
root user `pi` with password `pi`.
|
||||
1. Or via serial connection.
|
||||
|
||||
> NOTE: Connecting with MuxPi through serial will automatically login as
|
||||
non root user `pi` with password `pi`.
|
||||
|
||||
## Validation steps
|
||||
|
||||
#### 1. Install WiringNP
|
||||
### 1. Install WiringNP
|
||||
|
||||
```bash
|
||||
git clone https://github.com/friendlyarm/WiringNP
|
||||
@@ -140,18 +147,19 @@ progress). To flash muxPi's microcontroller, follow steps below:
|
||||
From now on, muxPi's LCD should light on and display:
|
||||
|
||||
```bash
|
||||
* MuxPi *
|
||||
HW: 1.0 SW: 0.5
|
||||
* MuxPi *
|
||||
HW: 1.0 SW: 0.5
|
||||
```
|
||||
|
||||
#### 3. SD Adapter
|
||||
|
||||
1. Connect IDC-uSD adapter to the muxPI board:
|
||||
|
||||
|
||||
2. Insert the microSD card to microSD card slot accessible on the bottom side of
|
||||
|
||||
|
||||
1. Insert the microSD card to microSD card slot accessible on the bottom side of
|
||||
muxPi board.
|
||||
3. To enable microSD card reader, connect to Cortex from MuxPi via minicom:
|
||||
1. To enable microSD card reader, connect to Cortex from MuxPi via minicom:
|
||||
|
||||
```bash
|
||||
minicom -D /dev/ttyS2
|
||||
@@ -169,22 +177,20 @@ HW: 1.0 SW: 0.5
|
||||
dut
|
||||
```
|
||||
|
||||
> NOTE: Each command should return `OK`
|
||||
> NOTE: Each command should return `OK`
|
||||
|
||||
4. Connect IDC-uSD adapter to a SD card adapter plugged into your machine
|
||||
> NOTE: You need to force IDC-uSD adapter to insert into SD card adapter
|
||||
1. Connect IDC-uSD adapter to a SD card adapter plugged into your machine
|
||||
|
||||
5. (On your machine) Check if device is connected: `dmesg -w`
|
||||
> NOTE: You need to force IDC-uSD adapter to insert into SD card adapter
|
||||
|
||||
1. (On your machine) Check if device is connected: `dmesg -w`
|
||||
should help. You should also be able to read and write
|
||||
data to uSD card from file manager.
|
||||
|
||||
6. Flash image into microSD card (for RPI or other device
|
||||
bootable form SD card.)
|
||||
|
||||
7. Disconnect uSD adapter form a SD card adapter and connect
|
||||
1. Flash image into microSD card (for RPI or other device
|
||||
bootable form SD card).
|
||||
1. Disconnect uSD adapter form a SD card adapter and connect
|
||||
to the device (e.g. RPI).
|
||||
|
||||
8. Connect device to the power supply, now device should boot
|
||||
1. Connect device to the power supply, now device should boot
|
||||
via IDC-uSD adapter.
|
||||
|
||||
#### 4. Screening
|
||||
@@ -237,7 +243,8 @@ Minicom quick guide:
|
||||
1. Connect via minicom: `sudo minicom -D /dev/ttyS2 -o -b 115200`
|
||||
1. Type: `help`
|
||||
|
||||
> NOTE: If output is the same as above then basic validation for muxPi is done.
|
||||
> NOTE: If output is the same as above then basic validation for muxPi is
|
||||
done.
|
||||
|
||||
---
|
||||
|
||||
|
||||
@@ -6,7 +6,7 @@
|
||||
|
||||
## muxPi setup
|
||||
|
||||
#### NanoPi NEO
|
||||
### NanoPi NEO
|
||||
|
||||
Preparation of the muxPi's "heart":
|
||||
|
||||
@@ -23,51 +23,50 @@ There are two methods to setup serial communication with muxPi:
|
||||
|
||||
* with microUSB<->USB cable
|
||||
|
||||
|
||||
|
||||
|
||||
* with UART/USB converter
|
||||
|
||||
Attach USB/UART converter to muxPi's left addon female header (`GND`, `DBG UART
|
||||
RX`, `DBG UART TX` on pinout image below):
|
||||
Attach USB/UART converter to muxPi's left addon female header (`GND`,
|
||||
`DBG UART RX`, `DBG UART TX` on pinout image below):
|
||||
|
||||
|
||||
|
||||
|
||||
and plug USB connector to the computer. Next, open connection in PC terminal by
|
||||
typing:
|
||||
and plug USB connector to the computer. Next, open connection in PC
|
||||
terminal by typing:
|
||||
|
||||
```bash
|
||||
sudo minicom -D /dev/ttyUSB0 -o -b 115200.
|
||||
```
|
||||
```bash
|
||||
sudo minicom -D /dev/ttyUSB0 -o -b 115200.
|
||||
```
|
||||
|
||||
> `/dev/ttyUSB0` is example device - check whether `USB0` is the correct one
|
||||
> `/dev/ttyUSB0` is example device - check whether `USB0` is the correct one
|
||||
|
||||
#### Jumpers configuration
|
||||
|
||||
|
||||
|
||||
* UART - pins `Vloc` & `VCC` - if jumped then internal voltage generator is used
|
||||
as voltage reference for data lines and powers up target device. If open then
|
||||
voltage reference for data lines comes from target device and internal voltage
|
||||
generator is unused.
|
||||
* UART - pins `Vloc` & `VCC` - if jumped then internal voltage generator is
|
||||
used as voltage reference for data lines and powers up target device. If
|
||||
open then voltage reference for data lines comes from target device and
|
||||
internal voltage generator is unused.
|
||||
* USB/ETH - determines what USB data lines of one USB HUB are connected to. If
|
||||
first two pins are jumped then USB lines are connected to add-on connector. If
|
||||
last two pins are jumped then these lines are connected tu USB<->ETH converter.
|
||||
If none of the pins are jumped then the only connection is the upper socket of
|
||||
double connector.
|
||||
first two pins are jumped then USB lines are connected to add-on connector.
|
||||
If last two pins are jumped then these lines are connected tu USB<->ETH
|
||||
converter. If none of the pins are jumped then the only connection is the
|
||||
upper socket of double connector.
|
||||
|
||||
> NOTE: The upper socket of double USB-A connector must be left empty if
|
||||
USB<->ETH is selected or add-on connector is selected and something is connected
|
||||
to these data lines on the addon!
|
||||
|
||||
> NOTE: Both jumpers must be placed in the same position!
|
||||
> NOTE: The upper socket of double USB-A connector must be left empty if
|
||||
USB<->ETH is selected or add-on connector is selected and something is
|
||||
connected to these data lines on the addon!
|
||||
> NOTE: Both jumpers must be placed in the same position!
|
||||
|
||||
* VDD - if this pins are jumped then the VDD and 3V3 are always on. If this is
|
||||
left open then VDD and 3V3 are controlled by NanoPi. The usage example is
|
||||
setting value of USB ID potentiometer (which is located underneath NanoPi).
|
||||
But when NanoPi NEO is removed there is no way to turn on power for
|
||||
microcontroller (that is when VDD jumper is helpful).
|
||||
left open then VDD and 3V3 are controlled by NanoPi. The usage example is
|
||||
setting value of USB ID potentiometer (which is located underneath NanoPi).
|
||||
But when NanoPi NEO is removed there is no way to turn on power for
|
||||
microcontroller (that is when VDD jumper is helpful).
|
||||
|
||||
> NOTE: If there is no particular need then leave this jumper open.
|
||||
> NOTE: If there is no particular need then leave this jumper open.
|
||||
|
||||
#### Power supply
|
||||
|
||||
@@ -82,7 +81,7 @@ then 1A assuming no addons connected.
|
||||
To check which IP address has been assigned, type in terminal: `ifconfig`.
|
||||
|
||||
OPTIONAL STEP:
|
||||
To set static IP, create following file:
|
||||
To set static IP, create the following file:
|
||||
|
||||
```bash
|
||||
sudo vi /etc/NetworkManager/NetworkManager.conf
|
||||
@@ -228,7 +227,7 @@ HW: 1.0 SW: 0.5
|
||||
|
||||
> NOTE: It is recommended to cross-compile muxPi's software on your host machine
|
||||
|
||||
#### Building using docker
|
||||
### Building using docker
|
||||
|
||||
Prerequisites: `Docker`, `Make`.
|
||||
|
||||
@@ -247,11 +246,11 @@ Prerequisites: `git`, `go (1.10+)`
|
||||
1. Download dependencies: `go get ./...`
|
||||
1. Build binaries:
|
||||
|
||||
```bash
|
||||
mkdir -p bin
|
||||
GOARCH=arm GOOARM=7 GOOS=linux go build -o bin/stm ./cmd/stm/
|
||||
GOARCH=arm GOOARM=7 GOOS=linux go build -o bin/fota ./cmd/fota/
|
||||
```
|
||||
```bash
|
||||
mkdir -p bin
|
||||
GOARCH=arm GOOARM=7 GOOS=linux go build -o bin/stm ./cmd/stm/
|
||||
GOARCH=arm GOOARM=7 GOOS=linux go build -o bin/fota ./cmd/fota/
|
||||
```
|
||||
|
||||
#### Install muxpi-power
|
||||
|
||||
@@ -264,12 +263,12 @@ GOARCH=arm GOOARM=7 GOOS=linux go build -o bin/fota ./cmd/fota/
|
||||
scp power/systemd/muxpi-power.service root@192.168.4.XXX:/etc/systemd/system
|
||||
```
|
||||
|
||||
2. On your MuxPi device, enable and start muxpi-power service:
|
||||
1. On your MuxPi device, enable and start muxpi-power service:
|
||||
|
||||
```bash
|
||||
systemctl enable muxpi-power.service
|
||||
systemctl start muxpi-power.service
|
||||
```
|
||||
```bash
|
||||
systemctl enable muxpi-power.service
|
||||
systemctl start muxpi-power.service
|
||||
```
|
||||
|
||||
#### Install stm
|
||||
|
||||
@@ -285,14 +284,14 @@ systemctl start muxpi-power.service
|
||||
scp stm/stm root@192.168.4.XXX:/usr/local/bin/stm
|
||||
```
|
||||
|
||||
2. On your MuxPi device - create group stm and add your user:
|
||||
1. On your MuxPi device - create group stm and add your user:
|
||||
|
||||
```bash
|
||||
groupadd stm
|
||||
usermod -aG stm root
|
||||
```
|
||||
|
||||
3. On your MuxPi device - enable stm sockets:
|
||||
1. On your MuxPi device - enable stm sockets:
|
||||
|
||||
```bash
|
||||
systemctl daemon-reload
|
||||
@@ -310,7 +309,7 @@ systemctl start muxpi-power.service
|
||||
scp bin/fota_armv7 root@192.168.4.XXX:/usr/bin/fota
|
||||
```
|
||||
|
||||
2. On your MuxPi device - create a symlink from `/usr/local/bin/fota` to
|
||||
1. On your MuxPi device - create a symlink from `/usr/local/bin/fota` to
|
||||
`/usr/bin/fota/`. Only `/usr/local/bin/fota/` should be used by software
|
||||
interfacing with MuxPi. This allows to swap fota implementation to your
|
||||
preferred tool:
|
||||
@@ -321,7 +320,7 @@ preferred tool:
|
||||
|
||||
## DUT setup
|
||||
|
||||
#### DUT power supply
|
||||
### DUT power supply
|
||||
|
||||
MuxPi is capable of:
|
||||
|
||||
@@ -373,17 +372,16 @@ Example configuration for OrangePi (DUT) uart connection:
|
||||
1. Connect GND, RX and TX (without crossing).
|
||||
1. Open connection: `screen /dev/ttyS1 115200,cs8,ixon,ixoff`
|
||||
|
||||
> NOTE: `RX`, `TX`, `XTS`, `RTS` are crossed on the board so you don't need
|
||||
> NOTE: `RX`, `TX`, `XTS`, `RTS` are crossed on the board so you don't need
|
||||
to cross the wires by yourself.
|
||||
|
||||
> NOTE: A device powered from `Vloc` mustn't draw more than 50mA of current.
|
||||
> NOTE: A device powered from `Vloc` mustn't draw more than 50mA of current.
|
||||
|
||||
#### Add-ons
|
||||
|
||||
Add-ons headers are extensions for attaching new shields or simply using NanoPi
|
||||
and CortexM0 interfaces:
|
||||
|
||||
|
||||
|
||||
|
||||
* `5V` - power supply - not switchable - always present
|
||||
* `3V3` - switchable (controlled by NanoPi) 3.3V power supply
|
||||
@@ -411,10 +409,10 @@ and CortexM0 interfaces:
|
||||
dealing with them.
|
||||
* `GND` - ground lines
|
||||
|
||||
NOTE: PI GPIO 1 has additional special function. It is connected to Cortex-M0
|
||||
Boot0 pin which enables firmware download mode during microcontroller boot. 1 -
|
||||
enables this mode while 0 disables it. So it is useless as GPIO when the
|
||||
microcontroller is being booted.
|
||||
>NOTE: PI GPIO 1 has additional special function. It is connected to Cortex-M0
|
||||
Boot0 pin which enables firmware download mode during microcontroller boot.
|
||||
1 - enables this mode while 0 disables it. So it is useless as GPIO when
|
||||
the microcontroller is being booted.
|
||||
|
||||
#### DyPers
|
||||
|
||||
@@ -470,7 +468,7 @@ and enter in minicom following commands:
|
||||
ts
|
||||
```
|
||||
|
||||
and then
|
||||
and then:
|
||||
|
||||
```bash
|
||||
dut
|
||||
@@ -485,7 +483,7 @@ card contains appropriate OS.
|
||||
|
||||
## Interacting with muxPi
|
||||
|
||||
#### Connection with NanoPi
|
||||
### Connection with NanoPi
|
||||
|
||||
User can simply open SSH connection by (password: `fa`):
|
||||
|
||||
@@ -494,7 +492,7 @@ User can simply open SSH connection by (password: `fa`):
|
||||
* or use serial connection mentioned [here](#serial-communication)
|
||||
|
||||
> NOTE: Connecting with MuxPi through serial will automatically login as non
|
||||
root user `pi` with password `pi`.
|
||||
root user `pi` with password `pi`.
|
||||
|
||||
#### User interface
|
||||
|
||||
|
||||
@@ -44,12 +44,12 @@ Full Remote Testing Environment set includes:
|
||||
> _test your device from any location._
|
||||
|
||||
* efficiency
|
||||
> *simplify validation: write one script and run it on unlimited platforms.
|
||||
Don’t repeat yourself!*
|
||||
> _simplify validation: write one script and run it on unlimited platforms.
|
||||
Don’t repeat yourself!_
|
||||
|
||||
* independent development
|
||||
> *open hardware license: modify, upgrade and set it as you like. All blueprints
|
||||
are at your disposal.*
|
||||
> _open hardware license: modify, upgrade and set it as you like. All blueprints
|
||||
are at your disposal._
|
||||
|
||||
* instant setup
|
||||
> _intuitive connection: you do not need to be a certified engineer._
|
||||
|
||||
@@ -2,9 +2,10 @@
|
||||
|
||||
|
||||
|
||||
* **UART0 header** - 1x3 Orange Pi Zero system debug output and console (pins: `RX`, `TX`, `GND`).
|
||||
* **SPI header** - 2x4 standard 2.5mm IDC compatible header with all necessary signals to flash SPI
|
||||
chips.
|
||||
* **UART0 header** - 1x3 Orange Pi Zero system debug output and console
|
||||
(pins: `RX`, `TX`, `GND`).
|
||||
* **SPI header** - 2x4 standard 2.5mm IDC compatible header with all necessary
|
||||
signals to flash SPI chips.
|
||||
* **Orange Pi Zero GPIO** - 1x3 GPIO pin header directly connected to Orange Pi
|
||||
zero platform.
|
||||
* **I2C header** - 1x4 populated pins: `3.3V`, `SCK`, `SDA`, `GND`.
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
SDWire is a small board with two features:
|
||||
# SDWire is a small board with two features
|
||||
|
||||
* SD card reader
|
||||
* SD card MUX
|
||||
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user