├── .github └── workflows │ ├── gh-pages.yml │ ├── lazy-lint.bash │ ├── markdownlint.yml │ └── vale.yml ├── .gitignore ├── .mdl_style.rb ├── .mdlrc ├── .vale.ini ├── CNAME ├── LICENSE ├── Makefile ├── README.md ├── book.toml ├── ci └── vale │ └── styles │ └── config │ └── vocabularies │ └── LinuxBoot │ └── accept.txt ├── po ├── messages.pot └── zh-TW.po ├── src ├── SUMMARY.md ├── case_studies │ ├── Ampere_study.md │ ├── Google_study.md │ ├── TiogaPass.md │ ├── index.md │ └── linux_config ├── components.md ├── coreboot.u-root.systemboot │ ├── index.md │ └── linux-4.19.6-linuxboot.config ├── faq.md ├── glossary.md ├── history.md ├── images │ ├── Case-study-Ampere.svg │ ├── Case-study-step1.svg │ ├── Case-study-step1a.svg │ ├── Case-study-step1b.svg │ ├── Case-study-step2.svg │ ├── Case-study-step3.svg │ ├── Case-study-step4.svg │ ├── Case-study-step5.svg │ ├── Case-study-step6.svg │ ├── LinuxBoot-components.svg │ ├── UEFI-versus-LinuxBoot.svg │ ├── cpu_first_step.svg │ ├── cpu_overview.svg │ ├── cpu_second_step.svg │ ├── cpu_startup.svg │ └── cpu_third_step.svg ├── implementation.md ├── intro.md ├── odroid.md ├── openpower.md ├── petitboot.md ├── talks-news.md ├── tools-evaluation.md ├── u-root-qemu-demo.md ├── u-root.md ├── use-cases.md └── utilities │ ├── UEFI_Tool_Kit.md │ ├── cpu.md │ ├── dut.md │ └── index.md └── theme ├── css └── language-picker.css ├── head.hbs └── js └── language-picker.js /.github/workflows/gh-pages.yml: -------------------------------------------------------------------------------- 1 | name: github pages 2 | 3 | on: 4 | push: 5 | branches: 6 | - main 7 | pull_request: 8 | 9 | env: 10 | # Update the language picker in theme/js/language-picker.js to link new languages. 11 | LANGUAGES: zh-TW 12 | 13 | jobs: 14 | deploy: 15 | runs-on: ubuntu-24.04 16 | concurrency: 17 | group: ${{ github.workflow }}-${{ github.ref }} 18 | steps: 19 | - name: Checkout 20 | uses: actions/checkout@v4 21 | 22 | - name: Setup mdBook 23 | # https://github.com/jontze/action-mdbook 24 | uses: jontze/action-mdbook@v4 25 | with: 26 | token: ${{ secrets.GITHUB_TOKEN }} 27 | # mdbook-version: 'latest' 28 | mdbook-version: "0.4.48" 29 | use-mermaid: true 30 | mermaid-version: "0.15.0" 31 | use-linkcheck: true 32 | linkcheck-version: "0.7.7" 33 | 34 | - name: Install mdbook-mermaid 35 | run: mdbook-mermaid install 36 | 37 | - name: Install mdbook-i18n-helpers 38 | run: | 39 | cargo install mdbook-i18n-helpers --locked --version 0.3.4 40 | 41 | - name: Build 42 | # linkcheck causes ouput files to end up in html/, so move them to root 43 | run: | 44 | mdbook build 45 | mv book/html/* book/ 46 | 47 | - name: Build all translations 48 | run: | 49 | for po_lang in ${{ env.LANGUAGES }}; do 50 | echo "::group::Building $po_lang translation" 51 | MDBOOK_BOOK__LANGUAGE=$po_lang \ 52 | MDBOOK_OUTPUT__HTML__SITE_URL=/linuxboot-book/$po_lang/ \ 53 | mdbook build -d book/$po_lang 54 | rsync -a book/$po_lang/html/ book/$po_lang/ 55 | rm -r book/$po_lang/html/ 56 | echo "::endgroup::" 57 | done 58 | 59 | - name: Deploy 60 | uses: peaceiris/actions-gh-pages@v3 61 | if: ${{ github.ref == 'refs/heads/main' }} 62 | with: 63 | github_token: ${{ secrets.GITHUB_TOKEN }} 64 | publish_dir: ./book 65 | -------------------------------------------------------------------------------- /.github/workflows/lazy-lint.bash: -------------------------------------------------------------------------------- 1 | #!/usr/bin/env bash 2 | 3 | declare -A shame_list 4 | shame_list=( 5 | [./src/case_studies/TiogaPass.md]=1 6 | [./src/components.md]=1 7 | [./src/coreboot.u-root.systemboot/index.md]=1 8 | [./src/implementation.md]=1 9 | [./src/intro.md]=1 10 | [./src/naming.md]=1 11 | [./src/SUMMARY.md]=1 12 | [./src/u-root.md]=1 13 | [./src/utilities/dut.md]=1 14 | [./src/utilities/UEFI_Tool_Kit.md]=1 15 | ) 16 | 17 | ll_rv=0 18 | for md_file in $(find . -name "*.md"); do 19 | if [[ "${shame_list[$md_file]}" ]]; then 20 | echo -e "\\e[93mSkipping ${md_file}\\e[0m" 21 | else 22 | echo "$ mdl ${md_file}" 23 | mdl ${md_file} 24 | 25 | mdl_rv="$?" 26 | if [[ "${mdl_rv}" -ne 0 ]]; then 27 | ll_rv="${mdl_rv}" 28 | fi 29 | fi 30 | done 31 | exit ${ll_rv} 32 | -------------------------------------------------------------------------------- /.github/workflows/markdownlint.yml: -------------------------------------------------------------------------------- 1 | name: Markdown Lint Action 2 | on: push 3 | 4 | jobs: 5 | build: 6 | name: Markdown Lint 7 | runs-on: ubuntu-latest 8 | steps: 9 | - name: Checkout 10 | uses: actions/checkout@v4 11 | 12 | - name: Install markdown lint 13 | run: sudo gem install mdl 14 | 15 | - name: Lint markdown 16 | run: .github/workflows/lazy-lint.bash 17 | -------------------------------------------------------------------------------- /.github/workflows/vale.yml: -------------------------------------------------------------------------------- 1 | name: Vale Action 2 | on: push 3 | 4 | jobs: 5 | build: 6 | name: Vale 7 | runs-on: ubuntu-latest 8 | steps: 9 | - name: Checkout 10 | uses: actions/checkout@v4 11 | 12 | - name: Install vale 13 | run: sudo snap install vale 14 | 15 | - name: Lint prose 16 | run: | 17 | vale sync 18 | vale src/intro.md 19 | vale src/openpower.md 20 | -------------------------------------------------------------------------------- /.gitignore: -------------------------------------------------------------------------------- 1 | book 2 | ci/vale/styles/alex/ 3 | ci/vale/styles/Google/ 4 | ci/vale/styles/Joblint/ 5 | ci/vale/styles/Microsoft/ 6 | ci/vale/styles/proselint/ 7 | ci/vale/styles/RedHat/ 8 | ci/vale/styles/write-good/ 9 | mermaid*.js 10 | -------------------------------------------------------------------------------- /.mdl_style.rb: -------------------------------------------------------------------------------- 1 | all 2 | # Ignore line length in code blocks and tables 3 | rule 'MD013', :ignore_code_blocks => true, :tables => false 4 | # Allow inline HTML 5 | exclude_rule 'MD033' 6 | # Order ordered lists 7 | rule 'MD029', :style => :ordered 8 | -------------------------------------------------------------------------------- /.mdlrc: -------------------------------------------------------------------------------- 1 | style '.mdl_style.rb' 2 | -------------------------------------------------------------------------------- /.vale.ini: -------------------------------------------------------------------------------- 1 | StylesPath = ci/vale/styles 2 | 3 | MinAlertLevel = error 4 | 5 | Vocab = LinuxBoot 6 | 7 | Packages = RedHat, proselint, alex, Joblint, write-good 8 | 9 | [*.{md}] 10 | BasedOnStyles = Vale, RedHat, proselint, alex, Joblint, write-good 11 | -------------------------------------------------------------------------------- /CNAME: -------------------------------------------------------------------------------- 1 | book.linuxboot.org -------------------------------------------------------------------------------- /LICENSE: -------------------------------------------------------------------------------- 1 | Attribution-ShareAlike 4.0 International 2 | 3 | ======================================================================= 4 | 5 | Creative Commons Corporation ("Creative Commons") is not a law firm and 6 | does not provide legal services or legal advice. Distribution of 7 | Creative Commons public licenses does not create a lawyer-client or 8 | other relationship. Creative Commons makes its licenses and related 9 | information available on an "as-is" basis. Creative Commons gives no 10 | warranties regarding its licenses, any material licensed under their 11 | terms and conditions, or any related information. Creative Commons 12 | disclaims all liability for damages resulting from their use to the 13 | fullest extent possible. 14 | 15 | Using Creative Commons Public Licenses 16 | 17 | Creative Commons public licenses provide a standard set of terms and 18 | conditions that creators and other rights holders may use to share 19 | original works of authorship and other material subject to copyright 20 | and certain other rights specified in the public license below. The 21 | following considerations are for informational purposes only, are not 22 | exhaustive, and do not form part of our licenses. 23 | 24 | Considerations for licensors: Our public licenses are 25 | intended for use by those authorized to give the public 26 | permission to use material in ways otherwise restricted by 27 | copyright and certain other rights. Our licenses are 28 | irrevocable. Licensors should read and understand the terms 29 | and conditions of the license they choose before applying it. 30 | Licensors should also secure all rights necessary before 31 | applying our licenses so that the public can reuse the 32 | material as expected. Licensors should clearly mark any 33 | material not subject to the license. This includes other CC- 34 | licensed material, or material used under an exception or 35 | limitation to copyright. More considerations for licensors: 36 | wiki.creativecommons.org/Considerations_for_licensors 37 | 38 | Considerations for the public: By using one of our public 39 | licenses, a licensor grants the public permission to use the 40 | licensed material under specified terms and conditions. If 41 | the licensor's permission is not necessary for any reason--for 42 | example, because of any applicable exception or limitation to 43 | copyright--then that use is not regulated by the license. Our 44 | licenses grant only permissions under copyright and certain 45 | other rights that a licensor has authority to grant. Use of 46 | the licensed material may still be restricted for other 47 | reasons, including because others have copyright or other 48 | rights in the material. A licensor may make special requests, 49 | such as asking that all changes be marked or described. 50 | Although not required by our licenses, you are encouraged to 51 | respect those requests where reasonable. More_considerations 52 | for the public: 53 | wiki.creativecommons.org/Considerations_for_licensees 54 | 55 | ======================================================================= 56 | 57 | Creative Commons Attribution-ShareAlike 4.0 International Public 58 | License 59 | 60 | By exercising the Licensed Rights (defined below), You accept and agree 61 | to be bound by the terms and conditions of this Creative Commons 62 | Attribution-ShareAlike 4.0 International Public License ("Public 63 | License"). To the extent this Public License may be interpreted as a 64 | contract, You are granted the Licensed Rights in consideration of Your 65 | acceptance of these terms and conditions, and the Licensor grants You 66 | such rights in consideration of benefits the Licensor receives from 67 | making the Licensed Material available under these terms and 68 | conditions. 69 | 70 | 71 | Section 1 -- Definitions. 72 | 73 | a. Adapted Material means material subject to Copyright and Similar 74 | Rights that is derived from or based upon the Licensed Material 75 | and in which the Licensed Material is translated, altered, 76 | arranged, transformed, or otherwise modified in a manner requiring 77 | permission under the Copyright and Similar Rights held by the 78 | Licensor. For purposes of this Public License, where the Licensed 79 | Material is a musical work, performance, or sound recording, 80 | Adapted Material is always produced where the Licensed Material is 81 | synched in timed relation with a moving image. 82 | 83 | b. Adapter's License means the license You apply to Your Copyright 84 | and Similar Rights in Your contributions to Adapted Material in 85 | accordance with the terms and conditions of this Public License. 86 | 87 | c. BY-SA Compatible License means a license listed at 88 | creativecommons.org/compatiblelicenses, approved by Creative 89 | Commons as essentially the equivalent of this Public License. 90 | 91 | d. Copyright and Similar Rights means copyright and/or similar rights 92 | closely related to copyright including, without limitation, 93 | performance, broadcast, sound recording, and Sui Generis Database 94 | Rights, without regard to how the rights are labeled or 95 | categorized. For purposes of this Public License, the rights 96 | specified in Section 2(b)(1)-(2) are not Copyright and Similar 97 | Rights. 98 | 99 | e. Effective Technological Measures means those measures that, in the 100 | absence of proper authority, may not be circumvented under laws 101 | fulfilling obligations under Article 11 of the WIPO Copyright 102 | Treaty adopted on December 20, 1996, and/or similar international 103 | agreements. 104 | 105 | f. Exceptions and Limitations means fair use, fair dealing, and/or 106 | any other exception or limitation to Copyright and Similar Rights 107 | that applies to Your use of the Licensed Material. 108 | 109 | g. License Elements means the license attributes listed in the name 110 | of a Creative Commons Public License. The License Elements of this 111 | Public License are Attribution and ShareAlike. 112 | 113 | h. Licensed Material means the artistic or literary work, database, 114 | or other material to which the Licensor applied this Public 115 | License. 116 | 117 | i. Licensed Rights means the rights granted to You subject to the 118 | terms and conditions of this Public License, which are limited to 119 | all Copyright and Similar Rights that apply to Your use of the 120 | Licensed Material and that the Licensor has authority to license. 121 | 122 | j. Licensor means the individual(s) or entity(ies) granting rights 123 | under this Public License. 124 | 125 | k. Share means to provide material to the public by any means or 126 | process that requires permission under the Licensed Rights, such 127 | as reproduction, public display, public performance, distribution, 128 | dissemination, communication, or importation, and to make material 129 | available to the public including in ways that members of the 130 | public may access the material from a place and at a time 131 | individually chosen by them. 132 | 133 | l. Sui Generis Database Rights means rights other than copyright 134 | resulting from Directive 96/9/EC of the European Parliament and of 135 | the Council of 11 March 1996 on the legal protection of databases, 136 | as amended and/or succeeded, as well as other essentially 137 | equivalent rights anywhere in the world. 138 | 139 | m. You means the individual or entity exercising the Licensed Rights 140 | under this Public License. Your has a corresponding meaning. 141 | 142 | 143 | Section 2 -- Scope. 144 | 145 | a. License grant. 146 | 147 | 1. Subject to the terms and conditions of this Public License, 148 | the Licensor hereby grants You a worldwide, royalty-free, 149 | non-sublicensable, non-exclusive, irrevocable license to 150 | exercise the Licensed Rights in the Licensed Material to: 151 | 152 | a. reproduce and Share the Licensed Material, in whole or 153 | in part; and 154 | 155 | b. produce, reproduce, and Share Adapted Material. 156 | 157 | 2. Exceptions and Limitations. For the avoidance of doubt, where 158 | Exceptions and Limitations apply to Your use, this Public 159 | License does not apply, and You do not need to comply with 160 | its terms and conditions. 161 | 162 | 3. Term. The term of this Public License is specified in Section 163 | 6(a). 164 | 165 | 4. Media and formats; technical modifications allowed. The 166 | Licensor authorizes You to exercise the Licensed Rights in 167 | all media and formats whether now known or hereafter created, 168 | and to make technical modifications necessary to do so. The 169 | Licensor waives and/or agrees not to assert any right or 170 | authority to forbid You from making technical modifications 171 | necessary to exercise the Licensed Rights, including 172 | technical modifications necessary to circumvent Effective 173 | Technological Measures. For purposes of this Public License, 174 | simply making modifications authorized by this Section 2(a) 175 | (4) never produces Adapted Material. 176 | 177 | 5. Downstream recipients. 178 | 179 | a. Offer from the Licensor -- Licensed Material. Every 180 | recipient of the Licensed Material automatically 181 | receives an offer from the Licensor to exercise the 182 | Licensed Rights under the terms and conditions of this 183 | Public License. 184 | 185 | b. Additional offer from the Licensor -- Adapted Material. 186 | Every recipient of Adapted Material from You 187 | automatically receives an offer from the Licensor to 188 | exercise the Licensed Rights in the Adapted Material 189 | under the conditions of the Adapter's License You apply. 190 | 191 | c. No downstream restrictions. You may not offer or impose 192 | any additional or different terms or conditions on, or 193 | apply any Effective Technological Measures to, the 194 | Licensed Material if doing so restricts exercise of the 195 | Licensed Rights by any recipient of the Licensed 196 | Material. 197 | 198 | 6. No endorsement. Nothing in this Public License constitutes or 199 | may be construed as permission to assert or imply that You 200 | are, or that Your use of the Licensed Material is, connected 201 | with, or sponsored, endorsed, or granted official status by, 202 | the Licensor or others designated to receive attribution as 203 | provided in Section 3(a)(1)(A)(i). 204 | 205 | b. Other rights. 206 | 207 | 1. Moral rights, such as the right of integrity, are not 208 | licensed under this Public License, nor are publicity, 209 | privacy, and/or other similar personality rights; however, to 210 | the extent possible, the Licensor waives and/or agrees not to 211 | assert any such rights held by the Licensor to the limited 212 | extent necessary to allow You to exercise the Licensed 213 | Rights, but not otherwise. 214 | 215 | 2. Patent and trademark rights are not licensed under this 216 | Public License. 217 | 218 | 3. To the extent possible, the Licensor waives any right to 219 | collect royalties from You for the exercise of the Licensed 220 | Rights, whether directly or through a collecting society 221 | under any voluntary or waivable statutory or compulsory 222 | licensing scheme. In all other cases the Licensor expressly 223 | reserves any right to collect such royalties. 224 | 225 | 226 | Section 3 -- License Conditions. 227 | 228 | Your exercise of the Licensed Rights is expressly made subject to the 229 | following conditions. 230 | 231 | a. Attribution. 232 | 233 | 1. If You Share the Licensed Material (including in modified 234 | form), You must: 235 | 236 | a. retain the following if it is supplied by the Licensor 237 | with the Licensed Material: 238 | 239 | i. identification of the creator(s) of the Licensed 240 | Material and any others designated to receive 241 | attribution, in any reasonable manner requested by 242 | the Licensor (including by pseudonym if 243 | designated); 244 | 245 | ii. a copyright notice; 246 | 247 | iii. a notice that refers to this Public License; 248 | 249 | iv. a notice that refers to the disclaimer of 250 | warranties; 251 | 252 | v. a URI or hyperlink to the Licensed Material to the 253 | extent reasonably practicable; 254 | 255 | b. indicate if You modified the Licensed Material and 256 | retain an indication of any previous modifications; and 257 | 258 | c. indicate the Licensed Material is licensed under this 259 | Public License, and include the text of, or the URI or 260 | hyperlink to, this Public License. 261 | 262 | 2. You may satisfy the conditions in Section 3(a)(1) in any 263 | reasonable manner based on the medium, means, and context in 264 | which You Share the Licensed Material. For example, it may be 265 | reasonable to satisfy the conditions by providing a URI or 266 | hyperlink to a resource that includes the required 267 | information. 268 | 269 | 3. If requested by the Licensor, You must remove any of the 270 | information required by Section 3(a)(1)(A) to the extent 271 | reasonably practicable. 272 | 273 | b. ShareAlike. 274 | 275 | In addition to the conditions in Section 3(a), if You Share 276 | Adapted Material You produce, the following conditions also apply. 277 | 278 | 1. The Adapter's License You apply must be a Creative Commons 279 | license with the same License Elements, this version or 280 | later, or a BY-SA Compatible License. 281 | 282 | 2. You must include the text of, or the URI or hyperlink to, the 283 | Adapter's License You apply. You may satisfy this condition 284 | in any reasonable manner based on the medium, means, and 285 | context in which You Share Adapted Material. 286 | 287 | 3. You may not offer or impose any additional or different terms 288 | or conditions on, or apply any Effective Technological 289 | Measures to, Adapted Material that restrict exercise of the 290 | rights granted under the Adapter's License You apply. 291 | 292 | 293 | Section 4 -- Sui Generis Database Rights. 294 | 295 | Where the Licensed Rights include Sui Generis Database Rights that 296 | apply to Your use of the Licensed Material: 297 | 298 | a. for the avoidance of doubt, Section 2(a)(1) grants You the right 299 | to extract, reuse, reproduce, and Share all or a substantial 300 | portion of the contents of the database; 301 | 302 | b. if You include all or a substantial portion of the database 303 | contents in a database in which You have Sui Generis Database 304 | Rights, then the database in which You have Sui Generis Database 305 | Rights (but not its individual contents) is Adapted Material, 306 | 307 | including for purposes of Section 3(b); and 308 | c. You must comply with the conditions in Section 3(a) if You Share 309 | all or a substantial portion of the contents of the database. 310 | 311 | For the avoidance of doubt, this Section 4 supplements and does not 312 | replace Your obligations under this Public License where the Licensed 313 | Rights include other Copyright and Similar Rights. 314 | 315 | 316 | Section 5 -- Disclaimer of Warranties and Limitation of Liability. 317 | 318 | a. UNLESS OTHERWISE SEPARATELY UNDERTAKEN BY THE LICENSOR, TO THE 319 | EXTENT POSSIBLE, THE LICENSOR OFFERS THE LICENSED MATERIAL AS-IS 320 | AND AS-AVAILABLE, AND MAKES NO REPRESENTATIONS OR WARRANTIES OF 321 | ANY KIND CONCERNING THE LICENSED MATERIAL, WHETHER EXPRESS, 322 | IMPLIED, STATUTORY, OR OTHER. THIS INCLUDES, WITHOUT LIMITATION, 323 | WARRANTIES OF TITLE, MERCHANTABILITY, FITNESS FOR A PARTICULAR 324 | PURPOSE, NON-INFRINGEMENT, ABSENCE OF LATENT OR OTHER DEFECTS, 325 | ACCURACY, OR THE PRESENCE OR ABSENCE OF ERRORS, WHETHER OR NOT 326 | KNOWN OR DISCOVERABLE. WHERE DISCLAIMERS OF WARRANTIES ARE NOT 327 | ALLOWED IN FULL OR IN PART, THIS DISCLAIMER MAY NOT APPLY TO YOU. 328 | 329 | b. TO THE EXTENT POSSIBLE, IN NO EVENT WILL THE LICENSOR BE LIABLE 330 | TO YOU ON ANY LEGAL THEORY (INCLUDING, WITHOUT LIMITATION, 331 | NEGLIGENCE) OR OTHERWISE FOR ANY DIRECT, SPECIAL, INDIRECT, 332 | INCIDENTAL, CONSEQUENTIAL, PUNITIVE, EXEMPLARY, OR OTHER LOSSES, 333 | COSTS, EXPENSES, OR DAMAGES ARISING OUT OF THIS PUBLIC LICENSE OR 334 | USE OF THE LICENSED MATERIAL, EVEN IF THE LICENSOR HAS BEEN 335 | ADVISED OF THE POSSIBILITY OF SUCH LOSSES, COSTS, EXPENSES, OR 336 | DAMAGES. WHERE A LIMITATION OF LIABILITY IS NOT ALLOWED IN FULL OR 337 | IN PART, THIS LIMITATION MAY NOT APPLY TO YOU. 338 | 339 | c. The disclaimer of warranties and limitation of liability provided 340 | above shall be interpreted in a manner that, to the extent 341 | possible, most closely approximates an absolute disclaimer and 342 | waiver of all liability. 343 | 344 | 345 | Section 6 -- Term and Termination. 346 | 347 | a. This Public License applies for the term of the Copyright and 348 | Similar Rights licensed here. However, if You fail to comply with 349 | this Public License, then Your rights under this Public License 350 | terminate automatically. 351 | 352 | b. Where Your right to use the Licensed Material has terminated under 353 | Section 6(a), it reinstates: 354 | 355 | 1. automatically as of the date the violation is cured, provided 356 | it is cured within 30 days of Your discovery of the 357 | violation; or 358 | 359 | 2. upon express reinstatement by the Licensor. 360 | 361 | For the avoidance of doubt, this Section 6(b) does not affect any 362 | right the Licensor may have to seek remedies for Your violations 363 | of this Public License. 364 | 365 | c. For the avoidance of doubt, the Licensor may also offer the 366 | Licensed Material under separate terms or conditions or stop 367 | distributing the Licensed Material at any time; however, doing so 368 | will not terminate this Public License. 369 | 370 | d. Sections 1, 5, 6, 7, and 8 survive termination of this Public 371 | License. 372 | 373 | 374 | Section 7 -- Other Terms and Conditions. 375 | 376 | a. The Licensor shall not be bound by any additional or different 377 | terms or conditions communicated by You unless expressly agreed. 378 | 379 | b. Any arrangements, understandings, or agreements regarding the 380 | Licensed Material not stated herein are separate from and 381 | independent of the terms and conditions of this Public License. 382 | 383 | 384 | Section 8 -- Interpretation. 385 | 386 | a. For the avoidance of doubt, this Public License does not, and 387 | shall not be interpreted to, reduce, limit, restrict, or impose 388 | conditions on any use of the Licensed Material that could lawfully 389 | be made without permission under this Public License. 390 | 391 | b. To the extent possible, if any provision of this Public License is 392 | deemed unenforceable, it shall be automatically reformed to the 393 | minimum extent necessary to make it enforceable. If the provision 394 | cannot be reformed, it shall be severed from this Public License 395 | without affecting the enforceability of the remaining terms and 396 | conditions. 397 | 398 | c. No term or condition of this Public License will be waived and no 399 | failure to comply consented to unless expressly agreed to by the 400 | Licensor. 401 | 402 | d. Nothing in this Public License constitutes or may be interpreted 403 | as a limitation upon, or waiver of, any privileges and immunities 404 | that apply to the Licensor or You, including from the legal 405 | processes of any jurisdiction or authority. 406 | 407 | 408 | ======================================================================= 409 | 410 | Creative Commons is not a party to its public 411 | licenses. Notwithstanding, Creative Commons may elect to apply one of 412 | its public licenses to material it publishes and in those instances 413 | will be considered the “Licensor.” The text of the Creative Commons 414 | public licenses is dedicated to the public domain under the CC0 Public 415 | Domain Dedication. Except for the limited purpose of indicating that 416 | material is shared under a Creative Commons public license or as 417 | otherwise permitted by the Creative Commons policies published at 418 | creativecommons.org/policies, Creative Commons does not authorize the 419 | use of the trademark "Creative Commons" or any other trademark or logo 420 | of Creative Commons without its prior written consent including, 421 | without limitation, in connection with any unauthorized modifications 422 | to any of its public licenses or any other arrangements, 423 | understandings, or agreements concerning use of licensed material. For 424 | the avoidance of doubt, this paragraph does not form part of the 425 | public licenses. 426 | 427 | Creative Commons may be contacted at creativecommons.org. 428 | -------------------------------------------------------------------------------- /Makefile: -------------------------------------------------------------------------------- 1 | build: 2 | mdbook build 3 | 4 | run: 5 | mdbook serve 6 | 7 | prepare: 8 | cargo install mdbook 9 | cargo install mdbook-mermaid 10 | mdbook-mermaid install 11 | cargo install mdbook-linkcheck 12 | -------------------------------------------------------------------------------- /README.md: -------------------------------------------------------------------------------- 1 | # The LinuxBoot Book 2 | 3 | LinuxBoot is a project that aims to replace specific firmware functionality with 4 | a Linux kernel and runtime. Over the years this project has grown to include 5 | various initiatives with the overarching goal of moving from obscure, complex 6 | firmware to simpler, open source firmware. 7 | 8 | This is the official site of documentation for the LinuxBoot project. The book 9 | provides guidance on how to get started, and gives overviews and 10 | background on the different aspects of LinuxBoot. 11 | 12 | ## Contributing 13 | 14 | This book is written with [mdBook](https://github.com/rust-lang/mdBook). 15 | When installed, run `mdbook serve` and you will get a local webserver. 16 | For more details, please refer to the mdBook documentation. 17 | 18 | Some pages render diagrams using [mermaid.js](https://mermaid.js.org/), which is 19 | preprocessed with [mdbook-mermaid](https://github.com/badboy/mdbook-mermaid). 20 | 21 | To check that all links are still available, [mdbook-linkcheck]( 22 | https://github.com/Michael-F-Bryan/mdbook-linkcheck) also runs in CI. 23 | 24 | For convenience, the `Makefile` lets you set up and run the environment: 25 | 26 | ```sh 27 | make prepare 28 | make run 29 | ``` 30 | 31 | The book is linted with markdownlint and Vale. Follow the official 32 | documentation to [install 33 | markdownlint](https://github.com/markdownlint/markdownlint?tab=readme-ov-file#installation) 34 | and [install Vale](https://vale.sh/docs/install). Then run `vale sync` to 35 | download the necessary styles. 36 | 37 | From the root directory of the repository run `mdl /src/example.md` and `vale 38 | src/example.md`. Add words that trigger false positive spelling errors to 39 | `ci/vale/styles/config/vocabularies/LinuxBoot/accept.txt`. 40 | 41 | ## Acknowledgments 42 | 43 | In alphabetical order: 44 | 45 | * [Andrea Barberio](https://github.com/insomniacslk) 46 | * [Gan Shun Lim](https://github.com/ganshun) 47 | * [Johnny Lin](https://github.com/johnnylinwiwynn) 48 | * [Jonathan Zhang](https://github.com/jonzhang-fb) 49 | * [Philipp Deppenwiese](https://github.com/zaolin) 50 | * [Prachi Laud](https://github.com/pallaud) 51 | * [Ronald Minnich](https://github.com/rminnich) 52 | * [Ryan O'Leary](https://github.com/rjoleary) 53 | -------------------------------------------------------------------------------- /book.toml: -------------------------------------------------------------------------------- 1 | [book] 2 | authors = ["LinuxBoot authors"] 3 | src = "src" 4 | title = "LinuxBoot" 5 | 6 | [output.html] 7 | cname = "book.linuxboot.org" 8 | git-repository-url = "https://github.com/linuxboot/book" 9 | additional-css = [ 10 | "theme/css/language-picker.css", 11 | ] 12 | additional-js = [ 13 | "mermaid.min.js", 14 | "mermaid-init.js", 15 | "theme/js/language-picker.js", 16 | ] 17 | 18 | [build] 19 | extra-watch-dirs = ["po"] 20 | 21 | [output.linkcheck] 22 | 23 | [preprocessor] 24 | 25 | [preprocessor.mermaid] 26 | command = "mdbook-mermaid" 27 | 28 | [preprocessor.gettext] 29 | after = ["links"] 30 | -------------------------------------------------------------------------------- /ci/vale/styles/config/vocabularies/LinuxBoot/accept.txt: -------------------------------------------------------------------------------- 1 | initramfs 2 | coreboot 3 | Monolake 4 | Winterfell 5 | Tioga 6 | nmbl 7 | kboot 8 | Almesberger 9 | petitboot 10 | skiboot 11 | skiroot 12 | hostboot 13 | -------------------------------------------------------------------------------- /src/SUMMARY.md: -------------------------------------------------------------------------------- 1 | - [LinuxBoot Introduction](intro.md) 2 | - [Use cases](use-cases.md) 3 | - [Talks and news coverage](talks-news.md) 4 | - [LinuxBoot Components](components.md) 5 | - [Evaluation of tools](tools-evaluation.md) 6 | - [Petitboot](petitboot.md) 7 | - [OpenPOWER](openpower.md) 8 | - [ODROID](odroid.md) 9 | - [All about u-root](u-root.md) 10 | - [u-root demo with QEMU](u-root-qemu-demo.md) 11 | - [LinuxBoot utilities](utilities/index.md) 12 | - [UEFI Tool Kit](utilities/UEFI_Tool_Kit.md) 13 | - [The magical cpu command](utilities/cpu.md) 14 | - [Device Under Test](utilities/dut.md) 15 | - [Implementing LinuxBoot](implementation.md) 16 | - [LinuxBoot using coreboot, u-root and systemboot](coreboot.u-root.systemboot/index.md) 17 | - [Glossary](glossary.md) 18 | - [History](history.md) 19 | - [Case Studies](case_studies/index.md) 20 | - [Ampere study](case_studies/Ampere_study.md) 21 | - [Google study](case_studies/Google_study.md) 22 | - [OCP TiogaPass](case_studies/TiogaPass.md) 23 | - [Frequently Asked Questions](faq.md) 24 | -------------------------------------------------------------------------------- /src/case_studies/Ampere_study.md: -------------------------------------------------------------------------------- 1 | # LinuxBoot on Ampere Mt. Jade Platform 2 | 3 | The Ampere Altra Family processor based Mt. Jade platform is a high-performance 4 | ARM server platform, offering up to 256 processor cores in a dual socket 5 | configuration. The Tianocore EDK2 firmware for the Mt. Jade platform has been 6 | fully upstreamed to the tianocore/edk2-platforms repository, enabling the 7 | community to build and experiment with the platform's firmware using entirely 8 | open-source code. It also supports LinuxBoot, an open-source firmware framework 9 | that reduces boot time, enhances security, and increases flexibility compared 10 | to standard UEFI firmware. 11 | 12 | Mt. Jade has also achieved a significant milestone by becoming [the first 13 | server certified under the Arm SystemReady LS certification 14 | program](https://community.arm.com/arm-community-blogs/b/architectures-and-processors-blog/posts/arm-systemready-ls). 15 | SystemReady LS ensures compliance with standardized boot and runtime 16 | environments for Linux-based systems, enabling seamless deployment across 17 | diverse hardware. This certification further emphasizes Mt. Jade's readiness 18 | for enterprise and cloud-scale adoption by providing assurance of 19 | compatibility, performance, and reliability. 20 | 21 | This case study explores the LinuxBoot implementation on the Ampere Mt. Jade 22 | platform, inspired by the approach used in [Google's LinuxBoot 23 | deployment](Google_study.md). 24 | 25 | ## Ampere EDK2-LinuxBoot Components 26 | 27 | The Mt. Jade platform embraces a hybrid firmware architecture, combining 28 | UEFI/EDK2 for hardware initialization and LinuxBoot for advanced boot 29 | functionalities. The platform aligns closely with step 6 in the LinuxBoot 30 | adoption model. 31 | 32 | 33 | 34 | The entire boot firmware stack for the Mt. Jade is open source and available in 35 | the Github. 36 | 37 | * **EDK2**: The PEI and minimal (stripped-down) DXE drivers, including both 38 | common and platform code, are fully open source and resides in Tianocore 39 | edk2-platforms and edk2 repositories. 40 | * **LinuxBoot**: The LinuxBoot binary ([flashkernel](../glossary.md)) for Mt. 41 | Jade is supported in the 42 | [linuxboot/linuxboot](https://github.com/linuxboot/linuxboot/tree/main/mainboards/ampere/jade) 43 | repository. 44 | 45 | ## Ampere Solution for LinuxBoot as a Boot Device Selection 46 | 47 | Ampere has implemented and successfully upstreamed a solution for integrating 48 | LinuxBoot as a Boot Device Selection (BDS) option into the TianoCore EDK2 49 | framework, as seen in commit 50 | [ArmPkg: Implement PlatformBootManagerLib for 51 | LinuxBoot](https://github.com/tianocore/edk2/commit/62540372230ecb5318a9c8a40580a14beeb9ded0). 52 | This innovation simplifies the boot process for the Mt. Jade platform and 53 | aligns with LinuxBoot's goals of efficiency and flexibility. 54 | 55 | Unlike the earlier practice that replaced the UEFI Shell with a LinuxBoot 56 | flashkernel, Ampere's solution introduces a custom BDS implementation that 57 | directly boots into the LinuxBoot environment as the active boot option. This 58 | approach bypasses the need to load the UEFI Shell or UiApp (UEFI Setup Menu), 59 | which depend on numerous unnecessary DXE drivers. 60 | 61 | To further enhance flexibility, Ampere introduced a new GUID specifically for 62 | the LinuxBoot binary, ensuring clear separation from the UEFI Shell GUID. This 63 | distinction allows precise identification of LinuxBoot components in the 64 | firmware. 65 | 66 | ## Build Process 67 | 68 | Building a flashable EDK2 firmware image with an integrated LinuxBoot 69 | flashkernel for the Ampere Mt. Jade platform involves two main steps: building 70 | the LinuxBoot flashkernel and integrating it into the EDK2 firmware build. 71 | 72 | ### Step 1: Build the LinuxBoot Flashkernel 73 | 74 | The LinuxBoot flash kernel is built as follows: 75 | 76 | ```bash 77 | git clone https://github.com/linuxboot/linuxboot.git 78 | cd linuxboot/mainboards/ampere/jade && make fetch flashkernel 79 | ``` 80 | 81 | After the build process completes, the flash kernel will be located at: 82 | linuxboot/mainboards/ampere/jade/flashkernel 83 | 84 | ### Step 2: Build the EDK2 Firmware Image with the Flash Kernel 85 | 86 | The EDK2 firmware image is built with the LinuxBoot flashkernel integrated into 87 | the flash image using the following steps: 88 | 89 | ```bash 90 | git clone https://github.com/tianocore/edk2-platforms.git 91 | git clone https://github.com/tianocore/edk2.git 92 | git clone https://github.com/tianocore/edk2-non-osi.git 93 | ./edk2-platforms/Platform/Ampere/buildfw.sh -b RELEASE -t GCC -p Jade -l linuxboot/mainboards/ampere/jade/flashkernel 94 | ``` 95 | 96 | The `buildfw.sh` script automatically integrates the LinuxBoot flash kernel 97 | (provided via the -l option) as part of the final EDK2 firmware image. 98 | 99 | This process generates a flashable EDK2 firmware image with embedded LinuxBoot, 100 | ready for deployment on the Ampere Mt. Jade platform. 101 | 102 | ## Booting with LinuxBoot 103 | 104 | When powered on, the system will boot into the u-root and automatically kexec 105 | to the target OS. 106 | 107 | ```text 108 | Run /init as init process 109 | 1970/01/01 00:00:10 Welcome to u-root! 110 | _ 111 | _ _ _ __ ___ ___ | |_ 112 | | | | |____| '__/ _ \ / _ \| __| 113 | | |_| |____| | | (_) | (_) | |_ 114 | \__,_| |_| \___/ \___/ \__| 115 | 116 | cgroup: Unknown subsys name 'perf_event' 117 | init: 1970/01/01 00:00:10 Deprecation warning: use UROOT_NOHWRNG=1 on kernel cmdline instead of uroot.nohwrng 118 | 1970/01/01 00:00:10 Booting from the following block devices: [BlockDevice(name=nvme0n1, fs_uuid=) BlockDevice(name=nvme0n1p1, fs_uuid=d6c6-6306) BlockDevice(name=nvme0n1p2, fs_uuid=63402158-6266-48fb-b602-5f83f26bd0b9) BlockDevice(name=nvme0n1p3, fs_uuid=) BlockDevice(name=nvme1n1, fs_uuid=) BlockDevice(name=nvme1n1p1, fs_uuid=525c-92fb)] 119 | 1970/01/01 00:00:10 [grub] Got config file file:///tmp/u-root-mounts3457412855/nvme0n1p1/EFI/ubuntu/grub.cfg: 120 | search.fs_uuid 63402158-6266-48fb-b602-5f83f26bd0b9 root 121 | set prefix=($root)'/grub' 122 | configfile $prefix/grub.cfg 123 | 124 | 1970/01/01 00:00:10 Warning: Grub parser could not parse ["search" "--fs-uuid" "63402158-6266-48fb-b602-5f83f26bd0b9" "root"] 125 | 1970/01/01 00:00:10 [grub] Got config file file:///tmp/u-root-mounts3457412855/nvme0n1p2/grub/grub.cfg 126 | 1970/01/01 00:00:10 Error: Expected 1 device with UUID "1334d6c5-c16f-46ba-9120-5127ae43bf63", found 0 127 | 1970/01/01 00:00:10 Error: Expected 1 device with UUID "1334d6c5-c16f-46ba-9120-5127ae43bf63", found 0 128 | 129 | 130 | Welcome to LinuxBoot's Menu 131 | 132 | Enter a number to boot a kernel: 133 | 134 | 1. Ubuntu 135 | 136 | 2. Ubuntu, with Linux 6.8.0-49-generic 137 | 138 | 3. Ubuntu, with Linux 6.8.0-49-generic (recovery mode) 139 | 140 | 4. Ubuntu, with Linux 6.8.0-48-generic 141 | 142 | 5. Ubuntu, with Linux 6.8.0-48-generic (recovery mode) 143 | 144 | 6. Reboot 145 | 146 | 7. Enter a LinuxBoot shell 147 | 148 | 149 | Enter an option ('01' is the default, 'e' to edit kernel cmdline): 150 | > 07 151 | 152 | > dmidecode -t 4 153 | # dmidecode-go 154 | Reading SMBIOS/DMI data from sysfs. 155 | SMBIOS 3.3.0 present. 156 | 157 | Handle 0x0003, DMI type 4, 51 bytes 158 | Processor Information 159 | Socket Designation: CPU01 160 | Type: Central Processor 161 | Family: ARMv8 162 | Manufacturer: Ampere(R) 163 | ID: 01 00 16 0A A1 00 00 00 164 | Signature: Implementor 0x0a, Variant 0x1, Architecture 6, Part 0x000, Revision 1 165 | Version: Ampere(R) Altra(R) Processor 166 | Voltage: 1.0 V 167 | External Clock: 25 MHz 168 | Max Speed: 3000 MHz 169 | Current Speed: 3000 MHz 170 | Status: Populated, Enabled 171 | Upgrade: Unknown 172 | L1 Cache Handle: 0x0001 173 | L2 Cache Handle: 0x0002 174 | L3 Cache Handle: Not Provided 175 | Serial Number: 000000000000000002550904033865B4 176 | Asset Tag: Not Set 177 | Part Number: Q80-30 178 | Core Count: 80 179 | Core Enabled: 80 180 | Thread Count: 80 181 | Characteristics: 182 | 64-bit capable 183 | Multi-Core 184 | Execute Protection 185 | Enhanced Virtualization 186 | Power/Performance Control 187 | 188 | Handle 0x0007, DMI type 4, 51 bytes 189 | Processor Information 190 | Socket Designation: CPU02 191 | Type: Central Processor 192 | Family: ARMv8 193 | Manufacturer: Ampere(R) 194 | ID: 01 00 16 0A A1 00 00 00 195 | Signature: Implementor 0x0a, Variant 0x1, Architecture 6, Part 0x000, Revision 1 196 | Version: Ampere(R) Altra(R) Processor 197 | Voltage: 1.0 V 198 | External Clock: 25 MHz 199 | Max Speed: 3000 MHz 200 | Current Speed: 3000 MHz 201 | Status: Populated, Enabled 202 | Upgrade: Unknown 203 | L1 Cache Handle: 0x0005 204 | L2 Cache Handle: 0x0006 205 | L3 Cache Handle: Not Provided 206 | Serial Number: 000000000000000002560909033865B4 207 | Asset Tag: Not Set 208 | Part Number: Q80-30 209 | Core Count: 80 210 | Core Enabled: 80 211 | Thread Count: 80 212 | Characteristics: 213 | 64-bit capable 214 | Multi-Core 215 | Execute Protection 216 | Enhanced Virtualization 217 | Power/Performance Control 218 | 219 | > 220 | M-? toggle key help • C-d erase/stop • C-c clear/cancel • C-r search hist … 221 | ``` 222 | 223 | ## Future Work 224 | 225 | While the LinuxBoot implementation on the Ampere Mt. Jade platform represents a 226 | significant milestone, several advanced features and improvements remain to be 227 | explored. These enhancements would extend the platform's capabilities, improve 228 | its usability, and reinforce its position as a leading open source firmware 229 | solution. Key areas for future development include: 230 | 231 | ### Secure Boot with LinuxBoot 232 | 233 | One of the critical areas for future development is enabling secure boot 234 | verification for the target operating system. In the LinuxBoot environment, the 235 | target OS is typically booted using kexec. However, it is unclear how Secure 236 | Boot operates in this context, as kexec bypasses traditional 237 | firmware-controlled secure boot mechanisms. Future work should investigate how 238 | to extend Secure Boot principles to kexec, ensuring that the OS kernel and its 239 | components are verified and authenticated before execution. This may involve 240 | implementing signature checks and utilizing trusted certificate chains directly 241 | within the LinuxBoot environment to mimic the functionality of UEFI Secure Boot 242 | during the kexec process. 243 | 244 | ### TPM Support 245 | 246 | The platform supports TPM, but its integration with LinuxBoot is yet to be 247 | defined. Future work could explore utilizing the TPM for secure boot 248 | measurements, and system integrity attestation. 249 | 250 | ### Expanding Support for Additional Ampere Platforms 251 | 252 | Building on the success of LinuxBoot on Mt. Jade, future efforts should expand 253 | support to other Ampere platforms. This would ensure broader adoption and 254 | usability across different hardware configurations. 255 | 256 | ### Optimizing the Transition Between UEFI and LinuxBoot 257 | 258 | Improving the efficiency of the handoff between UEFI and LinuxBoot could 259 | further reduce boot times. This optimization would involve refining the 260 | initialization process and minimizing redundant operations during the handoff. 261 | 262 | ### Advanced Diagnostics and Monitoring Tools 263 | 264 | Adding more diagnostic and monitoring tools to the LinuxBoot u-root environment 265 | would enhance debugging and system management. These tools could provide 266 | deeper insights into system performance and potential issues, improving 267 | reliability and maintainability. 268 | 269 | ## See Also 270 | 271 | * [LinuxBoot on Ampere Platforms: A new (old) approach to 272 | firmware](https://amperecomputing.com/blogs/linuxboot-on-ampere-platforms--a-new-old-approach-to-firmware) 273 | -------------------------------------------------------------------------------- /src/case_studies/Google_study.md: -------------------------------------------------------------------------------- 1 | # The LinuxBoot project at Google 2 | 3 | Google runs workloads across a number of clusters each with up to tens of 4 | thousands of machines. Firmware runs on these machines when they first start 5 | up. Google is pushing the state-of-the-art in many places including firmware. 6 | The discussion here about Google's implementation of LinuxBoot is limited to 7 | replacing specific UEFI [firmware](../glossary.md) 8 | functionality with a Linux kernel and runtime. Over the years this project 9 | has grown to include various initiatives with the overarching goal of moving 10 | from obscure, complex firmware to simpler, open source firmware. 11 | 12 | ## Team 13 | 14 | There have been a number of contributors to the Google LinuxBoot project 15 | including: 16 | 17 | - Ron Minnich (technical lead) 18 | - Gan-shun Lim 19 | - Ryan O'Leary 20 | - Prachi Laud 21 | - Chris Koch 22 | - Xuan Chen 23 | - Andrew Sun 24 | 25 | Ryan O'Leary is one of the Open Compute Platform Foundation 26 | [Open System Firmware project](https://www.opencompute.org/projects/open-system-firmware) 27 | volunteer leads and Ron Minnich is the Open Compute Platform Foundation 28 | Incubation Committee Representative. 29 | 30 | ## Goal 31 | 32 | The primary goal of Google's LinuxBoot is to modernize the firmware by 33 | simplifying it to technologies engineers understand and trust. 34 | In UEFI systems, LinuxBoot consists of a "full stack" solution 35 | of stripped-down UEFI firmware, a Linux kernel, and an initramfs with 36 | tools written in Go. Although these components all make up one bundle 37 | stored in ROM, there are three parts: the closed-source EFI firmware, 38 | a Linux kernel, and [u-root](../u-root.md). The Linux kernel is 39 | an unmodified kernel. The user-space initramfs image with Go tools 40 | for system booting is available as u-root. Due to this modularity, 41 | LinuxBoot can be used with a variety of systems. In many cases, 42 | for example, the same kernel and initramfs have been used, without 43 | recompilation, on both AMD and Intel x86 boards. The UEFI on 44 | these boards is always specific to the board, however. 45 | 46 | ## Converting a UEFI firmware image to use LinuxBoot 47 | 48 | The conversion to LinuxBoot starts with generic UEFI. A UEFI computer 49 | boots in four main phases. The security phase (SEC) and the Pre-EFI 50 | Initialization Stage (PEI) are responsible for low-level operations 51 | to prepare the hardware and are usually specific to the hardware 52 | they are implemented for. After these two stages, the Driver Execution 53 | Environment (DXE) loads various drivers, and then the Boot Device Select 54 | (BDS) phase begins. 55 | 56 | It is not possible to modify the SEC and PEI stages, as their 57 | components are tightly coupled to the chips on the board; even 58 | small changes to the chips require new SEC and PEI stages. 59 | LinuxBoot starts during the DXE stage, resulting in most of the drivers 60 | (and their associated attack surface) not being loaded. 61 | Instead, a Linux kernel is loaded as if it were a driver. 62 | By loading during the DXE, LinuxBoot runs after the first two stages 63 | of the UEFI, but takes over after that point, replacing the 64 | UEFI drivers. It therefore completely replaces a large portion 65 | of the boot process. 66 | 67 | ## Phases of the project 68 | 69 | Google's LinuxBoot project is focused on moving UEFI boot functionality 70 | into the kernel and user-space. That is, converting UEFI firmware 71 | to run LinuxBoot. The project has taken the standard UEFI boot process 72 | and converted it to LinuxBoot for production environments. 73 | The steps to reach this goal are described below. 74 | 75 | Step 1. Reduce or replace UEFI components 76 | 77 | UEFI contains proprietary, closed-source, vendor-supplied firmware 78 | drivers and firmware. LinuxBoot replaces many Driver Execution 79 | Environment (DXE) modules used by UEFI and other firmware, 80 | particularly the network stack and file system modules, with 81 | Linux applications. 82 | 83 | The following diagram shows the phases of the UEFI boot process. 84 | The items in red are components 85 | that are either reduced or eliminated with LinuxBoot. 86 | The dark blue items on the left 87 | cannot be changed. 88 | 89 | 90 | 91 | In the real FLASH part, the SEC and PEI are actually only 10% of total, 92 | so we reduce the size of those boxes in this and following diagrams. 93 | 94 | 95 | 96 | Another part of the conversion process was to modify the UEFI boot 97 | process to boot a LinuxBoot image as shown below. 98 | 99 | 100 | 101 | Step 2. Delete or replace as many proprietary DXEs as required to make 102 | step 3 work. In most cases, none need to be removed. 103 | 104 | 105 | 106 | Step 3. Replace the UEFI shell with a Linux kernel + u-root 107 | 108 | 109 | 110 | When Linux boots it needs a root file system with utilities. 111 | LinuxBoot provides a file system based on u-root standard 112 | utilities written in Go. 113 | 114 | Step 4. Through trial and error, continue to remove DXEs until you 115 | can't remove anymore. 116 | 117 | The DXEs are delivered as binary blobs. There are three ways 118 | to handle them: 119 | 120 | 1. The most desirable is to remove them and let Linux drivers take 121 | over what they did. This works well for USB, network, disk, 122 | and other drivers, as well as network protocols and file 123 | systems. In fact we have resolved many system reliability 124 | and performance issues just by removing DXEs! 125 | 2. The second way is to replace the DXE with an open source driver. 126 | This is less desirable, as the DXE environment is not as 127 | hardened as the Linux kernel environment. 128 | 3. The final, least desired option, is to continue to use the DXE. 129 | This is required if the DXE contains proprietary code that 130 | "tweaks" chipset settings, for example, memory timing or 131 | other controls, and there is no chance of ever bringing 132 | them to open source. 133 | 134 | 135 | 136 | Step 5. Replace closed source DXEs with open source 137 | 138 | If we can build a DXE from source, we can use `utk` to: 139 | 140 | - Remove the proprietary one 141 | - Replace it with one built from source 142 | 143 | 144 | 145 | Step 6. Next steps: complete LinuxBoot 146 | 147 | LinuxBoot is currently in production, but the LinuxBoot project 148 | development continues to provide an open-source solution that 149 | does the following: 150 | 151 | 1. Brings up the Linux kernel as a DXE in flash ROM instead of the UEFI shell. 152 | 2. Provides a Go based user-space that can then bring up the kernel that you 153 | want to run on the machine. 154 | 3. Enables writing traditional firmware applications such as bootloader, 155 | debugging, diagnosis, and error detection applications as cross-architecture 156 | and cross-platform portable Linux applications. 157 | 158 | The complete LinuxBoot solution is shown in the following diagram. 159 | 160 | 161 | -------------------------------------------------------------------------------- /src/case_studies/TiogaPass.md: -------------------------------------------------------------------------------- 1 | # OCP TiogaPass Case Study 2 | 3 | Points of contact: 4 | [Jonathan Zhang](https://github.com/jonzhang-fb), 5 | [Andrea Barberio](https://github.com/insomniacslk), 6 | [David Hendricks](https://github.com/dhendrix), 7 | [Adi](https://github.com/agangidi53), 8 | [Morgan Jang](https://github.com/morganjangwiwynn), 9 | [Johnny Lin](https://github.com/johnnylinwiwynn) 10 | 11 | This case study describes information for firmware development community to use 12 | [OCP](https://www.opencompute.org/) platform TiogaPass, made by [Wiwynn 13 | Corporation](http://www.wiwynn.com/english). 14 | 15 | It contains following sections: 16 | 17 | * [Quick Start](#Quick-Start) 18 | * [Details](#Details) 19 | * [How to build](#How-to-build) 20 | * [How to operate](#How-to-operate) 21 | * [Platform info](#Platform-info) 22 | * [Support](#Support) 23 | * [Hardware support](#Hardware-support) 24 | * [Community support](#Community-support) 25 | * [Professional support](#Professional-support) 26 | 27 | ## Quick Start 28 | 29 | * [Order the hardware](http://www.wiwynn.com/english) if you have not done so. 30 | * Download or build the firmware binary. The current solution is to boot 31 | embedded Linux kernel and initramfs as UEFI payload. Please contact Wiwynn to 32 | get a UEFI binary after ordering. 33 | * Flash the firmware. 34 | * Copy the downloaded firmware to OpenBMC. 35 | * From OpenBMC 36 | ``` 37 | fw-util mb --update bios --force ./ 38 | ``` 39 | * Boot and enjoy. 40 | * From OpenBMC 41 | ``` 42 | power-util mb reset 43 | sol-util mb 44 | ``` 45 | 46 | ## Details 47 | 48 | ### How to build 49 | 50 | Follow [Build Details](#Build-Details) for details on how to get the source 51 | code, and how to build. 52 | 53 | Boot flow of the current firmware solution is: Power on → minimized UEFI → 54 | LinuxBoot → target OS. 55 | 56 | In near feature, the boot flow will be: power on → Coreboot → LinuxBoot → 57 | target OS. 58 | 59 | #### Build Details 60 | 61 | * Download the code from [linuxboot github](https://github.com/linuxboot/linuxboot) 62 | ``` 63 | git clone https://github.com/linuxboot/linuxboot.git 64 | ``` 65 | * You need to apply Wiwiynn's linuxboot patch for now 66 | ``` 67 | cd linuxboot 68 | wget -O TiogaPass.patch https://github.com/johnnylinwiwynn/linuxboot/commit/28ae8450b3b05c6e6b8c74e29d0974ccf711d5e6.patch 69 | git am TiogaPass.patch 70 | ``` 71 | * Build the kernel bzImage (has embedded initramfs) for linuxboot, please 72 | reference [Building u-root](https://github.com/linuxboot/book/tree/master/coreboot.u-root.systemboot#building-u-root) 73 | and [Building a suitable Linux kernel](https://github.com/linuxboot/book/tree/master/coreboot.u-root.systemboot#building-a-suitable-linux-kernel) 74 | for how to build the bzImage. You can always customize your Linux kernel 75 | configuration to suit your needs, please reference Wiwynn's kernel 76 | configuration file as a sample [linux_config](linux_config). 77 | * Place the tioga.rom into linuxboot/boards/tioga which is provided from Wiwynn 78 | after ordering, and also put your bzImage to the root folder of linuxboot, 79 | and then make 80 | ``` 81 | cp path/to/tioga.rom linuxboot/boards/tioga 82 | cp path/to/bzImage linuxboot 83 | cd linuxboot 84 | BOARD=tioga make 85 | ``` 86 | * You should see the built image at build/tioga/linuxboot.rom. 87 | 88 | ### How to operate 89 | 90 | Follow **TBD section** for details on: 91 | 92 | * How to flash. The image can be flashed either out-of-band, or from LinuxBoot 93 | u-root shell, or from targetOS shell. 94 | * How to run LinuxBoot u-root shell commands. 95 | 96 | ### Platform info 97 | 98 | The SKU contains TiogaPass board, a debug card, a VGA card, a power adapter. 99 | The details can be obtained from the [Wiwynn Corporation](http://www.wiwynn.com/english). 100 | 101 | Platform design details (including the design spec and schematics) can be found 102 | on the [Open Compute Project UfiSpace product 103 | page](https://www.opencompute.org/products/108/wiwynn-tioga-pass-standard-sv7220g3-s-2u-ocp-server-up-to-768gb-8gb16gb32gb-ddr4-up-to-2666mts-12-dimm-slots). 104 | 105 | ## Support 106 | 107 | ### Hardware support 108 | 109 | Hardware support can be obtained from [Wiwynn Corporation](http://www.wiwynn.com/english). 110 | 111 | ### Community support 112 | 113 | [OCP Open System Firmware](https://www.opencompute.org/projects/open-system-firmware) 114 | is where industry collaborates on how to move forward with OSF. The OCP OSF 115 | project has regular recorded meetings and a mailing list. 116 | 117 | [LinuxBoot open source community](https://www.linuxboot.org/) is the community 118 | you can ask any technical questions. LinuxBoot community has a slack channel, a 119 | IRC channel, a mailing list and regular meetings. 120 | 121 | ### Professional support 122 | 123 | Following companies provides professional support services: 124 | 125 | ** TBD ** 126 | -------------------------------------------------------------------------------- /src/case_studies/index.md: -------------------------------------------------------------------------------- 1 | # Case Studies 2 | 3 | This chapter contains case studies for various solutions. 4 | 5 | ## Table of Contents 6 | 7 | 1. [Ampere study](Ampere_study.md) 8 | 2. [Google study](Google_study.md) 9 | 3. [OCP TiogaPass](TiogaPass.md) 10 | -------------------------------------------------------------------------------- /src/components.md: -------------------------------------------------------------------------------- 1 | ## LinuxBoot Components 2 | 3 | ![image](./images/LinuxBoot-components.svg) 4 | 5 | LinuxBoot consists of the following components: 6 | 7 | 1. BIOS 8 | 2. Linux kernel 9 | 3. u-root -> initramfs 10 | 11 | 12 | #### BIOS 13 | 14 | This does not have to be a specific BIOS; currently LinuxBoot supports UEFI 15 | and [coreboot](https://coreboot.org/). 16 | 17 | 18 | #### Linux kernel 19 | 20 | LinuxBoot is not intended to be a runtime production kernel; rather, it 21 | is meant to replace specific UEFI functionality using Linux kernel capabilities 22 | and then boot the actual production kernel on the machine. Kernel 23 | configuration files specific to LinuxBoot provide the needed Linux kernel 24 | capabilities without bloating the size of the BIOS with unnecessary drivers. 25 | 26 | These config files disable options that are not needed in the LinuxBoot 27 | kernel and add some patches that are needed. 28 | 29 | 30 | #### Initial RAM filesystem (initramfs) 31 | 32 | When Linux boots it needs a root file system that provides boot and startup 33 | utilities. LinuxBoot uses [u-root](./glossary.md) to create an 34 | initramfs for this purpose. 35 | 36 | 37 | #### What is an initramfs? 38 | 39 | The initramfs is a root file system that is embedded within the firmware 40 | image itself. It is intended to be placed in a flash device along with the 41 | Linux kernel as part of the firmware image for LinuxBoot. The initramfs is 42 | essentially a set of directories bundled into a single cpio archive. 43 | 44 | At boot time, the boot loader or firmware (for example, coreboot) loads 45 | the bzImage and initramfs into memory and starts the kernel. The kernel 46 | checks for the presence of the initramfs and, if found, unpacks it, mounts 47 | it as `/` and runs `/init`. 48 | 49 | 50 | There are many types of initramfs, in this topic we focus on u-root. 51 | u-root is a Go user-space (a set of programs and libraries written in Go that 52 | are used to interact with the kernel). It contains a toolset of standard 53 | Linux applications and commands. 54 | 55 | u-root can create an initramfs in two different modes: 56 | 57 | * source mode, which contains: 58 | * Go toolchain binaries 59 | * A simple shell 60 | * Go source for tools to be compiled on the fly by the shell 61 | * Busybox (bb) mode: This is one busybox-like binary comprising all the 62 | requested utilities. 63 | 64 | The initramfs provided by u-root implements the toolchain needed to securely 65 | boot the machine from the network, perform identity verification, communicate 66 | with different internal boot-related components, and kexec the next kernel. 67 | 68 | u-root is an open source project hosted on GitHub. Within the u-root 69 | repository, we have executable commands in `cmds` and the packages containing 70 | libraries and implementations in `pkg`. 71 | 72 | -------------------------------------------------------------------------------- /src/coreboot.u-root.systemboot/index.md: -------------------------------------------------------------------------------- 1 | # LinuxBoot using coreboot, u-root and systemboot 2 | 3 | Points of contact: 4 | [Andrea Barberio](https://github.com/insomniacslk), 5 | [David Hendricks](https://github.com/dhendrix) 6 | 7 | This chapter describes how to build a LinuxBoot firmware based on coreboot, 8 | u-root and systemboot. The examples will focus on `x86_64`, and the coreboot 9 | builds will cover virtual and physical OCP hardware. 10 | 11 | ## Quick Start with coreboot 12 | 13 | Run these commands in a directory you create or in `/tmp`; do so because it 14 | creates some files and directories: 15 | 16 | ``` 17 | $ go get github.com/linuxboot/corebootnerf 18 | $ go run github.com/linuxboot/corebootnerf --fetch 19 | ... lots and lots of output! 20 | ``` 21 | 22 | This produces a coreboot image in coreboot-4.9/build/coreboot.rom 23 | You can now run this ROM image: 24 | 25 | ``` 26 | qemu-system-x86_64 -serial stdio -bios coreboot-4.9/build/coreboot.rom 27 | ``` 28 | 29 | And see how it looks when you put this in a coreboot ROM image. 30 | 31 | ## Components 32 | 33 | The final image is built on top of multiple open-source components: 34 | 35 | * [coreboot](https://coreboot.org), used for the platform initialization. 36 | Silicon and DRAM initialization are done here. 37 | * [Linux](https://kernel.org), used to initialize peripherals and various 38 | device drivers like file systems, storage and network devices; network stack; 39 | a multiuser and multitasking environment. 40 | * [u-root](https://github.com/u-root/u-root), an user-space environment that 41 | provides basic libraries and utilities to work in a Linux environment. 42 | * ~~[systemboot](https://systemboot.org), an additional set of libraries and 43 | tools on top of u-root, that provide a bootloader behaviour for various 44 | booting scenarios.~~ systemboot was merged into u-root. 45 | 46 | These components are built in reverse order. `u-root` and `systemboot` are 47 | built together in a single step. 48 | 49 | ## Building u-root 50 | 51 | The first step is building the initramfs. This is done using the `u-root` ramfs 52 | builder, with additional tools and libraries from `systemboot`. 53 | 54 | u-root is written in Go. We recommend using a relatively recent version of the 55 | Go toolchain. At the time of writing the latest is 1.11, and we recommend using 56 | at least version 1.10. Previous versions may not be fully supported. 57 | 58 | Adjust your `PATH` to include `${GOPATH}/bin`, in order to find the `u-root` 59 | command that we will use in the next steps. 60 | 61 | Then, fetch `u-root` and its dependencies: 62 | 63 | ``` 64 | go get -u github.com/u-root/u-root 65 | ``` 66 | 67 | Then build the ramfs in busybox mode, and add fbnetboot, localboot, and a custom 68 | uinit to wrap everything together: 69 | 70 | ``` 71 | u-root -build=bb core github.com/u-root/u-root/cmds/boot/{uinit,localboot,fbnetboot} 72 | ``` 73 | 74 | This command will generate a ramfs named `/tmp/initramfs_${os}_${arch}.cpio`, 75 | e.g. `/tmp/initramfs.linux_amd64.cpio`. You can specify an alternative output 76 | path with `-o`. Run `u-root -h` for additional command line parameters. 77 | 78 | Note: the above command will include only pure-Go commands from `u-root`. If 79 | you need to include other files or non-Go binaries, use the `-file` option in 80 | `u-root`. For example, you may want to include static builds of `kexec` or 81 | `flashrom`, that we build on https://github.com/systemboot/binaries . 82 | 83 | Then, the initramfs has to be compressed. This step is necessary to embed the 84 | initramfs in the kernel as explained below, in order to maintain the image size 85 | smaller. Linux has a limited XZ compressor, so the compression requires specific 86 | options: 87 | 88 | ``` 89 | xz --check=crc32 --lzma2=dict=512KiB /tmp/initramfs.linux_amd64.cpio 90 | ``` 91 | 92 | which will produce the file `/tmp/initramfs.linux_amd64.cpio.xz`. 93 | 94 | The kernel compression requirements are documented under 95 | [Documentation/xz.txt](https://www.kernel.org/doc/Documentation/xz.txt) (last 96 | checked 2018-12-03) in the kernel docs. 97 | 98 | ## Building a suitable Linux kernel 99 | 100 | A sample config to use with QEMU can be downloaded here: 101 | [linux-4.19.6-linuxboot.config](linux-4.19.6-linuxboot.config). 102 | 103 | You need a relatively recent kernel. Ideally a kernel 4.16, to have support for 104 | VPD variables, but a 4.11 can do the job too, if you don't care about boot 105 | entries and want "brute-force" booting only. 106 | 107 | We will build a kernel with the following properties: 108 | 109 | * small enough to fit most flash chips, and with some fundamental kernel features 110 | * that can run Go programs (mainly futex and epoll support) 111 | * with the relevant storage and network stack and drivers 112 | * with kexec support, so it can boot a new kernel 113 | * with kexec signature verification disabled (optional) 114 | * with devtmpfs enabled, since we don't use udev 115 | * XZ support to decompress the embedded initramfs 116 | * VPD (Vital Product Data) (optional) 117 | * TPM support (optional) 118 | * embed the u-root initramfs 119 | * and last but not least, "linuxboot" as default host name :) 120 | 121 | ### Download kernel sources 122 | 123 | You can either download a tarball from kernel.org, or get it via git and use a 124 | version tag. We recommend at least a kernel 4.16, in order to have VPD 125 | variables support. 126 | 127 | ``` 128 | # download the kernel tarball. Replace 4.19.6` with whatever kernel version you want 129 | wget https://cdn.kernel.org/pub/linux/kernel/v4.x/linux-4.19.6.tar.xz 130 | tar xvJf linux-4.19.6.tar.xz 131 | cd linux-4.19.6 132 | make tinyconfig 133 | ``` 134 | 135 | You can also check out the `linux-stable` branch, that will point to the latest 136 | stable commit. You need to download it via `git` as follows: 137 | 138 | ``` 139 | git clone --depth 1 -b linux-stable 140 | git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable.git 141 | cd linux-stable 142 | make tinyconfig 143 | ``` 144 | 145 | Some more information about tiny configs can be found at 146 | https://tiny.wiki.kernel.org (last checked 2018-12-01). 147 | 148 | ### A few fundamental features 149 | 150 | Assuming we are running on `x86_64`, some basic features to enable are: 151 | 152 | * `64-bit kernel` 153 | * `General setup` → `Configure standard kernel features` → `Enable 154 | support for printk` 155 | * `General setup` → `Configure standard kernel features` → `Multiple 156 | users, groups and capabilities support` (this is not strictly required on 157 | LinuxBoot) 158 | * `Processor type and features` → `Built-in kernel command line` 159 | (customize your command line here if needed, e.g. 160 | `earlyprintk=serial,ttyS0,57600 console=ttyS0,57600`) 161 | * `Executable file formats / Emulations` → `Kernel support for ELF 162 | binaries` (you may want to enable more formats) 163 | * `Networking support` → `Networking options` → `TCP/IP networking` 164 | * `Networking support` → `Networking options` → `The IPv6 protocol` 165 | * `Device Drivers` → `Character devices` → `Enable TTY` 166 | * `Device Drivers` → `Character devices` → `Serial drivers` → 167 | `8250/16550 and compatible serial support` 168 | * `Device Drivers` → `Character devices` → `Serial drivers` → 169 | `Console on 8250/16550 and compatible serial port` 170 | * `File systems` → `Pseudo filesystems` → `/proc file system support` 171 | * `File systems` → `Pseudo filesystems` → `sysfs file system support` 172 | 173 | ### Requirements for Go 1.11 174 | 175 | `Go` requires a few kernel features to work properly. At the time of writing, 176 | you need to enable `CONFIG_FUTEX` in your kernel config. Older versions of Go 177 | may require `CONFIG_EPOLL`. 178 | 179 | In menuconfig: 180 | 181 | * `General setup` → `Configure standard kernel features (expert users)` 182 | → `Enable futex support` 183 | * `General setup` → `Configure standard kernel features (expert users)` 184 | → `Enable eventpoll support` 185 | 186 | Additional information about Go's minimum requirements can be found at 187 | https://github.com/golang/go/wiki/MinimumRequirements (last checked 188 | 2018-12-01). 189 | 190 | ### Enable devtmpfs 191 | 192 | Our system firmware uses u-root, which does not have (intentionally) an `udev` 193 | equivalent. Therefore, to have `/dev/` automatically populated at boot time you 194 | should enable devtmps. 195 | 196 | Simply enable `CONFIG_DEVTMPFS` and `CONFIG_DEVTMPFS_MOUNT` in your kernel 197 | config. 198 | 199 | In menuconfig: 200 | 201 | * `Device drivers` → `Generic Driver Options` → `Maintain a devtmpfs 202 | filesystem to mount at /dev` 203 | * `Device drivers` → `Generic Driver Options` → `Automount devtmpfs 204 | at /dev, after the kernel mounted the rootfs` 205 | 206 | ### Additional drivers 207 | 208 | This really depends on your hardware. You may want to add all the relevant 209 | drivers for the platforms you plan to run LinuxBoot on. For example you may 210 | need to include NIC drivers, file system drivers, and any other device that you 211 | need at boot time. 212 | 213 | For example, enable SCSI disk, SATA drivers, EXT4, and e1000 NIC driver. In 214 | menuconfig: 215 | 216 | * `Bus options` → `PCI support` 217 | * `Enable the block layer` 218 | * `Device drivers` → `Block devices` (required for SCSI and SATA) 219 | * `Device drivers` → `SCSI device support` → `SCSI disk support` 220 | * `Device drivers` → `Serial ATA and Parallel ATA drivers` 221 | * `File systems` → `The Extended 4 (ext4) filesystem` 222 | * `Networking support` (required for e1000) 223 | * `Device drivers` → `Network device support` → `Ethernet driver 224 | support` → `Intel(R) PRO/1000 Gigabit Ethernet support` 225 | 226 | ### Enable XZ kernel and initramfs compression support 227 | 228 | The `u-root`-based RAMFS will be compressed with XZ and embedded in the kernel. 229 | Hence you need to enable XZ compression support. Make sure to have at least 230 | `CONFIG_HAVE_KERNEL_XZ`, `CONFIG_KERNEL_XZ`, `CONFIG_DECOMPRESS_XZ`. 231 | 232 | In menuconfig: 233 | 234 | * `General setup` → `Kernel compression mode` → `XZ` 235 | * `General setup` → `Initial RAM filesystem and RAM disk 236 | (initramfs/initrd) support` → `Support initial ramdisk/ramfs compressed 237 | using XZ` 238 | 239 | ### Enable VPD 240 | 241 | VPD stands for [Vital Product 242 | Data](https://chromium.googlesource.com/chromiumos/platform/vpd/+/1c1806d8df4bb5976eed71a2e2bf156c36ccdce2/README.md). 243 | We use VPD to store boot configuration for `localboot` and `fbnetboot`, 244 | similarly to UEFI's boot variables. Linux supports VPD out of the box, but you 245 | need at least a kernel 4.16. 246 | 247 | Make sure to have `CONFIG_GOOGLE_VPD` enabled in your kernel config. 248 | 249 | In menuconfig: 250 | 251 | * `Firmware drivers` → `Google Firmware Drivers` → `Coreboot Table 252 | Access - ACPI` → `Vital Product Data` 253 | 254 | ### TPM support 255 | 256 | This also depends on your needs. If you plan to use TPM, and this is supported 257 | by your platform, make sure to enable `CONFIG_TCG_TPM`. 258 | 259 | In menuconfig: 260 | 261 | * `Device drivers` → `Character devices` → `TPM Hardware Support` 262 | → (enable the relevant drivers) 263 | 264 | ### Include the initramfs 265 | 266 | As mentioned above, the kernel will embed the compressed initramfs image. Your 267 | kernel configuration should point to the appropriate file using the 268 | `CONFIG_INITRAMFS_SOURCE` directive. E.g. 269 | 270 | ``` 271 | CONFIG_INITRAMFS_SOURCE="/path/to/initramfs_linux.x86_64.cpio.xz" 272 | ``` 273 | 274 | In menuconfig: 275 | 276 | * `General setup` → `Initial RAM filesystem and RAM disk 277 | (initramfs/initrd) support` → `Initramfs source file(s)` 278 | 279 | ### Default hostname 280 | 281 | We use "linuxboot" as the default hostname. You may want to adjust it to a 282 | different value. You need to set `CONFIG_DEFAULT_HOSTNAME` for the purpose. For 283 | example: 284 | 285 | ``` 286 | CONFIG_DEFAULT_HOSTNAME="linuxboot" 287 | ``` 288 | 289 | In menuconfig: 290 | 291 | * `General setup` → `Default hostname` 292 | 293 | ### Build the kernel 294 | 295 | Once your configuration is ready, build the kernel as usual: 296 | 297 | ``` 298 | make -j$(nproc --ignore=1) 299 | ``` 300 | 301 | The image will be located under `arch/${ARCH}/boot/bzImage` if your 302 | architecture supports bzImage (e.g. x86). 303 | 304 | For more details on how to build a kernel, see 305 | https://kernelnewbies.org/KernelBuild (last checked 2018-12-01). 306 | 307 | ## Building coreboot 308 | 309 | In this step we will build `coreboot` using the Linux kernel image that we 310 | built at the previous step as payload. This build is for a Qemu x86 target, the 311 | process may be somehow different for other platforms. 312 | 313 | Steps overview: 314 | 315 | * download coreboot from the git repo 316 | * build the compiler toolchain 317 | * configure coreboot for Qemu, and to use our `bzImage` as payload 318 | * build `coreboot.rom` 319 | 320 | ### Download coreboot 321 | 322 | Our preferred method is to download coreboot from the git repository: 323 | 324 | ``` 325 | git clone https://review.coreboot.org/coreboot.git 326 | cd coreboot 327 | ``` 328 | 329 | ### Build the compiler toolchain 330 | 331 | This step is required to have, among other things, reproducible builds, and a 332 | compiler toolchain that is known to work with coreboot. 333 | 334 | ``` 335 | make crossgcc-i386 CPUS=$(nproc) BUILD_LANGUAGES=c 336 | ``` 337 | 338 | The step above may ask you to install a few additional libraries or headers, do 339 | so as requested, with the exception of gcc-gnat, that we won't need. 340 | 341 | ### Configure coreboot for Qemu and our payload 342 | 343 | Run `make menuconfig` to enter the coreboot configuration menus. Then: 344 | 345 | Specify the platform we will run on: 346 | 347 | * `Mainboard` → `Mainboard vendor` → `Emulation` 348 | * `Mainboard` → `Mainboard Model` → `QEMU x86 q35/ich9 (aka qemu -M 349 | q35, since v1.4)` 350 | 351 | Specify a large enough flash chip and CBFS size: 352 | 353 | * `Mainboard` → `ROM chip size` → `16 MB` 354 | * `Mainboard` → `Size of CBFS filesystem in ROM` → `0x1000000` 355 | 356 | Specify our payload: 357 | 358 | * `Payload` → `Add a payload` → `A Linux payload` 359 | * `Payload` → `Linux path and filename` → path to your bzImage 360 | 361 | Then save your configuration and exit menuconfig. 362 | 363 | ### Build coreboot 364 | 365 | This is done with a simple 366 | 367 | ``` 368 | make -j$(nproc) 369 | ``` 370 | 371 | The coreboot build system will clone the relevant submodules, if it was not done 372 | already, and will build a coreboot ROM file that will contain the initialization 373 | code, and our bzImage payload. The output file is at `build/coreboot.rom`. 374 | 375 | If everything works correctly you will get an output similar to the following: 376 | 377 | ``` 378 | This image contains the following sections that can be manipulated with this tool: 379 | 380 | 'COREBOOT' (CBFS, size 16776704, offset 512) 381 | 382 | It is possible to perform either the write action or the CBFS add/remove actions on every section listed above. 383 | To see the image's read-only sections as well, rerun with the -w option. 384 | CBFSPRINT coreboot.rom 385 | 386 | FMAP REGION: COREBOOT 387 | Name Offset Type Size Comp 388 | cbfs master header 0x0 cbfs header 32 none 389 | fallback/romstage 0x80 stage 15300 none 390 | fallback/ramstage 0x3cc0 stage 51805 none 391 | config 0x10780 raw 155 none 392 | revision 0x10880 raw 576 none 393 | cmos_layout.bin 0x10b00 cmos_layout 548 none 394 | fallback/dsdt.aml 0x10d80 raw 6952 none 395 | fallback/payload 0x12900 simple elf 5883908 none 396 | (empty) 0x5af140 null 10800216 none 397 | bootblock 0xffbdc0 bootblock 16384 none 398 | 399 | Built emulation/qemu-q35 (QEMU x86 q35/ich9) 400 | ``` 401 | 402 | ## Putting everything together 403 | 404 | TODO 405 | 406 | ## Defining boot entries 407 | 408 | TODO 409 | 410 | ## Running on a virtual machine 411 | 412 | The image built with the above steps can run on a QEMU virtual machine, using 413 | the machine type `q35`, as specified in the coreboot mainboard section. 414 | Assuming that your coreboot image is located at `build/coreboot.rom`, you can 415 | run the following command: 416 | 417 | ``` 418 | sudo qemu-system-x86_64\ # sudo is required to enable KVM below 419 | -M q35 \ # the machine type specified in the coreboot mainboard configuration 420 | -enable-kvm \ # use KVM to avail of hardware virtualization extensions 421 | -bios build/coreboot.rom \ # the coreboot ROM to run as system firmware 422 | -m 1024 \ # the amount of RAM in MB 423 | -object rng-random,filename=/dev/urandom,id=rng0 \ 424 | # RNG to avoid DHCP lockups when waiting for entropy 425 | -nographic # redirect all the output to the console 426 | ``` 427 | 428 | If everything has been done correctly you should see, in order, the output from 429 | `coreboot`, `linux`, `u-root`, and `systemboot`. You can press `ctrl-c` when 430 | Systemboot instructs you to do so, to enter the `u-root` shell. 431 | 432 | ## Running on real OCP hardware 433 | 434 | TODO 435 | -------------------------------------------------------------------------------- /src/faq.md: -------------------------------------------------------------------------------- 1 | # Frequently asked questions 2 | 3 | ## Troubleshooting 4 | 5 | **Why does the u-root DHCP client take ages?** 6 | 7 | The problem is a lack of early entropy. If your platform has a hardware 8 | random number generator then enable it with `CONFIG_ARCH_RANDOM` and trust it 9 | with `CONFIG_RANDOM_TRUST_CPU`. Otherwise, add `uroot.nohwrng` to your kernel 10 | command line so u-root use a non-blocking random number generator 11 | implementation. 12 | -------------------------------------------------------------------------------- /src/glossary.md: -------------------------------------------------------------------------------- 1 | # Glossary 2 | 3 | - ___BIOS___: Originally, BIOS was the software built into computers to send 4 | simple instructions to the hardware, allowing input and output before the 5 | operating system was loaded. It was a binary blob with no standardized 6 | structure that was responsible for initializing CPU and memory, and jumping 7 | to a hard-coded position on the master block of the first disk drive. BIOS 8 | has been largely replaced by UEFI. Many UEFI implementations still offer a 9 | "BIOS compatibility mode" which makes it behave like an old BIOS, with its 10 | features. 11 | - ___busybox___: Busybox is a single user-space binary which includes versions 12 | of a large number of system commands, including a shell. This package can be 13 | very useful for recovering from certain types of system failures, 14 | particularly those involving broken shared libraries. There are multiple 15 | implementations of busybox, such as git.busybox.net/busybox and 16 | github.com/u-root/u-root. 17 | - [___coreboot___](https://doc.coreboot.org/): A project to develop open source 18 | boot firmware for various architectures. Its design philosophy is to do the 19 | bare minimum necessary to ensure that hardware is usable and then pass 20 | control to a different program called the payload. The payload can then 21 | provide user interfaces, file system drivers, various policies etc. to load 22 | the OS. 23 | - ___DHCP___: A networking protocol that runs on a DHCP server and that 24 | automatically assigns an IP address from a pre-configured pool to any machine 25 | that queries it on boot up. 26 | - [___EDK II___](https://github.com/tianocore/edk2): An open source reference 27 | implementation of an UEFI-compliant firmware, originally developed by Intel 28 | - ___firmware___: A specific class of computer software that provides low-level 29 | control for a device's specific hardware. It is installed at the time of 30 | manufacturing and is the first program that runs when a computer is turned 31 | on. It checks to see what hardware components the computing device has, wakes 32 | the components up, and hands them over to the operating system that is to be 33 | installed on the machine. The current x86 firmware is based on Intel’s 34 | Universal Extensible Firmware Interface (UEFI). 35 | - ___flashkernel___: A small Linux kernel that is stored in flash and used as a 36 | boot stage (e.g. the kernel used in LinuxBoot). Debian and Ubuntu maintain a 37 | `flash-kernel` script to install the kernel and initramfs in a special 38 | location for embedded devices that can not boot the kernel and initramfs using 39 | the normal `/boot` mechanism 40 | - [___Heads___](https://github.com/linuxboot/heads): An open source firmware 41 | for laptops and servers, aimed at strong platform security. Developed by 42 | Trammell Hudson, based on stripped UEFI plus Linux, and BusyBox instead of 43 | u-root. 44 | - ___iSCSI___: A protocol that provides a way to make network-attached storage 45 | appear to be a local device to the hosts using it, allowing it to be (among 46 | other things) mounted as a regular local file system. 47 | - ___kexec___: A system call that enables you to load and boot into another 48 | kernel from the currently running kernel. kexec performs the function of the 49 | boot loader from within the kernel. 50 | - ___LinuxBIOS___: A project originated in 1999 from Ron Minnich, Stefan 51 | Reinauer and others. It was an experiment in the idea of running Linux as 52 | firmware. At that time Linux was not mature enough for a hardware 53 | initialization project, and while LinuxBIOS was successful in several 54 | performance-and-reliability critical environments, it didn't see mass 55 | adoption. It later became coreboot. 56 | - ___LinuxBoot___: LinuxBoot is not a product, but rather a concept. It's the 57 | idea of booting Linux (OS) with Linux (system firmware). In a way, the same 58 | concept pioneered by LinuxBIOS. It is like a Linux distribution, but for 59 | firmware. It is a collection of various open source components, combined to 60 | work as a consistent firmware OS. 61 | - ___NERF___: The original name for the LinuxBoot project composed of stripped 62 | UEFI plus Linux plus u-root. The name stands for Non-Extensible Reduced 63 | Firmware, as opposed to UEFI's Unified Extensible Firmware Interface. NERF is 64 | an UEFI replacement that is more compact and less extensible. While 65 | extensibility is nice and often desirable, too much extensibility can make a 66 | complex project very hard to maintain and keep secure. 67 | - ___Open Source Firmware___: OSF can be used to refer to Open Source Firmware 68 | or Open System Firmware depending on the context. 69 | - ___Open System Firmware (OSF)___: An official subproject of the Open Compute 70 | Project (OCP). OSF has been developed in the open, by various members of OCP 71 | that were interested in having open source system firmware. OSF defines a set 72 | of guidelines with contributions from Microsoft, Google, Facebook, Intel, 73 | 9elements, TwoSigma, and several other companies. 74 | - ___OVMF___: Open Virtual Machine Firmware. Open Virtual Machine Firmware is a 75 | build of EDK II for virtual machines. It includes full support for UEFI, 76 | including Secure Boot, allowing use of UEFI in place of a traditional BIOS in 77 | your EFI Initialization (PEI)|UEFI stage which runs before RAM is 78 | initialized, from cache and ROM. PEI is mostly C-code running in 32-bit 79 | protected flat mode. The main goal of the PEI stage is to detect RAM. As 80 | soon as RAM is detected and configured, PEI stage give control to the DXE 81 | through DXE Initial Program Load (IPL) driver 82 | - ___production kernel___: LinuxBoot is not intended to be a runtime production 83 | kernel; rather, it is meant to replace specific UEFI functionality using 84 | Linux kernel capabilities and then boot the actual production kernel 85 | (prodkernel) on the machine. Kernel configuration files specific to LinuxBoot 86 | provide the needed Linux kernel capabilities without bloating the size of the 87 | BIOS with unnecessary drivers. 88 | - ___PureBoot___: A combination of disabling IME, coreboot, a TPM, Heads and 89 | the Librem Key (see [Trusted Boot (Anti-Evil-Maid, Heads, and 90 | PureBoot)](https://tech.michaelaltfield.net/2023/02/16/evil-maid-heads-pureboot/#pureboot)) 91 | - ___QEMU___: An emulator that performs hardware virtualization. QEMU is a 92 | hosted virtual machine monitor. 93 | - ___Secure Boot Preverifier (SEC)___: In UEFI, the SEC stage initializes the 94 | CPU cache-as-RAM (CAR) and gives control to the PEI dispatcher. It is 99.9% 95 | assembly code (32-bit protected mode). 96 | - ___u-boot___: A very popular open source firmware and bootloader. Not to be 97 | confused with u-root. 98 | - ___u-root___: A modern, embedded user-space environment for Linux, with 99 | bootloader tools. See the section on u-root. 100 | - ___UEFI___: Unified Extensible Firmware Interface. It is Intel’s 101 | specification of a standard for system firmware. UEFI defines everything from 102 | the layout on the flash chip, to how to interface to peripherals, enables 103 | boot from disk or from a network, defines how UEFI applications work, etc). 104 | It is not an implementation, it's a standard. EDK II and OpenEDK II are UEFI 105 | implementations. UEFI is not closed source per-se, but in practice most 106 | implementations are. 107 | -------------------------------------------------------------------------------- /src/history.md: -------------------------------------------------------------------------------- 1 | # History 2 | 3 | ## BIOS 4 | 5 | [BIOS](https://en.wikipedia.org/wiki/BIOS) is the good old, inscrutable way of 6 | initializing a hardware platform in the pre-UEFI days. It's a binary blob with 7 | no standardized structure, that is responsible for initializing CPU and memory, 8 | and jumping to a hard-coded position on the MBR of the first disk drive. 9 | 10 | Starting around 2000, BIOS has been largely replaced by the standardized 11 | [UEFI](https://en.wikipedia.org/wiki/UEFI). 12 | Many UEFI implementations still offer a BIOS compatibility mode called CSM 13 | (Compatibility Support Module), which makes it behave like an old BIOS. 14 | 15 | Note that the term "BIOS" is sometimes misused to refer to the general concept 16 | of _system firmware_, such as UEFI or even LinuxBoot. However, as "BIOS" refers 17 | to firmware with specific functionality, UEFI is definitely _not_ a BIOS, nor is 18 | LinuxBoot a BIOS in the original sense. 19 | 20 | ## LinuxBIOS 21 | 22 | The [LinuxBIOS]( 23 | https://web.archive.org/web/20070430170020/http://www.linuxbios.org/Welcome_to_LinuxBIOS) 24 | project was created in 1999 by Ron Minnich, Stefan Reinauer and others. It is 25 | not much younger than UEFI, but they were already experimenting the idea of 26 | running Linux as firmware. Like many great ideas, it was way ahead of its time. 27 | At that time Linux was not mature enough to be used in a hardware initialization 28 | project, and while LinuxBIOS was successful in several 29 | performance-and-reliability critical environments, it didn't see mass adoption. 30 | 31 | In 2008 LinuxBIOS became [coreboot](https://www.coreboot.org/). 32 | 33 | ## LinuxBoot 34 | 35 | ### NERF 36 | 37 | This is the original name for the stripped UEFI, plus Linux, plus u-root. The 38 | name stands for Non-Extensible Reduced Firmware, as opposed to UEFI's Unified 39 | Extensible Firmware Interface. Basically, saying that NERF is an UEFI 40 | replacement that prefers to be more compact, less extensible, and a bit more 41 | opinionated. While extensibility is nice and often desirable, too much 42 | extensibility and too many "yes" can make a complex project very hard to 43 | maintain and keep secure. 44 | 45 | NERF was created by Ron Minnich while at Google in 2017. The project grew and 46 | was maintained by Google's "NERF team". 47 | 48 | NERF eventually became the [linuxboot](https://github.com/linuxboot/linuxboot/) 49 | build system. 50 | 51 | ### Heads 52 | 53 | [Heads](https://github.com/linuxboot/heads) is an open source firmware for 54 | laptops and servers created by Trammell Hudson (a.k.a. osreasrch), aimed at 55 | strong platform security. It is currently maintained by Thierry Laurion. 56 | 57 | ### See also 58 | 59 | * [osresearch.net](https://osresearch.net/) 60 | * [trmm.net/NERF](https://trmm.net/NERF/) 61 | * [NERF-Projekt statt UEFI](https://www.golem.de/news/freie-linux-firmware-google-will-server-ohne-intel-me-und-uefi-1710-130840-2.html) 62 | * [Bringing Linux back to the Server BIOS with LinuxBoot](https://www.twosigma.com/articles/bringing-linux-back-to-the-server-bios-with-linuxboot/) 63 | * [LinuxBoot: A Fast, Reliable Open Source Firmware for Linux Servers](https://www.twosigma.com/articles/linuxboot-a-fast-reliable-open-source-firmware-for-linux-servers/) 64 | * [safeboot: Improving the Safety of Booting Linux on Normal Laptops](https://www.twosigma.com/articles/safeboot-improving-the-safety-of-booting-linux-on-normal-laptops/) 65 | 66 | ## Open Platform Firmware 67 | 68 | [Open Platform 69 | Firmware](https://www.opencompute.org/projects/open-system-firmware) (OPF), 70 | formerly Open System Firmware (OSF), is an official subproject of the [Open 71 | Compute Project](https://www.opencompute.org) (OCP). OPF has been developed in 72 | the open, by various members of OCP that were interested in having open source 73 | system firmware. OPF defines a set of guidelines with contributions from 74 | Microsoft, Google, Facebook, Intel, 9elements, Two Sigma, and several other 75 | companies. 76 | 77 | The important thing to keep in mind is that **Open Platform Firmware is a project 78 | name**, not an implementation, nor an idea. An implementation (like LinuxBoot 79 | or OpenEDK2) can be OPF-compliant if it follows the aforementioned guidelines. 80 | 81 | Currently, Open Platform Firmware has two work streams: 82 | 83 | * LinuxBoot, led by Google, Facebook, 9elements, ITRenew, TwoSigma, and others 84 | * OpenEDK II, led by Microsoft and Intel 85 | -------------------------------------------------------------------------------- /src/images/Case-study-Ampere.svg: -------------------------------------------------------------------------------- 1 | 2 | 3 |
TF-A
TF-A
Trusted Firmware
Trusted Firmware
Pre-EFI
PEI
Pre-EFI...
Drivers
DXE
Drivers...
CPU
CPU
Memory
Memory
PCIe
PCIe
DXE Core
DXE Core
DXE Dispatcher
DXE Dispatcher
Boot Manager
Boot Manager
LinuxBoot
Linux kernel + u-root initramfs
LinuxBoot...
Runtime (RT)
Runtime (RT)
Target OS
Target OS
Platform Init DXE
Platform Init DXE
SMBIOS DXEs
SMBIOS DXEs
ACPI DXEs
ACPI DXEs
Firmware Update DXEs
Firmware Update DXEs
UEFI Arch DXEs
UEFI Arch DXEs
~ 32 DXEs including
8 Ampere's modules
~ 32 DXEs including...
~ 11 PEIs including
2 Ampere's modules
~ 11 PEIs including... -------------------------------------------------------------------------------- /src/images/LinuxBoot-components.svg: -------------------------------------------------------------------------------- 1 | -------------------------------------------------------------------------------- /src/implementation.md: -------------------------------------------------------------------------------- 1 | # Implementing LinuxBoot 2 | 3 | The aim of LinuxBoot is to reduce complexity and obscure firmware by moving 4 | that functionality into kernel and user-space. 5 | 6 | This chapter describes the procedures from a [LinuxBoot 7 | workshop](https://docs.google.com/presentation/d/1s9ka4v7leKeJa3116AQoNb9cv3OqmnW6pgn0ov9WiHo/edit?ts=5e2b227b#slide=id.g7ceec54197_4_163) 8 | where an Atomic Pi board with UEFI firmware was converted to run LinuxBoot. The 9 | build materials associated with this are found at 10 | [digitalloggers/atomicpi](https://github.com/linuxboot/mainboards/tree/master/digitalloggers/atomicpi). 11 | 12 | Read the below and consult the Makefile for the details of how it was 13 | implemented. 14 | 15 | ## A quick refresher on UEFI 16 | 17 | UEFI has three sections: 18 | 19 | + SEC ("Boot") 20 | + PEI ("Very early chip setup and DRAM programming") 21 | + DXE ("DRAM code") 22 | 23 | DXE process is very complex; some systems have 750 DXEs. 24 | 25 | LinuxBoot replaces most of the UEFI software with Linux. LinuxBoot has an 26 | initramfs provided by [u-root](./u-root.md). 27 | 28 | The above are stored inside a flash filesystem (FFS) inside a region of flash 29 | on your motherboard (the BIOS region). Another important region of flash is the 30 | ME region. 31 | 32 | The Management Engine (ME) is an x86 CPU embedded in the Intel Platform 33 | Controller Hub (PCH). It runs the Minix operating system which boots first and 34 | enables hardware such as clocks and GPIOs. ME checks the contents of flash 35 | memory and is used to implement "BootGuard". If you reflash and the ME is in 36 | "BootGuard" mode, your machine will be unusable. You need to run a tool called 37 | `me_cleaner` on the image to disable BootGuard. 38 | 39 | ## How do you get LinuxBoot on your hardware 40 | 41 | Start with a board running standard UEFI and proceed from "zero changes to 42 | FLASH" to "max changes" in 4 steps: 43 | 44 | + Boot from USB stick via UEFI shell command _or_ netboot (zero changes) 45 | + Find a way to read flash and write flash 46 | + Understand the flash layout 47 | + Prepare linux kernel and initrd/initramfs payload. 48 | + Replace UEFI Shell code section with Linux kernel and associated initrd 49 | (change part of one thing) 50 | + Remove as many DXEs as possible (change by removal). This change: 51 | + Speeds boot 52 | + Reduces panic possibilities 53 | + Removes exploits 54 | + In production, it has solved problems 55 | + Clear ME region for initrd storage 56 | + Replace some DXEs with open source components (change by replacement) 57 | 58 | One of the challenges in the above is in finding (or reclaiming) enough space 59 | in flash to shoehorn your kernel and initrd into. 60 | 61 | ## Tools of the trade 62 | 63 | There are two tools you use when you modify the UEFI flash image: `utk` and 64 | `me_cleaner`. 65 | 66 | The ME Cleaner tool: 67 | 68 | `/usr/bin/python2 me_cleaner.py -s` _imagefile.bin_ 69 | 70 | `me_cleaner` sets the high assurance platform (HAP) bit. HAP provides a way to 71 | disable a feature on Intel chips that does not allow us to modify the UEFI 72 | image and install LinuxBoot. Setting the bit with `me_cleaner` disables the 73 | "feature". Note that this does not always work; check with the LinuxBoot 74 | community. 75 | 76 | When you run `me_cleaner`: 77 | 78 | ``` 79 | ~/projects/linuxboot/me_cleaner/me_cleaner.py -s /tmp/rom.bin 80 | ``` 81 | 82 | you should see output similar to the following: 83 | 84 | | | 85 | |:---| 86 | |`Full image detected`| 87 | |`Found FPT header at 0x1010`| 88 | |`Found 20 partition(s)`| 89 | |`Found FTPR header: FTPR partition spans from 0x6f000 to 0xe700`| 90 | |`ME/TXE firmware version 2.0.5.3112 (generation 2)`| 91 | |`Public key match: Intel TXE, firmware versions 2.x.x.x`| 92 | |`The AltMeDisable bit is SET`| 93 | |`Setting the AltMeDisable bit in PCHSTRP10 to disable Intel ME…`| 94 | |`Checking the FTPR RSA signature... VALID`| 95 | |`Done! Good luck!`| 96 | 97 | By applying `me_cleaner`, it has been observed that almost 4M of flash ram can 98 | be reclaimed for use. That 4M is enough to store a reasonably full featured 99 | compressed initrd image. 100 | 101 | The `utk` tool can: 102 | 103 | + Remove DXEs 104 | + Insert new DXEs 105 | + Replace the binary code of a DXE with a kernel 106 | + Reallocate space from the ME region to the BIOS region ("tighten") 107 | 108 | ## LinuxBoot Implementation steps 109 | 110 | ### Step 1: boot Linux via netboot / UEFI shell 111 | 112 | + netboot: standard BIOS-based PXE boot 113 | + Netboot is probably the most common working boot method on UEFI 114 | + We have never seen a system that did not have a net boot 115 | + UEFI Shell (mentioned only for completeness) 116 | + Install Linux on FAT-32 media with a name of your choice (e.g. "kernel") 117 | + FAT-32, also known as MS-DOS file system 118 | + Boot kernel at UEFI Shell prompt 119 | + We've run into a few systems that don't have a UEFI shell 120 | 121 | #### Working with a system that only has a net interface 122 | 123 | If the system only has a net interface, you use Dynamic Host Configuration 124 | Protocol (DHCP), using broadcast DISCOVER, and Trivial File Transfer Protocol 125 | (TFTP) to get the boot information you need. 126 | 127 | Configuration information is provided by REPLY to a DHCP request. The REPLY 128 | returns an IP, server, and a configuration file name that provides: 129 | 130 | + Identity 131 | + What to boot 132 | + Where to get it 133 | 134 | Data is provided by TFTP. HTTP downloading takes a fraction of a second even 135 | for 16M kernels. With TFTP it's very slow and TFTP won't work with initramfs 136 | much large than 32MiB. Most LinuxBoot shops use or are transitioning to HTTP. 137 | 138 | Note: Boot images require a kernel(bzImage) + an initramfs + a command line. 139 | They can be loaded as three pieces or compiled and loaded as one piece, as 140 | described in this section. 141 | 142 | ### Step 2: read & write the flash 143 | 144 | There are two main ways to read and write the flash - hardware and software. 145 | 146 | Hardware: It is worth buying a Pomona 5250 SOIC Clip adapter to read directly 147 | by hardware to have something to roll back to if anything goes wrong. Avoid 148 | cheap SOIC clip adapters that don't allow you to use standard jumper leads. For 149 | a good example of using a Raspberry Pi 3/4 to read/write, see [Sakaki's EFI 150 | Install Guide/Disabling the Intel Management 151 | Engine](https://wiki.gentoo.org/wiki/Sakaki%27s_EFI_Install_Guide/Disabling_the_Intel_Management_Engine#imt_check) 152 | 153 | Software: With a working boot image, use flashrom to read an image of your 154 | flash. To write you may need to disable flash protections (look for "ME 155 | Manufacturing mode" jumpers on your motherboard). Figure on generally using 156 | software methods for reading & writing flash, but with hardware to drop back 157 | to. 158 | 159 | ### Step 3: Familiarise yourself with the flash layout and identify free space 160 | 161 | Open your flash image with UEFITool, and locate the filesystem containing the 162 | DXE's (it will have the Shell or `Shell_Full` in it ). Check how much volume free 163 | space is in that filesystem - this will be an initial limit when you come to 164 | place your kernel and initramfs in it in step 5. 165 | 166 | ### Step 4: Prepare linux/u-root payload 167 | 168 | Start small and work your way up. 169 | 170 | + Use the tiny.config to configure your first kernel, and embed a small 171 | initramfs in-kernel (the u-root cpu payload is an excellent starting point). 172 | + One can have a full kernel/initramfs in around 2M of flash. 173 | + A more full featured kernel might consume 2M and a u-root bb distribution 4M, 174 | which may well exceed the volume free space. 175 | + When there isn't enough space in this filesystem, one can either start 176 | removing unused DXE's (step 6), or use space formerly used by the ME Region 177 | (step 7). 178 | 179 | ### Step 5: replace Shell binary section 180 | 181 | + UEFI Shell is a DXE 182 | + DXEs are Portable Executable 32-bit binaries (PE32) 183 | + They have multiple sections, one of them being binary code 184 | + You need a flash image (in this case called _firmware.bin_). You can get 185 | it via vendor website, flashrom, or other mechanism. 186 | + The following `utk` command replaces the Shell code section with a Linux 187 | kernel: 188 | + `utk firmware.bin replace_pe32 Shell bzImage save` _new.bin_ 189 | + Note: It's always a PE32, even for 64-bit kernels. _new.bin_ is a filename 190 | of your choosing. 191 | + After running `utk`, you can reflash 192 | 193 | ### Step 6a: remove as many DXEs as possible 194 | 195 | + You can do an initial mass removal based on your current knowledge 196 | + `utk` automates removing DXEs: this is the DXE cleaner 197 | + `utk` removes a DXE, reflashes, checks if it boots, repeat 198 | This part should be easy: DXE can have a dependency section. In practice, 199 | it's hard: because dependency sections are full of errors and omissions. A lot 200 | of UEFI code does not check for failed DXE loads. 201 | 202 | ### Step 6b: place your initramfs in me_cleaned region 203 | 204 | + Run `me_cleaner` and then utk tighten on the source image, then inspect the 205 | image using UEFITool. If successful, there will now be padding at the 206 | beginning of the BIOS region of a substantial size. 207 | + This padding space can be used, without the filesystem's knowledge, to stash 208 | an initramfs. The kernel is informed of the location this initramfs as an 209 | initrd kernel parameter. 210 | + Use the base address of this padding region to calculate the offset in 211 | the flash image where the initrd is stashed using dd. 212 | + Use the address (not base address) as the initramfs location in memory to 213 | pass as a kernel parameter. 214 | 215 | ### Step 7: replace closed-source with open source 216 | 217 | + If you can build a DXE from source, you can use `utk` to remove the 218 | proprietary one and replace it with one built from source. You can get DXE 219 | source from the tianocore/EDK2 source repo at github.com. The GitHub repo has a 220 | **_limited_** number of DXEs in source form; i.e., you can't build a full 221 | working image using it. 222 | + There are scripts that let you compile individual DXEs, including the UEFI 223 | Shell and Boot Device Selection (BDS). These two DXEs have been compiled and 224 | are used in the Atomic Pi. Source-based BDS was needed to ensure the UEFI 225 | Shell was called. 226 | + You only need the UEFI Shell built long enough to replace it with Linux. 227 | 228 | ### Final step: reflash the image 229 | 230 | + "Native" reflash: Boot the system whatever way is easiest: netboot, usb, 231 | local disk, and run `flashrom -p internal -w _filename.bin_` where 232 | _filename.bin_ is a filename of your choosing. 233 | + Run `flashrom` with an external device such as an sf100. There may be a 234 | header on the board, or you might have to use a clip. 235 | `flashrom -p dediprog:voltage=1.8 -w _filename.bin_` 236 | 237 | The voltage option is required for the Atomic Pi. 238 | -------------------------------------------------------------------------------- /src/intro.md: -------------------------------------------------------------------------------- 1 | # LinuxBoot Introduction 2 | 3 | This is the official “LinuxBoot Book” for the LinuxBoot project. The book: 4 | 5 | * Describes the LinuxBoot project 6 | * Explains why you would want to use LinuxBoot 7 | * Describes the components that comprise LinuxBoot 8 | * Highlights the differences between other boot processes and LinuxBoot 9 | * Guides you through the steps needed to implement LinuxBoot 10 | 11 | ## What is LinuxBoot? 12 | 13 | LinuxBoot is the idea of replacing proprietary or corporate-driven late-stage 14 | boot [firmware](./glossary.md) with the Linux kernel and a community-based 15 | user-space. That idea grew into a project that over the years includes various 16 | initiatives with the overarching goal of moving from obscure and complex 17 | firmware to simpler and open source firmware. 18 | 19 | The LinuxBoot project provides two reference implementations; `linuxboot` and 20 | Heads. The [`linuxboot`](https://github.com/linuxboot/linuxboot) build system 21 | outputs a boot payload consisting of a Linux kernel and an 22 | [initramfs](https://de.wikipedia.org/wiki/Initramfs) that contains a minimal 23 | Go user-space built using [u-root](https://github.com/u-root/u-root). 24 | 25 | The Heads build system is more focused on local attestation, TPM DUK 26 | seal/unseal operations, GPG-based security measurement, reproducible builds and 27 | uses BusyBox to provide a much larger suite of Linux tools allowing it to also 28 | be used as a recovery environment. 29 | 30 | Many other implementations exist independently of the project: 31 | 32 | - [petitboot](https://github.com/open-power/petitboot) under the OpenPOWER 33 | project originally targeting the PS3 34 | - [k-boot](https://github.com/BayLibre/k-boot) developed by BayLibre in 2023 35 | using BusyBox 36 | - [nmbl](https://github.com/rhboot/nmbl-poc) developed by RedHat in 2024 37 | - [ZFSBootMenu](https://docs.zfsbootmenu.org/en/latest) 38 | 39 | And there is a long history of similar implementations including projects that 40 | are no longer maintained: 41 | 42 | - MILO on Alpha started before 2000 (see [What is 43 | MILO?](https://tldp.org/HOWTO/MILO-HOWTO/what-section.html)) 44 | - kboot developed by Werner Almesberger in 2005 45 | 46 | These projects all attempt to reduce the role of firmware to a small, 47 | fixed-function core whose only purpose is to get a flash-based Linux kernel 48 | started. This “bare essentials” firmware prepares the hardware and starts a 49 | Linux kernel and a user-space environment will run on the machine. Go is the 50 | recommended user-space environment, but is not required. 51 | 52 | ## Why LinuxBoot is needed 53 | 54 | Sometimes firmware contains drivers and utilities. They can have bugs, or be 55 | unmaintained, which can be a source of problems and security issues. LinuxBoot 56 | replaces proprietary, closed-source, vendor-supplied firmware drivers with 57 | Linux drivers. This enables engineers writing Linux drivers and engineers 58 | writing firmware drivers to focus on one set of drivers. Those drivers will, as 59 | a result, have a larger set of contributors and reviewers, and because the 60 | drivers are part of Linux, standard industry coding infrastructure can be used 61 | to improve them. Finally, because these Linux drivers are currently being run 62 | around the clock at scale, they will have fewer bugs. 63 | 64 | ## What LinuxBoot does 65 | 66 | LinuxBoot replaces many Driver Execution Environment (DXE) modules used by 67 | Unified Extensible Firmware Interface (UEFI) and other firmware, particularly 68 | the network stack and file system modules, with Linux applications. 69 | 70 | LinuxBoot brings up the Linux kernel as a DXE in flash ROM instead of the UEFI 71 | shell. The Linux kernel, with a provided Go based user-space, can then load the 72 | runtime kernel. The LinuxBoot paradigm enables writing traditional firmware 73 | applications such as boot loader, debugging, diagnosis, and error detection 74 | applications as cross-architecture and cross-platform portable Linux 75 | applications. 76 | 77 | When Linux boots it needs a root file system with utilities. One such root 78 | filesystem used for LinuxBoot is based on u-root standard utilities written in 79 | Go. The following diagram shows the current state of the UEFI boot process and 80 | what is planned for the transition to LinuxBoot. 81 | 82 | [![comparison of UEFI boot and LinuxBoot](./images/UEFI-versus-LinuxBoot.svg)](./images/UEFI-versus-LinuxBoot.svg) 83 | 84 | ## Benefits of using the Go user-space environment and compiler 85 | 86 | Go is a systems programming language created by Google. Go has strong typing, 87 | language level support for concurrency, inter-process communication via 88 | channels, runtime type safety and other protective measures, dynamic allocation 89 | and garbage collection, and closures. Go has a package name notation similar to 90 | Java that makes it clear to determine what packages a given program needs. 91 | 92 | The modern language constructs make Go a much safer language than C. This 93 | safety is critical for network-attached embedded systems, which usually have 94 | network utilities written in C, including web servers, network servers 95 | including `sshd`, and programs that provide access to a command interpreter, 96 | itself written in C. All are proving to be vulnerable to the attack-rich 97 | environment that the Internet has become. 98 | 99 | Even the most skilled programmers can make mistakes that in C can be 100 | unrecoverable, especially on network connected systems. Currently, even the 101 | lowest-level firmware in our PCs, printers, and thermostats is 102 | network-connected. These programming mistakes are either impossible to make in 103 | Go or, if made, are detected at runtime and result in the program exiting. 104 | 105 | The case for using a high-level, safe language like Go in low level embedded 106 | firmware might be stronger than for user programs, because exploits at the 107 | firmware level are nearly impossible to detect and mitigate. 108 | 109 | The challenge to using Go in a storage-constrained environment such as firmware 110 | is that advanced language features lead to big binaries. Even a date program is 111 | about 2 MiB. One Go binary, implementing one function, is twice as large as a 112 | BusyBox binary implementing many functions. Currently, a typical BIOS FLASH 113 | part is 16 MiB. Fitting many Go binaries into a single BIOS flash part is not 114 | practical. The Go compiler is fast and its sheer speed suggests a solution 115 | of having programs compiled only when they are used. With this approach, you 116 | can build a root file system that has almost no binaries except the Go compiler 117 | itself. The compiled programs and packages can be saved to a RAM-based file 118 | system. Another solution is to compile everything together into one 119 | BusyBox-style program. Alternatively, programs can be fetched over the network, 120 | but compiling dynamically with Go or creating a BusyBox program are the 121 | recommended solutions. 122 | 123 | ## Benefits of LinuxBoot with UEFI servers 124 | 125 | Most server firmware is based on Intel’s Universal Extensible Firmware 126 | Interface (UEFI). LinuxBoot provides the following benefits over UEFI: 127 | 128 | Reliability 129 | 130 | * Improves boot reliability by replacing lightly-tested firmware drivers with 131 | hardened Linux drivers 132 | * Proven approach for almost 20 years in military, consumer electronics, and 133 | supercomputers – wherever reliability and performance are paramount 134 | * Fault Tolerance - Linux isolates processes** **(for example, when `pxeboot` 135 | fails catastrophically, `diskboot` still works afterwards) 136 | 137 | Security 138 | 139 | * Move “Ring 0” boot loaders to “Ring 3” 140 | * `pxeboot` and `diskboot` do parsing and other logic in user-space 141 | * Go provides memory safety and type safety 142 | * A buggy parser is much less likely to affect other programs 143 | * Kernel security patches can apply to firmware 144 | 145 | Flexibility 146 | 147 | * Can be used with coreboot, u-boot, OpenPOWER Abstraction Layer (OPAL), 148 | SlimBootLoader, ARM Trusted Firmware (ATF) 149 | * Can boot multiple operating systems (Linux, Berkeley UNIX (BSD), XEN, 150 | Windows) 151 | * Supports the following server mainboards: 152 | * QEMU emulated Q35 systems 153 | * [Intel S2600WF](https://trmm.net/S2600wf) 154 | * [Dell R630](https://trmm.net/NERF) 155 | * Winterfell Open Compute node 156 | * Leopard Open Compute node 157 | * Tioga Pass Open Compute node 158 | * Monolake Open Compute node (not tested) 159 | 160 | Boot speed 161 | 162 | * Improves boot time by removing unnecessary code; typically makes boot 20 163 | times faster 164 | 165 | Customization 166 | 167 | * Allows customization of the initramfs runtime to support site-specific needs 168 | (both device drivers as well as custom executables) 169 | 170 | Engineering Productivity 171 | 172 | * Write a driver once, not twice 173 | * Linux is **open, measurable, reproducible, and straightforward to update** 174 | * Linux already has drivers for almost everything 175 | * Kernel Engineers = Firmware Engineers 176 | * Many more Engineers know Linux than know UEFI 177 | * Reduced build time 178 | * **30s** for initramfs 179 | * **15s** for kernel (incremental) 180 | * **~15s** to repack the bios image (using fiano/utk) 181 | * **Total: ~1m** for a new full bios image, ready to be tested 182 | * Testing and debugging 183 | * `diskboot` and `pxeboot` already have unit tests 184 | * Easier to write tests using resources (like network) with Linux 185 | * Open-source projects such as u-root follow excellent software practices 186 | such as running automated test on each submitted change 187 | * Much easier to debug Go user-space applications 188 | * Test with a kernel in QEMU 189 | -------------------------------------------------------------------------------- /src/odroid.md: -------------------------------------------------------------------------------- 1 | # ODROID boot chain 2 | 3 | The [ODROID-N2](https://wiki.odroid.com/odroid-n2/hardware) comes with a SPI 4 | flash as well as a connector for an eMMC flash and an SD card slot. The SoC is 5 | an [Amlogic S922X which can boot from all those storages](https://wiki.odroid.com/odroid-n2/software/boot_sequence), 6 | depending on GPIO configuration and a fallback flow in the mask ROM. 7 | For booting from SPI flash, the ODROID-N2 board has a switch, and comes with 8 | [Petitboot](./petitboot.md) preinstalled[^1]. 9 | 10 | The SPI flash boot flow is as follows: 11 | 12 | ```mermaid 13 | flowchart LR 14 | maskrom["mask ROM"] 15 | spl["U-Boot SPL"] 16 | uboot["U-Boot main"] 17 | petitboot(["petitboot"]) 18 | maskrom-->spl-->uboot-->petitboot-->OS 19 | ``` 20 | 21 | - [U-Boot SPL](https://docs.u-boot.org/en/latest/usage/spl_boot.html) 22 | initializes DRAM and loads U-Boot main ("proper") 23 | - U-Boot main is set up to directly load Linux with Petitboot, which implements 24 | LinuxBoot 25 | 26 | ## See also 27 | 28 | - [ODROID forum discussion on porting Petitboot to ODROID-N2]( 29 | https://forum.odroid.com/viewtopic.php?f=182&t=33873) 30 | 31 | [^1]: 32 | -------------------------------------------------------------------------------- /src/openpower.md: -------------------------------------------------------------------------------- 1 | # OpenPOWER boot chain 2 | 3 | ```mermaid 4 | flowchart LR 5 | skiroot(["skiroot (petitboot)"]) 6 | SBEs-->hostboot-->skiboot-->skiroot-->OS 7 | ``` 8 | 9 | - [Self-boot engines](https://github.com/open-power/sbe) (SBE) are split 10 | between an on-chip ROM and an external EEPROM 11 | - [hostboot](https://github.com/open-power/hostboot) is a C++ boot loader that 12 | does DRAM initialization provides runtime services to skiboot or a hypervisor 13 | - [skiboot](https://github.com/open-power/skiboot) is a C boot loader and 14 | runtime firmware for OpenPOWER that loads skiroot. 15 | 16 | skiroot is a term used to describe the LinuxBoot implementation for OpenPOWER. 17 | A skiroot repository or package does not exist. The term is only used in the 18 | kernel configuration, `skiroot_defconfig`.[^1] 19 | 20 | ## See also 21 | 22 | - [coreboot and Heads as an alternative firmware for OpenPOWER Talos 23 | II](https://openpower.foundation/blog/coreboot-on-talos2/) 24 | 25 | [^1]: 26 | -------------------------------------------------------------------------------- /src/petitboot.md: -------------------------------------------------------------------------------- 1 | # Petitboot 2 | 3 | petitboot is a Linux user-space application written in C that calls `kexec`. 4 | The `kexec` installed in the initramfs is not the mainline kexec-tools 5 | implementation, but a smaller implementation named 6 | [kexec-lite](https://github.com/antonblanchard/kexec-lite). It is claimed to be 7 | roughly 32 KB compared to kexec-tools, which is roughly 200 KB.[^1] 8 | 9 | [^1]: 10 | -------------------------------------------------------------------------------- /src/talks-news.md: -------------------------------------------------------------------------------- 1 | # Coverage 2 | 3 | ## Talks 4 | 5 | | Date | Presenter | Title | 6 | |------|-----------|-------| 7 | | 12/27/2016 | Trammell Hudson | [Bootstraping a slightly more secure laptop](https://trmm.net/Heads_33c3) | 8 | | 10/27/2017 | Ron Minnich | Replace your exploit-ridden firmware with a Linux kernel ([YouTube](https://www.youtube.com/watch?v=iffTJ1vPCSo), [slides](https://schd.ws/hosted_files/osseu17/84/Replace%20UEFI%20with%20Linux.pdf)) | 9 | | 12/29/2017 | Trammell Hudson | [Bringing Linux back to the server BIOS with LinuxBoot](https://trmm.net/LinuxBoot_34c3) | 10 | | 09/13/2018 | Andrea Barberio, David Hendricks | [Open Source Firmware @ Facebook](https://www.osfc.io/2018/talks/open-source-firmware-facebook/) | 11 | | 10/02/2018 | Andrea Barberio, David Hendricks | [Turning Linux Engineers into Firmware Engineers](https://2018ocpregionalsummit.sched.com/event/F8ax/turning-linux-engineers-into-firmware-engineers) ([slides](https://insomniac.slackware.it/static/2018_ocp_regional_summit_linuxboot_at_facebook.pdf), [YouTube](https://www.youtube.com/watch?v=i84df1z6mdI)) | 12 | | 06/15/2024 | Marta Lewandowska | [No more boot loader: Please use the kernel instead](https://pretalx.com/devconf-cz-2024/talk/W3AVCT/) | 13 | 14 | * [Make Your System Firmware Faster, More Flexible and Reliable with LinuxBoot](https://www.usenix.org/conference/lisa18/presentation/barberio) 15 | by [David Hendricks](https://github.com/dhendrix) and 16 | [Andrea Barberio](https://github.com/insomniacslk) at 17 | [LISA 2018](https://www.usenix.org/conference/lisa18) 18 | ([slides](https://insomniac.slackware.it/static/2018_lisa_linuxboot_at_facebook.pdf)) 19 | (2018-10-31) 20 | * [Open Source Firmware - A love story](https://www.youtube.com/watch?v=xfqKm190dbU) 21 | by [Philipp Deppenwiese](https://cybersecurity.9elements.com) 22 | at [35c3](https://events.ccc.de/congress/2018) 23 | ([slides](https://cdn.media.ccc.de/congress/2018/slides-h264-hd/35c3-9778-deu-eng-Open_Source_Firmware_hd-slides.mp4)) 24 | (2018-12-27) 25 | * [Open Source Firmware at Facebook](https://fosdem.org/2019/schedule/event/open_source_firmware_at_facebook/) 26 | by [David Hendricks](https://github.com/dhendrix) 27 | and [Andrea Barberio](https://github.com/insomniacslk) 28 | at [FOSDEM 2019](https://fosdem.org/2019/) 29 | ([video](https://video.fosdem.org/2019/K.4.401/open_source_firmware_at_facebook.mp4)) 30 | ([slides](https://insomniac.slackware.it/static/2019_fosdem_linuxboot_at_facebook.pdf)) 31 | (2019-02-03) 32 | * [Kexec Evolutions for LinuxBoot](https://www.osfc.io/2022/talks/kexec-evolutions-for-linuxboot/) 33 | by David Hu at OSFC 2021 34 | * [No more boot loader: Please use the kernel instead](https://pretalx.com/devconf-cz-2024/talk/W3AVCT/) 35 | at 2024 DevConf 36 | 37 | ## News 38 | 39 | | Date | Website | Title | 40 | |------|---------|-------| 41 | | 01/25/2018 | Linux Foundation | [System Statup gets a Boost with new LinuxBoot project](https://www.linuxfoundation.org/blog/system-startup-gets-a-boost-with-new-linuxboot-project/) | 42 | | 02/15/2018 | Linux Journal | [Linux Journal: FOSS Project Spotlight: LinuxBoot](https://www.linuxjournal.com/content/foss-project-spotlight-linuxboot/) | 43 | | 03/08/2018 | LWN | [LWN.net: LinuxBoot: Linux as firmware](https://lwn.net/Articles/748586/) | 44 | | 06/21/2018 | Phoronix | [Equus WHITEBOX OPEN: A Line Of Coreboot/LinuxBoot-Ready Xeon Scalable Servers](https://www.phoronix.com/news/Equus-WHITEBOX-OPEN) | 45 | | 02/06/2019 | Phoronix | [At Just Over One Year Old, LinuxBoot Continues Making Inroads At Facebook & Elsewhere](https://www.phoronix.com/news/LinuxBoot-2019) | 46 | | 03/14/2019 | Facebook | [Facebook's LinuxBoot-powered F-16 high-performance fabric network](https://code.fb.com/data-center-engineering/f16-minipack/) | 47 | | 03/10/2023 | Phoronix | [Lenovo Begins Supporting LinuxBoot Firmware With ByteDance](https://www.phoronix.com/news/Lenovo-LinuxBoot-ByteDance) | 48 | | 07/08/2024 | LWN | [Giving bootloaders the boot with nmbl](https://lwn.net/Articles/979789) | 49 | -------------------------------------------------------------------------------- /src/tools-evaluation.md: -------------------------------------------------------------------------------- 1 | # Evaluation of tools 2 | 3 | Three general questions guide all software projects: 4 | 5 | - what exists already? (implementations, tools and build systems) 6 | - what needs development? (UIs and such) 7 | - what is a good environment? (build + runtime) 8 | 9 | Not only do we want to answer those questions. We also keep track of the options 10 | and decision process in this book in order for readers to make sense. 11 | 12 | There are many existing tools already that we can leverage to implement the idea 13 | of using Linux to boot into an operating system. 14 | 15 | ## Root filesystem 16 | 17 | Linux needs a root filesystem with at least one binary that is called 18 | [`init`](https://docs.kernel.org/admin-guide/init.html). Since booting a system 19 | is a cumbersome task, additional tools aid in both development and investigating 20 | possible issues. 21 | 22 | ### Core utilities 23 | 24 | Unix already came with lots of little utilities for the user of the system, 25 | which may be anyone from a system developer to an administrator of a shared or 26 | provided system, or an end user. Further tools have been created over the years, 27 | and the [GNU core utilities](https://en.wikipedia.org/wiki/GNU_Core_Utilities) 28 | are essentially a collection of tools resulting from merging other collections. 29 | Note that there are still many other utilities that are not part of coreutils. 30 | At the same time, there are multiple other implementations now, which differ in 31 | terms of arguments and flags and possibly additional utilities they include. 32 | 33 | | tool | language | license | usage | 34 | | -------------------------------------------------------- | -------- | ------------ | ----------------------- | 35 | | [BusyBox](https://busybox.net/) | C | GPLv2 | Heads | 36 | | [toybox](http://landley.net/toybox) | C | 0BSD | Android | 37 | | [GNU coreutils](https://www.gnu.org/software/coreutils/) | C | GPLv3 | not for LinuxBoot | 38 | | [u-root](https://u-root.org) | Go | BSD 3-Clause | ByteDance, Google et al | 39 | | [uutils/coreutils](http://uutils.github.io/) | Rust | MIT | not for LinuxBoot | 40 | 41 | ### kexec implementations 42 | 43 | While [kexec itself is a Linux syscall](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/uapi/linux/kexec.h), 44 | it is not a one-shot operation. Loading multiple segments into memory, 45 | synchronizing and unmounting file systems, and the eventual syscall to 46 | [reboot](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/uapi/linux/reboot.h) 47 | belong to the procedure. In addition, there are architecture specifics to take 48 | into account. Thus, there are multiple implementations of kexec, which are Linux 49 | programs that offer their own interfaces again to pass extra arguments. Besides 50 | those standalone implementations, there are also specialized boot loaders based 51 | on kexec that have their own extra logic, such as FreeBSD's kload or petitboot. 52 | 53 | | tool | language | license | usage | 54 | | ---------------------------------------------------------------------------------------------------------------------------------------- | --------- | ------------ | ---------------- | 55 | | [kexec-tools](https://git.kernel.org/pub/scm/utils/kernel/kexec/kexec-tools.git) ([GitHub mirror](https://github.com/horms/kexec-tools)) | C | GPLv2 | Heads, Petitboot | 56 | | [systemd](https://systemd.io/) (wrapper) | C | LGPL-2.1+ | systemd on UEFI | 57 | | [kexecboot](https://github.com/kexecboot/kexecboot) | C | GPLv2 | ? | 58 | | u-root (CLI+mod) | Go | BSD 3-Clause | Google et al | 59 | | [kexlinux](https://github.com/im-0/kexlinux) | Rust | LGPL-3.0+ | ? | 60 | -------------------------------------------------------------------------------- /src/u-root-qemu-demo.md: -------------------------------------------------------------------------------- 1 | # u-root demo with QEMU 2 | 3 | You can try out LinuxBoot without needing to build anything! You can try out 4 | LinuxBoot needing only 3 commands. 5 | 6 | We have made Initial Ram File System (initramfs) images available for four 7 | architectures: arm, aarch64, amd64 (a.k.a. x86_64), and riscv64. 8 | 9 | For now, we only have a kernel ready for x86_64, so the instructions below 10 | apply to that. 11 | 12 | First, you can get the initramfs image, which mainly contains Go programs from 13 | the u-root project. 14 | 15 | ```bash 16 | curl -L -o u-root.cpio.xz https://github.com/linuxboot/u-root-builder/releases/download/v0.0.1/u-root_amd64_all.cpio.xz 17 | ``` 18 | 19 | Next, you will need to get a kernel. We use a pre-built kernel from Arch Linux. 20 | 21 | ```bash 22 | curl -L -o linux.tar.zst https://archlinux.org/packages/core/x86_64/linux/download/ 23 | tar -xf linux.tar.zst 24 | ``` 25 | 26 | Now you are ready to test LinuxBoot out. 27 | 28 | ```bash 29 | qemu-system-x86_64 -enable-kvm -machine q35 -nographic -append "console=ttyS0" \ 30 | -kernel usr/lib/modules/*/vmlinuz -initrd u-root.cpio.xz 31 | ``` 32 | 33 | Or, for example, on Darwin: 34 | 35 | ```bash 36 | qemu-system-x86_64 -machine q35 -nographic -append "console=ttyS0" \ 37 | -kernel usr/lib/modules/*/vmlinuz -initrd u-root.cpio.xz 38 | ``` 39 | 40 | You will see the following: 41 | 42 | ```text 43 | [... varying message or two depending on qemu version and OS] 44 | 2023/12/12 22:37:52 Welcome to u-root! 45 | _ 46 | _ _ _ __ ___ ___ | |_ 47 | | | | |____| '__/ _ \ / _ \| __| 48 | | |_| |____| | | (_) | (_) | |_ 49 | \__,_| |_| \___/ \___/ \__| 50 | 51 | /# 52 | ``` 53 | 54 | You can type uname: 55 | 56 | ```text 57 | /# uname 58 | Linux 59 | /# 60 | ``` 61 | 62 | To exit qemu, just run the poweroff command: 63 | 64 | ```text 65 | /# poweroff 66 | [ 14.442914] reboot: Power down 67 | ``` 68 | 69 | You have just run your first LinuxBoot kernel. 70 | -------------------------------------------------------------------------------- /src/use-cases.md: -------------------------------------------------------------------------------- 1 | # Use cases 2 | 3 | The general concept of using a Linux kernel to boot into an operating system 4 | sounds simple at first glance. The challenges in the details, in part not only 5 | limited to using Linux, are being discussed in this chapter, with ideas on 6 | solving specific problems in the domain of bootloaders. 7 | 8 | ## Constrained environments 9 | 10 | Booting a system means dealing with constraints. Those can have either of two 11 | effects: spark creativity or keep you from pursuing a goal. On foot, you can 12 | only reach as far in a day, whereas a vehicle gets you much further. With 13 | LinuxBoot, we want to take the chance to reevaluate contemporary designs and go 14 | beyond. 15 | 16 | When it comes to hardware, the vendor would choose the parts for their product 17 | and consider them in their price calculation. 18 | 19 | One main constraint is the initial boot source. A System-on-Chip (SoC) typically 20 | starts off with a mask ROM and continues with a simple storage part, which may 21 | range from a SPI flash of a few megabytes up to eMMC or SD cards of hundreds of 22 | megabytes or even gigabytes. 23 | 24 | We neglect other storages here that are attached via NVMe, SATA or other 25 | high-speed buses, because those are commonly not supported by mask ROMs. They 26 | are, on the other hand, what a bootloader offers to boot from, as well as 27 | network sources. 28 | 29 | ## Embedded devices 30 | 31 | Many devices, nowadays known as IoT (Internet of Things), appliances, or 32 | similar, have a narrow use case. They are meant to perform a specific set of 33 | tasks, and thus can be tailored for it. In hardware terms, that often means an 34 | SoC, a bit of storage, and peripherals. Debug interfaces are reduced or removed 35 | for the final product. 36 | 37 | ## Desktop, laptop, workstation and server systems 38 | 39 | At this point, many systems are still based on x86 processors, coming with a SPI 40 | flash on the board. While laptops and desktops mostly have a mere 16 or 32 41 | megabytes to offer, high-end servers and workstations already have 64, and even 42 | a second whole system called the Board Management Controller (BMC), which has 43 | its own firmware and corresponding storage. Designs around those constraints 44 | vary among OEMs. 45 | 46 | Note that it need not be that way. Arm based, RISC-V based and other systems 47 | already show that you can expect more, such as booting off eMMC. Laptops and 48 | desktop boards in that range are available as of now, even some servers and 49 | workstations. 50 | 51 | ## Single Board Computers (SBCs) 52 | 53 | The SBC market has grown to such a degree that credit card size boards nowadays 54 | comes with both small storage parts that can act as boot sources as well as PCIe 55 | connectors that can hold NVMes of gigabytes and terabytes of storage. This gives 56 | us the opportunity to work out a boot flow that provides the end user with a 57 | very rich environment already early on before the main operating system is 58 | loaded. 59 | -------------------------------------------------------------------------------- /src/utilities/UEFI_Tool_Kit.md: -------------------------------------------------------------------------------- 1 | # UEFI Tool Kit 2 | 3 | Authors: Ryan O'Leary, Gan Shun Lim and Andrea Barberio 4 | 5 | In previous chapters, you learned how to read a raw ROM image from a flash 6 | part. If you've been following along, you know the next step is to insert a 7 | Linux kernel. 8 | 9 | Inspecting and modifying ROM images is tricky and can involve a fair amount of 10 | tinkering. These images typically contain a number of file systems, drivers, 11 | tables, data structures and opaque blobs. They also differ significantly from the 12 | UNIX model of a file systems, thus cannot be reasonably mounted in Linux. 13 | 14 | UEFI Tool Kit (UTK) is intended to be a one-stop-shop for reading, writing and 15 | modifying UEFI images -- the most common type of firmware image for x86 16 | systems. UTK can parse a number of data structures including UEFI firmware 17 | volumes, Intel firmware descriptors and FIT. 18 | 19 | In this chapter, we'll go over how to: 20 | 21 | 1. Install UTK 22 | 2. Inspect ROMs 23 | 3. Modify ROMs 24 | 4. Common pitfalls 25 | 5. Extend UTK with additional commands 26 | 27 | ## Synopsis 28 | 29 | ``` 30 | make bzImage 31 | sudo flashrom -r /tmp/ROM.bin 32 | utk /tmp/ROM.bin replace_pe32 Shell arch/86/boot/bzImage save /tmp/NEWROM.bin 33 | sudo flashrom -w /tmp/NEWROM.bin 34 | ``` 35 | 36 | ## Quick start 37 | 38 | We assume you have a way to read and write the FLASH into a file. 39 | 40 | Let's assume you have read FLASH into an image called ROM.bin and you 41 | have a kernel, called bzImage, which you want to insert into 42 | ROM.bin. Be sure the kernel is buildable as an EFI driver (DXE); see 43 | the pitfalls section. The easiest option is to replace the UEFI shell. This 44 | is a quick and easy way to get started. In the long term, you want to 45 | remove as much of UEFI as possible, but replacing the shell is always 46 | our first step on a new board. 47 | 48 | Get the tool: 49 | 50 | ``` 51 | go get -u github.com/linuxboot/fiano/cmds/utk 52 | ``` 53 | 54 | Replace the shell: 55 | 56 | ``` 57 | utk ROM.bin replace_pe32 Shell bzImage save NEWROM.bin 58 | ``` 59 | 60 | After that, you can flash NEWROM.bin and test. If anything goes wrong, such as 61 | not enough space, you will need to refer to the more detailed instructions 62 | below. 63 | 64 | ## Installation 65 | 66 | At the time of writing, you must clone and build UTK from source -- binary 67 | distributions are not officially available. The source code resides in the 68 | [Fiano Github project](https://github.com/linuxboot/fiano/). 69 | 70 | Aside: what is the difference between Fiano and UTK? The Fiano project contains 71 | a few more tools besides UTK, but UTK is a big element. 72 | 73 | We'll assume you already have Go installed. Check your installation with: 74 | 75 | ``` 76 | $ go version 77 | go version go1.11 linux/amd64 78 | ``` 79 | 80 | Linux and the latest stable version of Go are recommended. Either download the 81 | official binary distributions of Go or install from source. See 82 | [https://golang.org/](https://golang.org/) for details. 83 | 84 | With Go, download and install UTK: 85 | 86 | ``` 87 | go get -u github.com/linuxboot/fiano/cmds/utk 88 | ``` 89 | 90 | Running the above line installs `utk` to your `$GOPATH/bin` directory (or 91 | `$HOME/go/bin` if the `GOPATH` environment variable is not set). Adding this 92 | directory to your `$PATH` is recommended. 93 | 94 | Make sure it works with: 95 | 96 | ``` 97 | $ utk -h 98 | Usage: utk [flags] [0 or more operations] 99 | 100 | Operations: 101 | cat : cat a file with a regexp that matches a GUID 102 | comment : Print one arg 103 | count : count the number of each firmware type 104 | dump : dump a firmware file 105 | dxecleaner : automates removal of UEFI drivers 106 | dxecleaner_blacklist : automates removal of UEFI drivers with a blacklist file 107 | extract : extract the files to a directory 108 | find : find a file by GUID or Name 109 | flatten : prints a JSON list of nodes 110 | insert_after : insert a file after another file 111 | insert_before : insert a file before another file 112 | insert_end : insert a file at the end of a firmware volume 113 | insert_front : insert a file at the beginning of a firmware volume 114 | json : produce JSON for the full firmware volume 115 | remove : remove a file from the volume 116 | remove_pad : remove a file from the volume and replace it with a pad file of the same size 117 | repack : repack a per file compressed fv to a nested compressed fv 118 | replace_pe32 : replace a pe32 given a GUID and new file 119 | save : assemble a firmware volume from a directory tree 120 | table : print out important information in a pretty table 121 | validate : perform extra validation checks 122 | ``` 123 | 124 | Don't fret if your list of operations differs. UTK is an evolving project! 125 | 126 | ## Inspecting ROMs 127 | 128 | Throughout this section, we'll demonstrate commands for inspecting a UEFI 129 | image. When confronted with a new image, run these commands to get a "lay of 130 | the land". 131 | 132 | Start by downloading the UEFI image used in these examples: 133 | 134 | ``` 135 | wget https://github.com/linuxboot/fiano/raw/master/integration/roms/OVMF.rom 136 | ``` 137 | 138 | Aside: alternatively, all UTK operations should work with your own UEFI images. 139 | Simply substitute "OVMF.rom" with your own UEFI image in all the examples 140 | below. If you encounter any problems, please file an issue at 141 | [https://github.com/linuxboot/fiano/issues](https://github.com/linuxboot/fiano/issues). 142 | 143 | First, it is advisable to print a count of each firmware element: 144 | 145 | ``` 146 | $ utk OVMF.rom count 147 | { 148 | "FirmwareTypeCount": { 149 | "BIOSRegion": 1, 150 | "File": 118, 151 | "FirmwareVolume": 5, 152 | "Section": 365 153 | }, 154 | "FileTypeCount": { 155 | "EFI_FV_FILETYPE_APPLICATION": 2, 156 | "EFI_FV_FILETYPE_DRIVER": 94, 157 | "EFI_FV_FILETYPE_DXE_CORE": 1, 158 | "EFI_FV_FILETYPE_FFS_PAD": 7, 159 | "EFI_FV_FILETYPE_FIRMWARE_VOLUME_IMAGE": 1, 160 | "EFI_FV_FILETYPE_FREEFORM": 3, 161 | "EFI_FV_FILETYPE_PEIM": 7, 162 | "EFI_FV_FILETYPE_PEI_CORE": 1, 163 | "EFI_FV_FILETYPE_RAW": 1, 164 | "EFI_FV_FILETYPE_SECURITY_CORE": 1 165 | }, 166 | "SectionTypeCount": { 167 | "EFI_SECTION_DXE_DEPEX": 44, 168 | "EFI_SECTION_FIRMWARE_VOLUME_IMAGE": 2, 169 | "EFI_SECTION_GUID_DEFINED": 1, 170 | "EFI_SECTION_PE32": 99, 171 | "EFI_SECTION_RAW": 21, 172 | "EFI_SECTION_USER_INTERFACE": 99, 173 | "EFI_SECTION_VERSION": 99 174 | } 175 | } 176 | ``` 177 | 178 | The definition of a "Firmware Element" is in order. Firmware images are 179 | hierarchical and can be represented as a tree. Each node in the tree is a 180 | "Firmware Element". Each element has a type such as "BIOSRegion", 181 | "FirmwareVolume", "File" and "Section" as seen above. Files (and sections) 182 | themselves have an additional type dictated by the UEFI spec. There are three 183 | major file types you should be aware of: 184 | 185 | - `EFI_FV_FILETYPE_DRIVER`: This is the most numerous file type and is often 186 | called a "DXE". They persist in memory even after their main function exits. 187 | - `EFI_FV_FILETYPE_APPLICATION`: Applications do not persist in memory after 188 | exiting. For example, the EFI Shell is an EFI Application. 189 | - `EFI_FV_FILETYPE_FIRMWARE_VOLUME_IMAGE`: These file types allow nesting 190 | firmware volumes. You will see this when an entire firmware volume is 191 | compressed. 192 | 193 | TODO: Diagram showing a tree of these firmware elements. 194 | 195 | To view a human-readable tree of all the firmware elements, types and sizes, 196 | run: 197 | 198 | ``` 199 | $ utk OVMF.rom table | less 200 | Node GUID/Name Type Size 201 | BIOS 0x400000 202 | FV FFF12B8D-7696-4C8B-A985-2747075B4F50 0x84000 203 | Free 0x0 204 | FV 8C8CE578-8A3D-4F1C-9935-896185C32DD3 0x348000 205 | File 9E21FD93-9C72-4C15-8C4B-E77F1DB2D792 EFI_FV_FILETYPE_FIRMWARE_VOLUME_IMAGE 0x1256a7 206 | Sec EFI_SECTION_GUID_DEFINED 0x12568f 207 | Sec EFI_SECTION_RAW 0x7c 208 | Sec EFI_SECTION_FIRMWARE_VOLUME_IMAGE 0xe0004 209 | FV 8C8CE578-8A3D-4F1C-9935-896185C32DD3 0xe0000 210 | File 1B45CC0A-156A-428A-AF62-49864DA0E6E6 EFI_FV_FILETYPE_FREEFORM 0x2c 211 | Sec EFI_SECTION_RAW 0x14 212 | File FFFFFFFF-FFFF-FFFF-FFFF-FFFFFFFFFFFF EFI_FV_FILETYPE_FFS_PAD 0x40 213 | File 52C05B14-0B98-496C-BC3B-04B50211D680 EFI_FV_FILETYPE_PEI_CORE 0xc4fa 214 | Sec EFI_SECTION_RAW 0x3c 215 | Sec EFI_SECTION_PE32 0xc484 216 | Sec PeiCore EFI_SECTION_USER_INTERFACE 0x14 217 | Sec EFI_SECTION_VERSION 0xe 218 | ... 219 | ``` 220 | 221 | This format is compact and easy for humans reading, but not ideal for machine 222 | consumption. Use the `json` command to print everything (including much more 223 | metadata) as JSON: 224 | 225 | ``` 226 | utk OVMF.rom json | less 227 | ``` 228 | 229 | Combine `utk` with the JSON query command, `jq` (`sudo apt-get install jq`), 230 | and other UNIX commands to quickly write powerful queries. For example, the 231 | following lists all the GUIDs, sorted and without duplicates: 232 | 233 | ``` 234 | $ utk OVMF.rom json | jq -r '..|.GUID?|select(type=="string")' | sort -u 235 | 00000000-0000-0000-0000-000000000000 236 | 0167CCC4-D0F7-4F21-A3EF-9E64B7CDCE8B 237 | 0170F60C-1D40-4651-956D-F0BD9879D527 238 | 021722D8-522B-4079-852A-FE44C2C13F49 239 | 025BBFC7-E6A9-4B8B-82AD-6815A1AEAF4A 240 | ... 241 | ``` 242 | 243 | To only print the JSON for specific files, use the find command: 244 | 245 | ``` 246 | # The find command uses a regex to match on the name or GUID. 247 | # These three examples find and print the JSON for the same file: 248 | $ utk OVMF.rom find 'Sh.*' 249 | $ utk OVMF.rom find 'Shell' 250 | $ utk OVMF.rom find 7C04A583-9E3E-4F1C-AD65-E05268D0B4D1 251 | { 252 | "Header": { 253 | "UUID": { 254 | "UUID": "7C04A583-9E3E-4F1C-AD65-E05268D0B4D1" 255 | }, 256 | "Type": 9, 257 | "Attributes": 0 258 | }, 259 | "Type": "EFI_FV_FILETYPE_APPLICATION", 260 | "Sections": [ 261 | { 262 | "Header": { 263 | "Type": 21 264 | }, 265 | "Type": "EFI_SECTION_USER_INTERFACE", 266 | "ExtractPath": "", 267 | "Name": "Shell" 268 | }, 269 | ... 270 | ], 271 | "ExtractPath": "", 272 | "DataOffset": 24 273 | } 274 | ``` 275 | 276 | Note that UEFI uses GUIDs to identify files. Some files also have a name which 277 | is stored within the file's UI section. Like `find`, most of UTKs commands let 278 | you match a file by its name or GUID. 279 | 280 | The examples up until now have only dealt with file metadata and not the file's 281 | contents. The `extract ` command extracts all the files from the image and 282 | saves them to ``. `/summary.json` lists all the paths to the extracted 283 | files along with their metadata. 284 | 285 | ``` 286 | utk OVMF.rom extract OVMF/ 287 | ``` 288 | 289 | After modifying the files, they can be reassembled with: 290 | 291 | ``` 292 | utk OVMF/ save OVMF2.rom 293 | ``` 294 | 295 | ## Modifying ROMs 296 | 297 | First, let's verify the image works by running it inside QEMU. This step is not 298 | absolutely necessary, but gives us confidence the image works before and after 299 | each change we make. 300 | 301 | ``` 302 | qemu-system-x86_64 -bios OVMF.rom -nographic -net none 303 | ``` 304 | 305 | For the provided OVMF.rom image, this should boot to the EDK2 shell. 306 | 307 | TODO: include screenshot of the EDK2 shell 308 | 309 | Multiple commands can be used together to form a pipeline. The first argument 310 | always loads the image into memory and the last argument typically writes the 311 | output. The commands in between operate on the image in memory and are 312 | reminiscent of a UNIX pipeline. The general syntax is: 313 | 314 | ``` 315 | utk \ 316 | ... \ 317 | ... \ 318 | ... 319 | ``` 320 | 321 | To see the pipeline in action, we introduce two new commands: 322 | 323 | - `remove `: Remove a file from a firmware volume. The 324 | search has the same semantics as `find`. 325 | - `replace_pe32 `: Replace the pe32 section of a 326 | file with the given file. The search has the same semantics as `find`. The 327 | file must be a valid pe32 binary. 328 | - `save `: Save the firmware image to the given file. Usually, this is the 329 | last command in a pipeline. 330 | 331 | The following pipeline removes some unnecessary drivers (anything that starts 332 | with Usb and the Legacy8259 driver which has the GUID 333 | 79ca4208-bba1-4a9a-8456-e1e66a81484e) and replaces the Shell with Linux. Often 334 | you need to remove drivers to make room for Linux which makes the pipeline 335 | convenient. This is the essence of LinuxBoot: 336 | 337 | ``` 338 | $ stat linux.efi 339 | linux.efi: Linux kernel x86 boot executable bzImage, version 4.17.0 340 | $ utk OVMF.rom \ 341 | remove 'Usb.*' \ 342 | remove 79ca4208-bba1-4a9a-8456-e1e66a81484e \ 343 | replace_pe32 Shell linux.efi \ 344 | save OVMF2.rom 345 | ``` 346 | 347 | That's all there to it! Try experimenting with the other commands such as 348 | insert. 349 | 350 | ## Common Pitfalls 351 | 352 | ### Kernel is not built as a DXE or has not enabled UEFI stub mode 353 | 354 | In order to be properly bootable as a DXE, kernels must have the following 355 | enabled: 356 | 357 | ``` 358 | CONFIG_EFI=y 359 | CONFIG_EFI_STUB=y 360 | ``` 361 | 362 | ### Files are missing from the Firmware Volume 363 | 364 | When UTK does not recognize the compression format used by the particular 365 | image, the files within it are not listed. 366 | 367 | In the wild, three compression schemes are common: 368 | 369 | | Compression | GUID | UTK Support | 370 | | ------------ | ------------------------------------ | ------------------------- | 371 | | Uncompressed | | Fully supported | 372 | | LZMA | EE4E5898-3914-4259-9D6E-DC7BD79403CF | Fully supported | 373 | | LZMA + x86 | D42AE6BD-1352-4BFB-909A-CA72A6EAE889 | Supported, but not tested | 374 | | Tianocore | A31280AD-481E-41B6-95E8-127F4C984779 | Not supported, see [#226](https://github.com/linuxboot/fiano/issues/226) | 375 | 376 | To determine which compression scheme you are using, search for the respective 377 | GUID in the json summary. 378 | 379 | ### File size too big 380 | 381 | ``` 382 | File size too big! File with GUID: XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX has length 543210, but is only 123450 bytes big 383 | ``` 384 | 385 | When saving a UEFI image, files are added successively to each firmware volume. 386 | The first file which overflows the volume's size causes this error. 387 | 388 | If you were inserting files, you will need to delete existing files to make room. 389 | 390 | There is a special cases where this error is generated without any operations: 391 | 392 | ``` 393 | utk OVMF.rom save OVMF2.rom 394 | ``` 395 | 396 | How can this be? No changes should be made to the image! 397 | 398 | Not quite (and the complete list of differences can be found in the "binary 399 | equality section") -- compressed volumes are recompressed. 400 | 401 | By default, UTK uses the Go compressor, which is generally worse than the 402 | compression found in most UEFI images. Pass `--systemXZ=xz` as the first 403 | argument to UTK to use a better compressor. 404 | 405 | ### (TODO for everything after this point) Arbitrary data before or after the image 406 | 407 | Find a general solution which works for all images is a topic of research: 408 | [#200](https://github.com/linuxboot/fiano/issues/200). 409 | 410 | ### Hard-coded addresses 411 | 412 | ### Binary equality 413 | 414 | TODO 415 | 416 | ## Extending UTK 417 | 418 | Visitor pattern means decoupling the structure from the operations. 419 | 420 | - pkg/uefi: structure 421 | - pkg/visitors: operations 422 | 423 | Good resources: 424 | 425 | 1. https://sourcemaking.com/design_patterns/visitor 426 | 2. https://en.wikipedia.org/wiki/Visitor_pattern 427 | 428 | A good visitor still works when new Firmware are introduced. A good Firmware 429 | still works when a new visitor is introduced. 430 | 431 | ### AST 432 | 433 | Abstract Syntax Tree -- this is a concept borrowed from compilers. When you're 434 | extracting the DXE to create a tree of structs containing a simplified model, 435 | you're essentially creating an AST. Then think about how patterns used in 436 | compiler architecture might apply to UTK. 437 | 438 | ### Visitor Interface 439 | 440 | Each visitor implements the following: 441 | 442 | ```go 443 | type Visitor interface { 444 | VisitFV(*FV) error 445 | VisitFile(*File) error 446 | VisitSection(*FileSection) error 447 | // ... 448 | } 449 | ``` 450 | 451 | Think of a visitor as an "action" or a "transformation" being applied on the 452 | AST. 453 | 454 | ### Visitor 455 | 456 | A struct implementing Visitor performs a transformation on the AST, for example: 457 | 458 | ```go 459 | type RenameDXE struct { 460 | before, after string 461 | } 462 | func (v *RenameDXE) VisitFV(fv *FV) error { 463 | // Recursively apply on files in the FV. 464 | for i := range fv.Files { 465 | fv.Files[i].Apply(v) 466 | } 467 | return nil 468 | } 469 | func (v *RenameDXE) VisitFile(f *File) error { 470 | if f.Type == FILETYPE_DXE && f.Name == v.before { 471 | f.Name = after 472 | } 473 | return nil 474 | } 475 | func (v *RenameDXE) VisitSection(s *FileSection) error { 476 | return nil 477 | } 478 | ``` 479 | 480 | You can imagine visitors being implemented for other actions, such as: 481 | 482 | - Remove a DXE with the given GUID from the AST 483 | - Replace a GUID with a file 484 | - Validate that all the nodes in the tree are valid 485 | - Find compressed files in the tree and decompress them 486 | - Assemble the AST back into an image. 487 | - Recursively write the AST to the filesystem (what you currently do with extract) 488 | - Print an overview of the files to the terminal for debugging 489 | - ... 490 | 491 | It is easy to add more visitors without modifying existing code. Each action can 492 | be in a separate file. 493 | 494 | ### Applying 495 | 496 | Visitors are applied to the AST. Each node in the AST has an "Apply" method, for 497 | example: 498 | 499 | ```go 500 | func (f *File) Apply(v *visitor) error { 501 | return v.VisitFile(f) 502 | } 503 | ``` 504 | 505 | This is so the visitors can be applied recursively over the AST. 506 | 507 | To apply the above RenameDXE visitor, you'd run: 508 | 509 | ```go 510 | v := &RenameDXE{"Shell", "NotShell"} 511 | fv.Apply(v) 512 | ``` 513 | 514 | ### Chaining Visitors Together 515 | 516 | It would be exciting/useful to be able to chain these small actions together 517 | through the command line. For example: 518 | 519 | ``` 520 | utk extract bios.rom \ 521 | remove a2dad2a-adadad-a2d2-ad23a3 \ 522 | remove 9d8cd98-d9c8d9-d9c8-9d8c8c \ 523 | replaceDXEWithFile bab8a98-a9ba89a-9aba-a98a9 linux.efi \ 524 | validate \ 525 | save new_bios.rom 526 | ``` 527 | 528 | Again, it is easy to write new actions in Go which modify nodes in the AST. 529 | Create a new file, new struct, and implement the visitFV/visitFile/visitSection 530 | methods to modify the AST. 531 | 532 | TODO: reference the UEFI spec. 533 | 534 | TODO: mention alternatives 535 | 536 | - binwalk 537 | - fresh0r/romdump 538 | - UEFITool 539 | - uefi-firmware-parser 540 | -------------------------------------------------------------------------------- /src/utilities/dut.md: -------------------------------------------------------------------------------- 1 | # DUT, a simple Device Under Test utility. 2 | 3 | Points of contact: [Ron Minnich](https://github.com/rminnich) 4 | 5 | DUT is a simple Device Under Test program that gives you control of a node. It is intended to make 6 | very fast startup and control easy. 7 | 8 | DUT is one program implementing three operations. The first, tester, is run on a test control system, such as your desktop; 9 | the second, called device, is run on the device; the third, called ssh and also run on the device, starts an 10 | ssh server assuming one is present. 11 | 12 | DUT is intended to be very limited, with more sophisticated operations, should they be 13 | needed, being done over SSH. 14 | 15 | DUT is found at github.com:linuxboot/dut. 16 | 17 | This chapter describes how we build and use DUT. 18 | 19 | ## Components 20 | 21 | DUT is intended to be built into a u-root image. First one must fetch it: 22 | ``` 23 | go get github.com/linuxboot/dut 24 | # ignore the warning message. 25 | ``` 26 | 27 | DUT source tree is structured such that a program called uinit is produced. This is convenient for u-root usage. 28 | 29 | Building it into a u-root image is easy: 30 | ``` 31 | go run $(GOPATH)/src/github.com/u-root/u-root -build=bb minimal github.com/linuxboot/dut/uinit 32 | ``` 33 | 34 | I almost always add an sshd to u-root; it's just too handy. U-root sshd does not support 35 | passwords, so you have to supply the public key: 36 | ``` 37 | go run $(GOPATH)/src/github.com/u-root/u-root -build=bb -files key.pub minimal github.com/linuxboot/dut/uinit github.com/u-root/u-root/xcmds/sshd 38 | ``` 39 | 40 | ### DUT on the device 41 | On boot, the standard init program will find dut, and run it. The standard mode on a device 42 | is device mode, and dut will bring up the ethernet, currently 43 | using 192.168.0.2, and assuming the tester is 192.168.0.1 (this should be fixed ...). 44 | It will then attempt to connect to a uinit running in 'tester' mode on 192.168.0.1. Once connected, it functions 45 | as a server and waits for requests. 46 | 47 | ### DUT on the controller 48 | Running on the controller is easy: 49 | ``` 50 | uinit -m tester 51 | ``` 52 | 53 | On the controller, the program waits for a connection and then starts issuing commands to the device. 54 | The controller has the option of calling the following RPC functions: 55 | ``` 56 | RPCWelcome - return a welcome message 57 | RPCExit - exit the testing mode 58 | RPCReboot - reboot the system 59 | RPCKexec - kexec a kernel 60 | RPCSsh - start the sshd 61 | ``` 62 | 63 | Each of these RPCs takes arguments and returns a result, with Welcome being the most fun: 64 | ``` 65 | ______________ 66 | < welcome to DUT > 67 | -------------- 68 | \ ^__^ 69 | \ (oo)\_______ 70 | (__)\ )\/\ 71 | ||----w | 72 | || || 73 | ``` 74 | 75 | The current tester mode performs an RPC sequence I use for DXE cleaning, namely, a Welcome, followed by a Reboot, followed 76 | by a Welcome. This sequence verifies that I can get network going from power on, do a reboot, and reconnect after 77 | a reboot. It's been good for finding out if a particular DXE can be removed. 78 | 79 | Once the second Welcome has happened, if an sshd is installed, it will have been started, and you can do additional commands. 80 | 81 | # Future work 82 | 83 | Obviously, much more can be done. But this is a useful foundation on which to build DUT environments. 84 | -------------------------------------------------------------------------------- /src/utilities/index.md: -------------------------------------------------------------------------------- 1 | # LinuxBoot Utilities 2 | 3 | In order to bootstrap, build and maintain LinuxBoot projects, we provide a 4 | handful of utilities for extracting, reducing, reworking, and stitching firmware 5 | images. 6 | -------------------------------------------------------------------------------- /theme/css/language-picker.css: -------------------------------------------------------------------------------- 1 | #language-list { 2 | left: auto; 3 | right: 10px; 4 | } 5 | 6 | [dir="rtl"] #language-list { 7 | left: 10px; 8 | right: auto; 9 | } 10 | 11 | #language-list a { 12 | color: inherit; 13 | } 14 | -------------------------------------------------------------------------------- /theme/head.hbs: -------------------------------------------------------------------------------- 1 | 5 | -------------------------------------------------------------------------------- /theme/js/language-picker.js: -------------------------------------------------------------------------------- 1 | (function addThemePicker() { 2 | const rightButtonsElement = document.querySelector('.right-buttons'); 3 | rightButtonsElement.insertAdjacentHTML("afterbegin", ` 4 | 10 | 18 | `); 19 | 20 | const language = document.documentElement.getAttribute("lang"); 21 | let langToggle = document.getElementById("language-toggle"); 22 | let langList = document.getElementById("language-list"); 23 | langToggle.addEventListener("click", (event) => { 24 | langList.style.display = 25 | langList.style.display == "block" ? "none" : "block"; 26 | }); 27 | let selectedLang = document.getElementById(language); 28 | if (selectedLang) { 29 | selectedLang.parentNode.classList.add("theme-selected"); 30 | } 31 | 32 | // The path to the root, taking the current language into account. 33 | let full_path_to_root = 34 | language == "en" ? `${mdbookPathToRoot}` : `${mdbookPathToRoot}../`; 35 | // The page path (mdbook only gives us access to the path to the Markdown file). 36 | let path = mdbookPath.replace(/\.md$/, ".html"); 37 | for (let lang of langList.querySelectorAll("a")) { 38 | if (lang.id == "en") { 39 | lang.href = `${full_path_to_root}${path}`; 40 | } else { 41 | lang.href = `${full_path_to_root}${lang.id}/${path}`; 42 | } 43 | } 44 | })(); 45 | --------------------------------------------------------------------------------