|
1 | 1 | # Secure Boot Objects
|
2 | 2 |
|
3 |
| -This repository is used to hold the secure boot objects recommended by |
4 |
| -Microsoft to use as the default KEK, DB, and DBX variables. This repository |
5 |
| -utilizes a script (`scripts/secure_boot_default_keys.py`) to generate the |
6 |
| -binary blobs based off of the `FirmwareDefaults.toml` configuration file. |
| 3 | +This repository is used to hold the secure boot objects recommended by Microsoft. |
7 | 4 |
|
8 |
| -On a release github release, the script is run and the generated binaries are |
9 |
| -bundled, zipped, and attached to the release so that they can be consumed by |
10 |
| -platforms. |
| 5 | +For documentation visit our [Wiki](https://github.com/microsoft/secureboot_objects/wiki)! |
11 | 6 |
|
12 | 7 | ## Versioning
|
13 | 8 |
|
@@ -46,105 +41,6 @@ this repository, it enables developers to easily review the contents and make
|
46 | 41 | changes as needed. This also enables an easy way for the KeK, Db, and (mainly)
|
47 | 42 | the Dbx to be updated transparently and then consumed by any platform!
|
48 | 43 |
|
49 |
| -## Platform Consumption |
50 |
| - |
51 |
| -The secure boot binary objects are formatted to the expected EDKII data |
52 |
| -structures to enable simple integration into an EDKII platform. Please refer to |
53 |
| -[SecureBootKeyStoreLib](https://github.com/microsoft/mu_plus/tree/HEAD/MsCorePkg/Library/BaseSecureBootKeyStoreLib) |
54 |
| -to see one example on how to easily integrate these binaries into your |
55 |
| -platform. The EDKII build system even supports easily appending to the default |
56 |
| -values suggested by Microsoft! |
57 |
| - |
58 |
| -This is just one suggested way of consuming the binary objects. There are of |
59 |
| -course plenty of others, such as storing them as a Freeform Ffs file in an |
60 |
| -FV. |
61 |
| - |
62 |
| -## secure_boot_default_keys.py |
63 |
| - |
64 |
| -This script ingests a configuration file and generates binary blobs for each |
65 |
| -table specified in the configuration file. |
66 |
| - |
67 |
| -``` cmd |
68 |
| -usage: secure_boot_default_keys.py [-h] --keystore KEYSTORE [-o OUTPUT] |
69 |
| -
|
70 |
| -Build the default keys for secure boot. |
71 |
| -
|
72 |
| -options: |
73 |
| - -h, --help show this help message and exit |
74 |
| - --keystore KEYSTORE A json file containing the keys mapped to certificates and |
75 |
| - hashes. |
76 |
| - -o OUTPUT, --output OUTPUT |
77 |
| - The output directory for the default keys. |
78 |
| -``` |
79 |
| - |
80 |
| -## Configuration File |
81 |
| - |
82 |
| -A configuration file must be provided to the script to generate the binary |
83 |
| -information. The script generates a binary blob for each table entry in the |
84 |
| -toml file (a table is each `[]` in the toml file) and for each supported |
85 |
| -architecture (Currently Ia32, X64, Arm, Aarch64). We also generate a readme for |
86 |
| -eacharchitecture to provide information about the files inside each binary blob |
87 |
| - |
88 |
| -That is to say, if you define a toml file similar to this: |
89 |
| - |
90 |
| -```toml |
91 |
| -[MyCustomPk] |
92 |
| - |
93 |
| -[MyCustomKek] |
94 |
| - |
95 |
| -[MyCustomDb] |
96 |
| - |
97 |
| -[MyCustomDbx] |
98 |
| -``` |
99 |
| - |
100 |
| -Binary blobs will be created with the following folder structure: |
101 |
| - |
102 |
| -``` cmd |
103 |
| -Artifacts |
104 |
| -├── Aarch64 |
105 |
| -│ ├── MyCustomPk.bin |
106 |
| -│ ├── MyCustomKek.bin |
107 |
| -│ ├── MyCustomDb.bin |
108 |
| -│ ├── MyCustomDbx.bin |
109 |
| -│ └── README.md |
110 |
| -├── Arm |
111 |
| -│ ├── MyCustomPk.bin |
112 |
| -│ ├── MyCustomKek.bin |
113 |
| -│ ├── MyCustomDb.bin |
114 |
| -│ ├── MyCustomDbx.bin |
115 |
| -│ └── README.md |
116 |
| -├── Ia32 |
117 |
| -│ ├── MyCustomPk.bin |
118 |
| -│ ├── MyCustomKek.bin |
119 |
| -│ ├── MyCustomDb.bin |
120 |
| -│ ├── MyCustomDbx.bin |
121 |
| -│ └── README.md |
122 |
| -└── X64 |
123 |
| - ├── MyCustomPk.bin |
124 |
| - ├── MyCustomKek.bin |
125 |
| - ├── MyCustomDb.bin |
126 |
| - ├── MyCustomDbx.bin |
127 |
| - └── README.md |
128 |
| -``` |
129 |
| - |
130 |
| -For each table in the toml file, the script supports the following entries: |
131 |
| - |
132 |
| -1. `help (Optional<str>)`: A short blob of information to be added to the |
133 |
| - readme for that table entry. |
134 |
| -2. `arch (Optional<str>)`: The architecture (Intel, ARM) the blob should be |
135 |
| - generated for. Defaults to all. |
136 |
| -3. `file (list<File>)`: A list of files to include in the binary blob (.crt, |
137 |
| - .csv). This has additional config described below |
138 |
| -4. `signature_owner (Optional<str>)`: The GUID of the signature owner. |
139 |
| - |
140 |
| -For each file in the toml file, the script supports the following entries: |
141 |
| - |
142 |
| -1. `path (str)`: The local path to the file to include in the binary |
143 |
| -2. `url (Optional<str>)`: The url to where the file was downloaded from. |
144 |
| - Included in the readme if provided |
145 |
| -3. `sha1 (Optional<str>)`: The sha1 hash of the file. Included in the readme |
146 |
| - if provided. |
147 |
| - |
148 | 44 | ## Code of Conduct
|
149 | 45 |
|
150 | 46 | This project has adopted the [Microsoft Open Source Code of Conduct](https://opensource.microsoft.com/codeofconduct/).
|
|
0 commit comments