diff --git a/site/contrib.md b/site/contrib.md index 5362c74..074becf 100644 --- a/site/contrib.md +++ b/site/contrib.md @@ -47,7 +47,7 @@ Caleb La Grange with a narrower focus. Caleb focuses on several areas of development: * Build system. Caleb is responsible for improving and fixing the libreboot Make build -system. Specifically: binary blob management, automation, and reproducibility. +system. Specifically: automation, and reproducibility. * Hardware modification. Caleb has a passion for hardware alteration; soldering, desoldering, and testing libreboot software on the resulting hardware. * Board porting. Anything supported in Coreboot can be ported to libreboot, Caleb @@ -212,14 +212,6 @@ FSF would take me seriously, and I said yes. This is what started the early work on Libreboot. Joshua showed me all the problems my products had, and from that, the solution was clear: -A project needed to exist, providing a fully free version of coreboot, without -any binary blobs. At the time (and this is still true today), coreboot was not -entirely libre software and shipped with binary blobs by default. In particular, -CPU microcode updates were included by default, on all x86 machines. Working -with Joshua who reviewed my work, I created a fully free version of coreboot. -At first, it wasn't called Libreboot, and the work was purely intended for my -company (at that time called Gluglug) to be promoted by the FSF. - Joshua used his media connections at the FSF to heavily promote my work, and on December 13th, 2013, the Libreboot project was born (but not called that). Joshua made sure that everyone knew what I was doing! diff --git a/site/docs/hardware/e6400.md b/site/docs/hardware/e6400.md index 939b40c..7ab8dd6 100644 --- a/site/docs/hardware/e6400.md +++ b/site/docs/hardware/e6400.md @@ -91,7 +91,7 @@ functionality, though this configuration has not yet been encountered. Most people will want to use the 4MiB images. -Intel GPU: Blob-free setup (no-ME possible) +Intel GPU: 100% Free Software is possible --------------- This is a GM45/PM45 platform, so completely libre initialisation in diff --git a/site/docs/hardware/hp2560p.md b/site/docs/hardware/hp2560p.md index 0435617..be7f1ba 100644 --- a/site/docs/hardware/hp2560p.md +++ b/site/docs/hardware/hp2560p.md @@ -74,7 +74,7 @@ If you're using *Libreboot release* ROM images, the ME image has been scrubbed and you must re-insert it. Use the information on this guide to know how to do that: -[Insert binary blobs on Intel Sandybridge/Ivybridge/Haswell +[Insert vendor files on Intel Sandybridge/Ivybridge/Haswell platforms](../install/ivy_has_common.md) You may also wish to change the *default MAC address* if you're planning to diff --git a/site/docs/hardware/hp2570p.md b/site/docs/hardware/hp2570p.md index 15f20bc..2610bf7 100644 --- a/site/docs/hardware/hp2570p.md +++ b/site/docs/hardware/hp2570p.md @@ -113,7 +113,7 @@ If you're using *Libreboot release* ROM images, the ME image has been scrubbed and you must re-insert it. Use the information on this guide to know how to do that: -[Insert binary blobs on Intel Sandybridge/Ivybridge/Haswell +[Insert vendor files on Intel Sandybridge/Ivybridge/Haswell platforms](../install/ivy_has_common.md) You may also wish to change the *default MAC address* if you're planning to diff --git a/site/docs/hardware/hp8200sff.md b/site/docs/hardware/hp8200sff.md index f7e2237..ad1eda9 100644 --- a/site/docs/hardware/hp8200sff.md +++ b/site/docs/hardware/hp8200sff.md @@ -106,7 +106,7 @@ If you're using *Libreboot release* ROM images, the ME image has been scrubbed and you must re-insert it. Use the information on this guide to know how to do that: -[Insert binary blobs on Intel Sandybridge/Ivybridge/Haswell +[Insert vendor files on Intel Sandybridge/Ivybridge/Haswell platforms](../install/ivy_has_common.md) You may also wish to change the *default MAC address* if you're planning to diff --git a/site/docs/hardware/hp8300usdt.md b/site/docs/hardware/hp8300usdt.md index b7846fb..7d58f38 100644 --- a/site/docs/hardware/hp8300usdt.md +++ b/site/docs/hardware/hp8300usdt.md @@ -90,7 +90,7 @@ If you're using Libreboot release ROM images, the ME image has been scrubbed and you must re-insert it. Use the information on this guide to know how to do that: -[Insert binary blobs on Intel Sandybridge/Ivybridge/Haswell +[Insert vendor files on Intel Sandybridge/Ivybridge/Haswell platforms](../install/ivy_has_common.md) You can now flash libreboot: diff --git a/site/docs/hardware/hp9470m.md b/site/docs/hardware/hp9470m.md index 4b38b18..68b310f 100644 --- a/site/docs/hardware/hp9470m.md +++ b/site/docs/hardware/hp9470m.md @@ -60,7 +60,7 @@ source. If you're using *Libreboot release* ROM images, the ME image has been scrubbed and you must re-insert it. Use the information on this guide to know how to do that: -[Insert binary blobs on Intel Sandybridge/Ivybridge/Haswell +[Insert vendor files on Intel Sandybridge/Ivybridge/Haswell platforms](../install/ivy_has_common.md) You may also wish to change the *default MAC address* if you're planning to diff --git a/site/docs/hardware/index.md b/site/docs/hardware/index.md index 4325e7b..01f5f8c 100644 --- a/site/docs/hardware/index.md +++ b/site/docs/hardware/index.md @@ -27,7 +27,7 @@ yourself. FAILURE to adhere to this warning may result in you bricking your machine (rendering it unbootable), if you were to flash the release ROMs without modifying them in any way. For more information, please read:** -**[Insert binary blobs on Sandybridge/Ivybridge/Haswell](../install/ivy_has_common.md)** +**[Insert vendor files on Sandybridge/Ivybridge/Haswell](../install/ivy_has_common.md)** NOTE: This warning does not apply to ROMs that you compiled yourself, using lbmk. It only applies to release ROMs, because ME/MRC/EC firmware is *deleted* @@ -121,8 +121,8 @@ from 2021.01 is known to work, for u-boot on this board. See:\ revisions) - for now, ROM images deleted from the Libreboot 20221214 and 20230319 releases.** -**WARNING: daisy- and peach- boards require a BL1 bootloader blob, but the -one from coreboot 3rdparty is a fake/placeholder blob. We need logic in the +**WARNING: daisy- and peach- boards require a BL1 bootloader firmware, but the +one from coreboot 3rdparty is a fake/placeholder file. We need logic in the Libreboot build system for properly fetching/extracting these, plus docs to cover it. For now, assume that these are broken - ROM images are excluded, for now, and have been deleted from the Libreboot 20221214 and 20230319 diff --git a/site/docs/install/chromebooks.md b/site/docs/install/chromebooks.md index a264155..bd27b45 100644 --- a/site/docs/install/chromebooks.md +++ b/site/docs/install/chromebooks.md @@ -133,7 +133,7 @@ Prepare the ROM image Libreboot ROM image layouts are currently incompatible with the regions that should be carried over from the stock firmware. However, the released images should still be somewhat usable, since the Chromebooks -supported so far don't require any non-redistributable blobs to be +supported so far don't require any non-redistributable code to be injected by the end user. Future Libreboot versions will likely require post-processing to @@ -146,7 +146,7 @@ Flash the ROM image =================== WARNING: Although none are supported yet, make sure not to flash ROM -images on x86 Chromebooks without injecting non-redistributable blobs +images on x86 Chromebooks without injecting non-redistributable code first (like Intel ME firmware). This is not yet documented here. You can flash the ROM image both internally and externally. For the diff --git a/site/docs/install/e6400.md b/site/docs/install/e6400.md index 27ae421..8e02baa 100644 --- a/site/docs/install/e6400.md +++ b/site/docs/install/e6400.md @@ -25,10 +25,10 @@ Variants (nvidia or intel graphics) Dell E6400, E6400 XFR and E6400 ATG are all believed to work. The flashing instructions are identical, on all of them. -Blob-free initialisation (on Intel GPU variants) +100% Free Software possible (Intel GPU) ========================= -This board can boot entirely blob-free in the flash. The hardware is similar +This board can boot entirely *free software* in the flash. The hardware is similar to that of ThinkPad X200, T400 etc where no-ME setup is possible. No-microcode setup feasible @@ -47,13 +47,13 @@ A note about GPUs ----------------- We *confirm that* the Nvidia models are PM45, and therefore will require a VGA -blob for initialisation. This is supported in Libreboot *after* the 20230625 +ROM for initialisation. This is supported in Libreboot *after* the 20230625 release, if you compile from source; the `e6400_4mb` target can work on both variants, but will need the Nvidia VGA ROM inserted to work on Nvidia models. This insertion is handled automatically in newer lbmk revisions, during build time, or you can [insert it on a release rom after 20230625](ivy_has_common.md). - **A Video BIOS Option -ROM is used, in this configuration, which is a binary blob. Libreboot's +ROM is used, in this configuration. Libreboot's build system automatically downloads this at build time, or it can handle that for you in the same way if it was scrubbed from a release ROM.** @@ -150,7 +150,7 @@ Obtaining the VGA Option ROM (Nvidia) ------------------------------------- Libreboot does not (and will not) directly distribute the Nvidia ROM, but lbmk - has logic added to blob scripts, which automatically fetches Dell + has logic added to vendor handle scripts, which automatically fetches Dell update files and extracts the Video BIOS from it. This is inserted during the build process, *automatically*. Everything has been figured out *for you*, as is the purpose of Libreboot's [automated build system](../maintain/). @@ -158,7 +158,7 @@ as is the purpose of Libreboot's [automated build system](../maintain/). Provided for *after* the Libreboot 20230625 release, this Video BIOS ROM will *not* be present in releases, but you'll be able to run the same script that lbmk uses, to manually re-download and re-add it. The Libreboot build system -scrubs certain binary blobs, in the scripts from lbmk that create release +scrubs certain vendor code, in the scripts from lbmk that create release archives. [Please read the Libreboot build guide](../build/) for more general guidance diff --git a/site/docs/install/index.md b/site/docs/install/index.md index 21f91fe..550d38b 100644 --- a/site/docs/install/index.md +++ b/site/docs/install/index.md @@ -20,7 +20,7 @@ yourself. FAILURE to adhere to this warning may result in you bricking your machine (rendering it unbootable), if you were to flash the release ROMs without modifying them in any way. For more information, please read:** -**[Insert binary blobs on Sandybridge/Ivybridge/Haswell](ivy_has_common.md)** +**[Insert vendor files on Sandybridge/Ivybridge/Haswell](ivy_has_common.md)** NOTE: This warning does not apply to ROMs that you compiled yourself, using lbmk. It only applies to release ROMs, because ME/MRC/EC firmware is *deleted* @@ -29,8 +29,8 @@ yourself, from source, Libreboot's build system automatically handles it. See: [Libreboot build instructions](../build/) This isn't required on *all* Libreboot-supported boards, but if in doubt, follow -these instructions anyway. If you run `blobutil` on a board that doesn't need -blobs, nothing will happen. +these instructions anyway. If you run the vendor scripts on a board that doesn't +need vendor files, nothing will happen. PRECAUTIONS =========== @@ -55,12 +55,12 @@ BLOBS MISSING IN RELEASE ROMs E.g. ThinkPad X220, X230, T440p, W541. - also desktop boards such as HP Elite 8200 SFF. -The lbmk build system automatically fetches required blobs for these +The lbmk build system automatically fetches required vendor code for these boards, when building, and sets them up properly, e.g. `me_cleaner` is used. The same process is also available in a script, which can insert them into ROM images. -**If you're using release ROMs, these blobs are missing, and must be +**If you're using release ROMs, these files are missing, and must be added. See: [ivy_has_common.md](ivy_has_common.md).** About ROM image file names @@ -106,7 +106,7 @@ NOTE: no configs in libreboot are currently available that use this method. With this method, coreboot is finding, loading and executing a VGA option ROM for your graphics hardware. This would not be done on laptops, because that -implies supplying non-free binary blobs in libreboot, so this setup would only +implies needless supply of non-free software in libreboot, so this setup would only ever be provided on desktop hardware where no GPU exists or where it is desirable for you to use an external/add-on graphics card diff --git a/site/docs/install/ivy_has_common.md b/site/docs/install/ivy_has_common.md index 77323b7..1ff0bd7 100644 --- a/site/docs/install/ivy_has_common.md +++ b/site/docs/install/ivy_has_common.md @@ -22,60 +22,59 @@ before reading the instructions below: ** Coreboot is nominally free software, but requires non-free software for certain -boards, for certain functionalities; it differs per board, and some boards do -not require blobs of any kind in the flash. We cover this more thoroughly in +boards, for certain functionalities; we cover this more thoroughly in the [Freedom Status](../../freedom-status.md) page and in the [Binary Blob Reduction Policy](../../news/policy.md). -Well, not all of these blobs are freely redistributable. Coreboot does provide -binary blobs in some cases, if the vendor has allowed it. In other cases, +Well, not all of these files are freely redistributable. Coreboot does provide +vendor files in some cases, if the vendor has allowed it. In other cases, extraction from factory firmware is required, or you can extract them from vendor-supplied updates - Libreboot's build system does the latter. When you [compile Libreboot ROM images from source](../build/), Libreboot will -automatically download any given blobs that are required, for any given board +automatically download any given files that are required, for any given board target. This is done without user intervention, and only when absolutely needed to make the machine boot properly. The problem? ------------ -Well, if the blobs cannot be freely redistributed, then we can't provide them. +Well, if the files cannot be freely redistributed, then we can't provide them. So how do we handle *that*, in the context of Libreboot releases? The solution ------------ -The answer is very simple: these blobs are **NOT** provided, at all! However, +The answer is very simple: these files are **NOT** provided, at all! However, the very same logic used by the build system can be run standalone, to re-insert -these binary blobs on release ROMs. The `inject` script detects what blobs are +these vendor files on release ROMs. The `inject` script detects what files are needed for your ROM image. The script will detect what board you're inserting on, or you can manually tell it what board, and it will fetch them for you, inserting them, so that your -board is ready to flash - flashing it without these required blobs may result in +board is ready to flash - flashing it without these required files may result in a brick. -Blob locations +Vendor file locations -------------- -During auto-download of blobs, they are saved to these locations within the +During auto-download of files, they are saved to these locations within the Libreboot build system: -* ME firmware: `blobs/*/me.bin` - the `*` can be any given directory. Different ones will +* ME firmware: `vendor/*/me.bin` - the `*` can be any given directory. Different ones will be used by given boards, but the directory name may not match the board target name. -* SMSC SCH5545 fan control firmware (for Dell T1650): `blobs/t1650/sch5545ec.bin` +* SMSC SCH5545 fan control firmware (for Dell T1650): `vendor/t1650/sch5545ec.bin` * SMSC KBC1126 embedded controller firmware, on HP EliteBooks: `ec/` * Intel MRC firmware, used for ram/peripheral init on Haswell machines such as thinkpad t440p/w541: `mrc/` -The above list refers to the *non-redistributable blobs*, and these are not -directly included in releases. These are what `blobutil` auto-downloads. +The above list refers to the *non-redistributable files*, and these are not +directly included in releases. These are auto-downloaded during the build. The `me.bin` files are produced by extracting them from vendor updates and neutering them with `me_cleaner` so that Intel ME is disabled during early boot. -Injecting Blobs into an Existing Rom +Injecting vendor files into ROM ------------------------------------ You must determine the correct board name, for your board, based on the list @@ -87,9 +86,9 @@ For example, `t440pmrc_12mb` corresponds to ThinkPad T440p with MRC firmware. Whereas `t440plibremrc_12mb` corresponds to T440p with libre MRC firmware. Another example: `x230_12mb` corresponds to Thinkpad X230. -In order to inject the necessary blobs into a rom image, run the script from the root of lbmk and point to the rom image. +In order to inject the necessary files into a rom image, run the script from the root of lbmk and point to the rom image. -If you only wish to flash a release rom then the process of injecting the necessary blobs is quite simple. +If you only wish to flash a release rom then the process of injecting the necessary files is quite simple. Run the injection script pointing to the release archive you downloaded: ./update vendor inject /path/to/libreboot-20230319-18-g9f76c92_t440pmrc_12mb.tar.xz @@ -108,10 +107,10 @@ For example: ./update vendor inject -r x230_libreboot.rom -b x230_12mb -m 00:f6:f0:40:71:fd -Check that the blobs were inserted +Check that the files were inserted ================================== -You *must* ensure that the blobs were inserted. +You *must* ensure that the files were inserted. Some examples of how to do that in lbmk: @@ -123,7 +122,7 @@ below): ./cbutils/default/cbfstool libreboot.rom print -You should check that the blobs were inserted in cbfs, if needed; for example, +You should check that the files were inserted in cbfs, if needed; for example, EC firmware or MRC firmware. Next: @@ -139,7 +138,7 @@ Check the output. If it's all `0xFF` (all ones) or otherwise isn't a bunch of code, then the Intel ME firmware wasn't inserted. You'll note the small size of the Intel ME, e.g. 84KB on sandybridge platforms. -This is because blobutil *automatically* neuters it, disabling it during +This is because lbmk *automatically* neuters it, disabling it during early boot. This is done using `me_cleaner`, which lbmk imports. Errata @@ -149,7 +148,7 @@ Errata ROM image configuration. These ROM configs have `mrc.bin`: `t440pmrc_12mb` and `w541mrc_12mb`. These ROM configs have libre MRC: `t440p_12mb` and `w541_12mb` - it is critical that you choose the right one, when using -the `-b` flag in the `blobutil inject` command. For example, if you +the `-b` flag in the `./update vendor inject` command. For example, if you used `-b t440p_12mb` on a ROM image that actually corresponds to `t440pmrc_12mb`, then the required `mrc.bin` file would not be added and that ROM would not boot when flashed.** diff --git a/site/docs/install/ivy_has_common.uk.md b/site/docs/install/ivy_has_common.uk.md index 3b10731..f53d7da 100644 --- a/site/docs/install/ivy_has_common.uk.md +++ b/site/docs/install/ivy_has_common.uk.md @@ -26,59 +26,59 @@ before reading the instructions below: Coreboot is nominally free software, but requires non-free software for certain boards, for certain functionalities; it differs per board, and some boards do -not require blobs of any kind in the flash. We cover this more thoroughly in +not require vendor code of any kind in the flash. We cover this more thoroughly in the [Freedom Status](../../freedom-status.md) page and in the [Binary Blob Reduction Policy](../../news/policy.md). -Well, not all of these blobs are freely redistributable. Coreboot does provide -binary blobs in some cases, if the vendor has allowed it. In other cases, +Well, not all of these files are freely redistributable. Coreboot does provide +vendor files in some cases, if the vendor has allowed it. In other cases, extraction from factory firmware is required, or you can extract them from vendor-supplied updates - Libreboot's build system does the latter. When you [compile Libreboot ROM images from source](../build/), Libreboot will -automatically download any given blobs that are required, for any given board +automatically download any given vendor files required, for any given board target. This is done without user intervention, and only when absolutely needed to make the machine boot properly. The problem? ------------ -Well, if the blobs cannot be freely redistributed, then we can't provide them. +Well, if the files cannot be freely redistributed, then we can't provide them. So how do we handle *that*, in the context of Libreboot releases? The solution ------------ -The answer is very simple: these blobs are **NOT** provided, at all! However, +The answer is very simple: these files are **NOT** provided, at all! However, the very same logic used by the build system can be run standalone, to re-insert -these binary blobs on release ROMs. The `inject` script detects what blobs are +these vendor files on release ROMs. The `inject` script detects what files are needed for your ROM image. The script will detect what board you're inserting on, or you can manually tell it what board, and it will fetch them for you, inserting them, so that your -board is ready to flash - flashing it without these required blobs may result in +board is ready to flash - flashing it without these required files may result in a brick. -Blob locations +Vendor file locations -------------- -During auto-download of blobs, they are saved to these locations within the +During auto-download of files, they are saved to these locations within the Libreboot build system: -* ME firmware: `blobs/*/me.bin` - the `*` can be any given directory. Different ones will +* ME firmware: `vendor/*/me.bin` - the `*` can be any given directory. Different ones will be used by given boards, but the directory name may not match the board target name. -* SMSC SCH5545 fan control firmware (for Dell T1650): `blobs/t1650/sch5545ec.bin` +* SMSC SCH5545 fan control firmware (for Dell T1650): `vendor/t1650/sch5545ec.bin` * SMSC KBC1126 embedded controller firmware, on HP EliteBooks: `ec/` * Intel MRC firmware, used for ram/peripheral init on Haswell machines such as thinkpad t440p/w541: `mrc/` -The above list refers to the *non-redistributable blobs*, and these are not -directly included in releases. These are what `blobutil` auto-downloads. +The above list refers to the *non-redistributable files*, and these are not +directly included in releases. These are auto-downloaded during the build. The `me.bin` files are produced by extracting them from vendor updates and neutering them with `me_cleaner` so that Intel ME is disabled during early boot. -Injecting Blobs into an Existing Rom +Inject vendor files into ROM ------------------------------------ You must determine the correct board name, for your board, based on the list @@ -90,9 +90,9 @@ For example, `t440pmrc_12mb` corresponds to ThinkPad T440p with MRC firmware. Whereas `t440plibremrc_12mb` corresponds to T440p with libre MRC firmware. Another example: `x230_12mb` corresponds to Thinkpad X230. -In order to inject the necessary blobs into a rom image, run the script from the root of lbmk and point to the rom image. +In order to inject the necessary files into a rom image, run the script from the root of lbmk and point to the rom image. -If you only wish to flash a release rom then the process of injecting the necessary blobs is quite simple. +If you only wish to flash a release rom then the process of injecting the necessary files is quite simple. Run the injection script pointing to the release archive you downloaded: ./update vendor inject /path/to/libreboot-20230319-18-g9f76c92_t440pmrc_12mb.tar.xz @@ -111,10 +111,10 @@ For example: ./update vendor inject -r x230_libreboot.rom -b x230_12mb -m 00:f6:f0:40:71:fd -Check that the blobs were inserted +Check that the files were inserted ================================== -You *must* ensure that the blobs were inserted. +You *must* ensure that the files were inserted. Some examples of how to do that in lbmk: @@ -126,7 +126,7 @@ below): ./cbutils/default/cbfstool libreboot.rom print -You should check that the blobs were inserted in cbfs, if needed; for example, +You should check that the files were inserted in cbfs, if needed; for example, EC firmware or MRC firmware. Next: @@ -142,7 +142,7 @@ Check the output. If it's all `0xFF` (all ones) or otherwise isn't a bunch of code, then the Intel ME firmware wasn't inserted. You'll note the small size of the Intel ME, e.g. 84KB on sandybridge platforms. -This is because blobutil *automatically* neuters it, disabling it during +This is because lbmk *automatically* neuters it, disabling it during early boot. This is done using `me_cleaner`, which lbmk imports. Errata @@ -152,7 +152,7 @@ Errata ROM image configuration. These ROM configs have `mrc.bin`: `t440pmrc_12mb` and `w541mrc_12mb`. These ROM configs have libre MRC: `t440p_12mb` and `w541_12mb` - it is critical that you choose the right one, when using -the `-b` flag in the `blobutil inject` command. For example, if you +the `-b` flag in the `./update vendor inject` command. For example, if you used `-b t440p_12mb` on a ROM image that actually corresponds to `t440pmrc_12mb`, then the required `mrc.bin` file would not be added and that ROM would not boot when flashed.** diff --git a/site/docs/install/nvmutil.md b/site/docs/install/nvmutil.md index afdf448..bd780ef 100644 --- a/site/docs/install/nvmutil.md +++ b/site/docs/install/nvmutil.md @@ -8,7 +8,7 @@ on any system that uses an Intel Flash Descriptor. This is the reference documentation for `nvmutil`, but an automated script using nvmutil is available for ivy/sandybridge and haswell hardware, when -inserting blobs, which you can use to change the MAC address. See: +inserting vendor files, which you can use to change the MAC address. See: [docs/install/ivy_has_common.md](ivy_has_common.md) diff --git a/site/docs/install/spi.md b/site/docs/install/spi.md index 6b320e6..3572c3a 100644 --- a/site/docs/install/spi.md +++ b/site/docs/install/spi.md @@ -555,7 +555,8 @@ You can combine both flashes together with `cat` for example: cat bottom_8mb.rom top_4mb.rom > full_12mb.rom -Note that you will need this combined rom if you intend to manually extract blobs. +Note that you will need this combined rom if you intend to manually extract vendor +files, which is a method not officially supported by Libreboot's build system. Writing ------- diff --git a/site/docs/install/t420_external.md b/site/docs/install/t420_external.md index 65fea83..704141f 100644 --- a/site/docs/install/t420_external.md +++ b/site/docs/install/t420_external.md @@ -18,26 +18,26 @@ The following instructions expect you to have these on hand: Preparing a release Rom ----------------------- -You must patch the release rom with the necessary blobs *and then* flash it to your board. +You must patch the release rom with the necessary vendor files *and then* flash it to your board. -In order to inject the necessary blobs into a rom image, run the script from the root of lbmk and point to the rom image. +In order to inject the necessary files into a rom image, run the script from the root of lbmk and point to the rom image. -If you only wish to flash a release rom then the process of injecting the necessary blobs is quite simple. +If you only wish to flash a release rom then the process of injecting the necessary files is quite simple. Run the injection script pointing to the release archive you downloaded: - ./update blobs inject /path/to/libreboot-20230423_t420_8mb.tar.xz + ./update vendor inject /path/to/libreboot-20230423_t420_8mb.tar.xz The script can automatically detect the board as long as you do not change the file name. You can then find flash-ready ROMs in `/bin/release/` Alternatively, you may patch only a single rom file. - ./update blobs inject -r t420_libreboot.rom -b t420_8mb + ./update vendor inject -r t420_libreboot.rom -b t420_8mb Optionally, you can use this script to modify the mac address of the rom with the `-m` flag. For example: - ./update blobs inject -r t420_libreboot.rom -b t420_8mb -m 00:f6:f0:40:71:fd + ./update vendor inject -r t420_libreboot.rom -b t420_8mb -m 00:f6:f0:40:71:fd Disassembly ----------- diff --git a/site/docs/install/t440p_external.md b/site/docs/install/t440p_external.md index e22df09..52981f0 100644 --- a/site/docs/install/t440p_external.md +++ b/site/docs/install/t440p_external.md @@ -18,17 +18,17 @@ You can now follow the rest of the instructions. Preparing a release Rom ----------------------- -You must patch the release rom with the necessary blobs *and then* flash it to your board. +You must patch the release rom with the necessary vendor files *and then* flash it to your board. -Lbmk includes a script that will automatically inject the necessary blobs into a rom file. +Lbmk includes a script that will automatically inject the necessary files into a rom file. The script can determine the board automatically if you have not changed the name, but you can also manually set the board name with the `-b` flag. -In order to inject the necessary blobs into a rom image, run the script from the root of lbmk and point to the rom image. +In order to inject the necessary files into a rom image, run the script from the root of lbmk and point to the rom image. -If you only wish to flash a release rom then the process of injecting the necessary blobs is quite simple. +If you only wish to flash a release rom then the process of injecting the necessary files is quite simple. Run the injection script pointing to the release archive you downloaded: - ./update blobs inject /path/to/libreboot-20230319-18-g9f76c92_t440_12mb.tar.xz + ./update vendor inject /path/to/libreboot-20230319-18-g9f76c92_t440_12mb.tar.xz The script can automatically detect the board as long as you do not change the file name. You can then find flash-ready ROMs in `/bin/release/` @@ -36,21 +36,21 @@ You can then find flash-ready ROMs in `/bin/release/` Alternatively, you may patch only a single rom file. For example (libre replacement of `mrc.bin`): - ./update blobs inject -r t440p_libreboot.rom -b t440p_12mb + ./update vendor inject -r t440p_libreboot.rom -b t440p_12mb Optionally, you can use this script to modify the mac address of the rom with the `-m` flag. For example: - ./update blobs inject -r t440p_libreboot.rom -b t440p_12mb -m 00:f6:f0:40:71:fd + ./update vendor inject -r t440p_libreboot.rom -b t440p_12mb -m 00:f6:f0:40:71:fd -If you're flashing a ROM that needs blob `mrc.bin`, you would do one of these +If you're flashing a ROM that needs vendor file `mrc.bin`, you would do one of these instead, for example: - ./update blobs inject -r t440p_libreboot.rom -b t440pmrc_12mb + ./update vendor inject -r t440p_libreboot.rom -b t440pmrc_12mb or (inserting a different MAC address) - ./update blobs inject -r t440p_libreboot.rom -b t440pmrc_12mb -m 00:f6:f0:40:71:fd + ./update vendor inject -r t440p_libreboot.rom -b t440pmrc_12mb -m 00:f6:f0:40:71:fd NOTE: this makes use of `nvmutil`, which you can read more about in the [nvmutil documentation](nvmutil.md). diff --git a/site/docs/install/x230_external.md b/site/docs/install/x230_external.md index 407d072..7465963 100644 --- a/site/docs/install/x230_external.md +++ b/site/docs/install/x230_external.md @@ -22,15 +22,15 @@ You can now follow the rest of the instructions. Preparing a release Rom ----------------------- -You must patch the release rom with the necessary blobs *and then* flash it to your board. +You must patch the release rom with the necessary vendor files *and then* flash it to your board. -Lbmk includes a script that will automatically inject the necessary blobs into a rom file. +Lbmk includes a script that will automatically inject the necessary files into a rom image. The script can determine the board automatically if you have not changed the name, but you can also manually set the board name with the `-b` flag. -In order to inject the necessary blobs into a rom image, run the script from the root of lbmk and point to the rom image. +In order to inject the necessary files into a rom image, run the script from the root of lbmk and point to the rom image. Run the injection script pointing to the release archive you downloaded: - ./update blobs inject /path/to/libreboot-20230319-18-g9f76c92_t440_12mb.tar.xz + ./update vendor inject /path/to/libreboot-20230319-18-g9f76c92_t440_12mb.tar.xz The script can automatically detect the board as long as you do not change the file name. You can then find flash-ready ROMs in `/bin/release/` @@ -38,12 +38,12 @@ You can then find flash-ready ROMs in `/bin/release/` Alternatively, you may patch only a single rom file. For example: - ./update blobs inject -r x230_libreboot.rom -b x230_12mb + ./update vendor inject -r x230_libreboot.rom -b x230_12mb Optionally, you can use this script to modify the mac address of the rom with the `-m` flag. For example: - ./update blobs inject -r x230_libreboot.rom -b x230_12mb -m 00:f6:f0:40:71:fd + ./update vendor inject -r x230_libreboot.rom -b x230_12mb -m 00:f6:f0:40:71:fd NOTE: this makes use of `nvmutil`, which you can read more about in the [nvmutil documentation](nvmutil.md). diff --git a/site/docs/linux/grub_hardening.md b/site/docs/linux/grub_hardening.md index 5321f4e..28ed31e 100644 --- a/site/docs/linux/grub_hardening.md +++ b/site/docs/linux/grub_hardening.md @@ -188,7 +188,7 @@ computer. NOTE: An attacker could still open your system and re-flash new firmware externally. You should implement some detection mechanism, such as epoxy applied in a *random pattern* on every screw; this slows down the attack and means that you will know someone tampered with it because they cannot -easily re-produce the exact same blob of epoxy in the same pattern (when you +easily re-produce the exact same glob of epoxy in the same pattern (when you apply it, swirl it around a bit for a few minutes while it cures. The purpose is not to prevent disassembly, but to slow it down and make it detectable when it has occured). diff --git a/site/docs/maintain/index.md b/site/docs/maintain/index.md index 09829b8..516dea7 100644 --- a/site/docs/maintain/index.md +++ b/site/docs/maintain/index.md @@ -72,7 +72,7 @@ the vendor on many supported systems. These programs lack source code, and the coreboot project does not control them, but they can be used to perform specific initialization tasks. -The libreboot project *allows* binary blobs from coreboot, but there is *still* a +The libreboot project *allows* vendor code within coreboot, but there is *still* a lot of nuance to precisely what is allowed. It is important that you understand these nuances, when working on *libreboot*. @@ -110,15 +110,6 @@ The files under `bin/` are provided in regular Libreboot releases. **These** are the ROM images that you should flash. Do *not* flash the ROM images contained under `elf/`! -blobs/ ---------------- - -Used by the blob handler scripts, referenced in certain coreboot configs. - -Certain binary blobs such as Intel ME or SCH5545 EC firmware are downloaded -here; not all blobs are downloaded here however, as some are handled under -separate directories. - cbutils/ --------------- @@ -161,10 +152,8 @@ Please also visit: - the handling of this, in Libreboot, is based largely on the information there. -This contains the Intel MRC blob, auto-downloaded during build -by `script/update/blobs/mrc`, called by the user directly or -by `script/update/blobs/download`. This provides raminit and peripheral -init on certain Haswell and Broadwell platforms. +This contains the Intel MRC firmware, auto-downloaded during build +by `script/update/vender/download`. In some cases, libre MRC firmware is also available, and provided by Libreboot as an alternative choice. @@ -185,7 +174,7 @@ current lbmk behaviour, and executed so as to provide Libreboot release archives. This provides source tarballs, and ROM images for example; however, ROM images -containing non-redistributable blobs are *scrubbed* such that those blobs must, +containing non-redistributable vendor code are *scrubbed* such that these files must, in regular releases, be [re-added manually](../install/ivy_has_common.md) by the user. @@ -197,7 +186,7 @@ Third-party source trees are downloaded into this directory, by lbmk. src/bios\_extract/ --------------- -Used by the blob handler scripts. The upstream that we use is here: +Used by the vendor file handler scripts. The upstream that we use is here: Specifically: the pfs extract utility from this is used on Dell vendor updates, @@ -206,7 +195,7 @@ to extract SCH5545 EC (Environment Control) firmware. src/biosutilities/ --------------- -Used by the blob handler scripts. The upstream that we use is here: +Used by the vendor file handler scripts. The upstream that we use is here: The `dell_inspiron_1100_unpacker.py` script is used here, to extract from Dell @@ -275,8 +264,8 @@ payload). More information available at these pages: * * Libreboot [freedom status page](../../freedom-status.md) -The *blob* scripts are what handle this, specifically the download script -located at `script/update/blobs/download`. +The *vendor file* scripts are what handle this, specifically the download script +located at `script/update/vendor/download`. src/memtest86plus/ --------------- @@ -318,7 +307,7 @@ src/uefitool/ Please also visit: This is compiled, so as to provide `UEFIExtract`. Currently used by the -blob download script at `script/update/blobs/download`, to download SCH5545 EC +vendor download script at `script/update/vendor/download`, to download SCH5545 EC firmware (used for fan control on Dell Precision T1650). src/pico-serprog @@ -359,6 +348,15 @@ may not have much RAM. Where large files (or a large number of files) are handled by lbmk on a temporary basis, this `tmp/` directory is created and then used. +vendor/ +--------------- + +Used by the vendor file handler scripts, referenced in certain coreboot configs. + +Certain vendor files such as Intel ME or SCH5545 EC firmware are downloaded +here; not all such files are downloaded here however, as some are handled under +separate directories. + util/ =============== @@ -506,9 +504,9 @@ for example, be `default`. In other words, they can refer to other trees. The coreboot downloads are based on scanning of these directories, and ROM images are also built based on them; coreboot defconfigs are also used by -the blob scripts, for adding or removing certain binary blobs (for example, +the vendor scripts, for adding or removing certain vendor firmware (for example, a config will define where `me.bin` is located, and if it doesn't exist, the -blob scripts will look up that file and download/process it with `me_cleaner`). +vendor scripts will look up that file and download/process it with `me_cleaner`). ### config/coreboot/BOARDNAME/patches/ @@ -534,7 +532,7 @@ as: * `payload_seabios_withgrub="y"` (example entry) * `grub_scan_disk="ata"` * `uboot_config=default` (specify which U-Boot tree to use) -* `blobs_required="n"` +* `vendorfiles="n"` * `microcode_required="y"` The `tree` value refers to `config/coreboot/TREE`; in other words, a given @@ -587,7 +585,7 @@ on a ThinkPad X60 with the optical drive may cause GRUB to hang, so on that machine it is advisable to set this option to `ahci` (becuse the default HDD slot is AHCI). -The `blobs_required` entry doesn't affect anything in code, except that +The `vendorfiles` entry doesn't affect anything in code, except that the `noblobs` string will be appended to ROM image file names, on releases; ditto `nomicrocode` but in that case, the behaviour is: if no microcode to begin with, only `nomicrocode` images will be named, otherwise ROM images with @@ -1091,9 +1089,9 @@ in the script at `script/update/vendor/download`, and it is used from there. include/option.sh --------------- -Functions used by scripts under `script/update/blobs/`, for checking defconfig +Functions used by scripts under `script/update/vendor/`, for checking defconfig files. These files are checked because the scripts need to know whether a given -blob is used; if it is, a path is then specified in defconfig, telling the blob +file is used; if it is, a path is then specified in defconfig, telling the vendor script either where it is, or where it should be downloaded to. Several other parts of lbmk also use this file. It is added to as little as @@ -1274,11 +1272,11 @@ clone, then cleans itself up and creates tarballs. If you run this script, you should expect it to take at least 4 hours; slower on really old systems. On really fast systems, it might take 2-3 hours. -NOTE: This script *scrubs* certain binary blobs from release ROMs, such as -Intel ME or MRC firmware. The release ROMs shall then exclude these blobs +NOTE: This script *scrubs* certain vendor firmware from release ROMs, such as +Intel ME or MRC firmware. The release ROMs shall then exclude these files within them, requiring manual insertion by the user post-release. See: -[Insert binary blobs +[Insert vendor files on Sandybridge/Ivybridge/Haswell](../install/ivy_has_common.md) ### script/update/project/trees @@ -1404,12 +1402,12 @@ Remember: code equals bugs, so less code equals fewer bugs. ### script/update/vendor/download -This downloads binary blobs when needed, on a given coreboot target. It does -this by scanning the defconfig files of that board, to know where the blobs +This downloads vendor code when needed, on a given coreboot target. It does +this by scanning the defconfig files of that board, to know where the files are (or where they should be) within lbmk. Based on this, it then knows which -blobs to download. +files to download. -These blobs are then inserted at build time by the coreboot build system (as +These files are then inserted at build time by the coreboot build system (as defined by defconfigs), or post-release by running the `inject` script. It looks inside `config/vendor/` at the files in there, concatenating them and @@ -1420,14 +1418,14 @@ the `me_cleaner` program. More information is available [here](../install/ivy_has_common.md). This script is executed automatically, when you compile ROM images, if the given -mainboard requires binary blobs to be inserted. In this way, you do not need to +mainboard requires vendor code to be inserted. In this way, you do not need to manually extract such files from your original vendor image. ### script/update/vendor/inject This is not used during the build process, but it can be run by the user on -release ROMs (which do not contain non-redistributable blobs handled by these -blob scripts, even if they are required). This script inserts those blobs +release ROMs (which do not contain non-redistributable code handled by these +vendor scripts, even if they are required). This script inserts those files into the coreboot ROM image; if you're building from source, using lbmk, you do not need to run the inject script at all. diff --git a/site/docs/maintain/porting.md b/site/docs/maintain/porting.md index 65a0774..ca226ab 100644 --- a/site/docs/maintain/porting.md +++ b/site/docs/maintain/porting.md @@ -84,7 +84,7 @@ Once you have finished this, you can try flashing the resulting rom to your boar If you try to flash this rom and it fails, then there are two probable reasons: 1) CBFS size or ROM size is wrong -2) The blobs are incompatible +2) The vendor code (if required) is incompatible Solutions to these problems follow in the proceeding sections. diff --git a/site/docs/uboot/uboot-archlinux.md b/site/docs/uboot/uboot-archlinux.md index 5996faa..e633802 100644 --- a/site/docs/uboot/uboot-archlinux.md +++ b/site/docs/uboot/uboot-archlinux.md @@ -31,9 +31,9 @@ Despite still being distributed by some distros, boot.scr is a legacy boot metho For more information about what actually goes into a boot.scr script, check [this page in the u-boot documentation](https://u-boot.readthedocs.io/en/latest/usage/cmd/source.html?highlight=boot.scr#fit-image) -3) extlinux.conf - a flat, bootloader-spec text file that lives in /boot/extlinux/extlinux.conf. That's all. Not a binary blob in sight! +3) extlinux.conf - a flat, bootloader-spec text file that lives in /boot/extlinux/extlinux.conf. That's all. -Since extlinux.conf is supported by multiple bootloaders, making your system more portable, is natively supported by u-boot, and requires no binary blobs or extra software, it seems to be the best choice for a chromebook. +Since extlinux.conf is supported by multiple bootloaders, making your system more portable, is natively supported by u-boot, it seems to be the best choice for a chromebook. Creating extlinux.conf ====================== diff --git a/site/download.md b/site/download.md index 590811a..a8f8943 100644 --- a/site/download.md +++ b/site/download.md @@ -21,7 +21,7 @@ yourself. FAILURE to adhere to this warning may result in you bricking your machine (rendering it unbootable), if you were to flash the release ROMs without modifying them in any way. For more information, please read:** -**[Insert binary blobs on Sandybridge/Ivybridge/Haswell](docs/install/ivy_has_common.md)** +**[Insert vendor files on Sandybridge/Ivybridge/Haswell](docs/install/ivy_has_common.md)** NOTE: This warning does not apply to ROMs that you compiled yourself, using lbmk. It only applies to release ROMs, because ME/MRC/EC firmware is *deleted* @@ -30,8 +30,8 @@ yourself, from source, Libreboot's build system automatically handles it. See: [Libreboot build instructions](docs/build/) This isn't required on *all* Libreboot-supported boards, but if in doubt, follow -these instructions anyway. If you run `blobutil` on a board that doesn't need -blobs, nothing will happen. +these instructions anyway. If you run the vendor scripts on a board that doesn't +need blobs, nothing will happen. GPG signing key --------------- diff --git a/site/download.uk.md b/site/download.uk.md index 0e61094..3cb4b25 100644 --- a/site/download.uk.md +++ b/site/download.uk.md @@ -21,7 +21,7 @@ yourself. FAILURE to adhere to this warning may result in you bricking your machine (rendering it unbootable), if you were to flash the release ROMs without modifying them in any way. For more information, please read:** -**[Insert binary blobs on Sandybridge/Ivybridge/Haswell](docs/install/ivy_has_common.md)** +**[Insert vendor files on Sandybridge/Ivybridge/Haswell](docs/install/ivy_has_common.md)** NOTE: This warning does not apply to ROMs that you compiled yourself, using lbmk. It only applies to release ROMs, because ME/MRC/EC firmware is *deleted* @@ -30,8 +30,8 @@ yourself, from source, Libreboot's build system automatically handles it. See: [Libreboot build instructions](docs/build/) This isn't required on *all* Libreboot-supported boards, but if in doubt, follow -these instructions anyway. If you run `blobutil` on a board that doesn't need -blobs, nothing will happen. +these instructions anyway. If you run the vendor scripts on a board that doesn't +need vendor files, nothing will happen. Код підпису GPG --------------- diff --git a/site/faq.md b/site/faq.md index 1067a7e..94bd8bc 100644 --- a/site/faq.md +++ b/site/faq.md @@ -194,7 +194,7 @@ Please read the [hardware compatibility list](docs/hardware/). Freedom pitfalls with modern Intel hardware {#intel} ---------------------------------------------------- -Coreboot is nominally Free Software, but requires binary blobs on most x86 +Coreboot is nominally Free Software, but requires certain vendor code on some x86 targets that it supports, on both Intel and AMD. ### Intel Management Engine (ME) {#intelme} @@ -370,21 +370,16 @@ interesting: ### Firmware Support Package (FSP) {#fsp} On all recent Intel systems, coreboot support has revolved around -integrating a blob (for each system) called the *FSP* (firmware support +integrating a vendor file (for each system) called the *FSP* (firmware support package), which handles all of the hardware initialization, including memory and CPU initialization. Reverse engineering and replacing this -blob is almost impossible, due to how complex it is. Even for the most +file is almost impossible, due to how complex it is. Even for the most skilled developer, it would take years to replace. Intel distributes -this blob to firmware developers, without source. +this file to firmware developers, for free redistribution. Since the FSP is responsible for the early hardware initialization, that means it also handles SMM (System Management Mode). This is a special -mode that operates below the operating system level. **It's possible -that rootkits could be implemented there, which could perform a number -of attacks on the user (the list is endless). Any Intel system that has -the proprietary FSP blob cannot be trusted at all.** In fact, several -SMM rootkits have been demonstrated in the wild (use a search engine to -find them). +mode that operates below the operating system level. ### CPU microcode updates {#microcode} @@ -488,7 +483,7 @@ demonstration](https://media.ccc.de/v/31c3_-_6103_-_en_-_saal_2_-_201412272145_- and based on this work, Damien Zammit (another coreboot hacker) [partially replaced it](https://github.com/zamaudio/smutool/) with free firmware, but on the relevant system (ASUS F2A85-M) there were still -other blobs present (Video BIOS, and others). +other such files present (Video BIOS, and others). ### AMD AGESA firmware @@ -499,7 +494,7 @@ page is a few years out of date. This is responsible for virtually all core hardware initialization on modern AMD systems. In 2011, AMD started cooperating with the coreboot project, releasing this as source code under a free license. In 2014, -they stopped releasing source code and started releasing AGESA as binary +they stopped releasing source code and started releasing AGESA as vendor blobs instead. This makes AGESA now equivalent to [Intel FSP](#fsp). ### AMD CPU microcode updates @@ -843,7 +838,7 @@ advisable if security is a concern. USB 2.0 has plenty of bandwidth for many HDDs (a few high-end ones can use more bandwidth than USB 2.0 is capable of), but for SSDs it might be problematic. USB 3.0 will provide more reasonable performance, though note that depending on the system, you may have -to deal with binary blob XHCI firmware in your kernel (if that bothers you). +to deal with binary vendor XHCI firmware in your kernel (if that bothers you). Use of USB is also not an absolute guarantee of safety, so do beware. The attack surface becomes much smaller, but a malicious drive could @@ -990,7 +985,7 @@ Besides software itself (embedded in ROM or not), most hardware We do not have a single device that can be considered be "100% free", and such absolutes are nearly impossible to reach. -Notable proprietary blobs (not a complete list): +Notable vendor code present (example) (not a complete list): * All devices * SATA/PATA Hard Drive/Optical Disc Drive Firmware diff --git a/site/footer.include b/site/footer.include index 537d002..655c18c 100644 --- a/site/footer.include +++ b/site/footer.include @@ -1,7 +1,7 @@ ------------------------------------------------------------------------------- -* [Binary blob policy](/news/policy.md) +* [Binary Blob Reduction Policy](/news/policy.md) * [Edit this page](/git.md) * [Who develops Libreboot?](/who.md) * [License](/license.md) diff --git a/site/freedom-status.md b/site/freedom-status.md index 086ba62..eec8e12 100644 --- a/site/freedom-status.md +++ b/site/freedom-status.md @@ -8,23 +8,23 @@ Introduction This page documents how Libreboot's [binary blob reduction policy](news/policy.md), adopted in November 2022, is implemented in practise, -especially that line which says: *"if a blob can be avoided, it must be -avoided."* +especially that line which says: *"if free software can be used, it must be +used."* Libreboot uses [coreboot](https://coreboot.org/) for hardware initialisation. While coreboot is nominally [*free* or *open source* software](https://writefreesoftware.org/), on *some* (not all) platforms, coreboot *requires* certain -[blobs](https://en.wikipedia.org/wiki/Binary_blob) +[vendor files](https://en.wikipedia.org/wiki/Binary_blob) for things like raminit. *All* boards currently supported by Libreboot can be initialised entirely with *free*, *libre* or *open source* code from *coreboot* itself, because Libreboot currently only focuses on such mainboards. Libreboot's goal is to eventually support *all* mainboards from coreboot. -A more *pragmatic* [binary blobs reduction policy](news/policy.md) was adopted +A more *pragmatic* [binary blob reduction policy](news/policy.md) was adopted by Libreboot during November 2022, as part of an ongoing campaign to support more hardware (from coreboot) within Libreboot, so as to provide *many more* -people with coreboot which, regardless of blob status, *does* provide increased +people with coreboot which, regardless of freedom status, *does* provide increased [software freedom](https://writefreesoftware.org/) compared to fully proprietary boot firmware which is what most people would otherwise use; Libreboot's modern policy is thus pragmatic, further @@ -164,7 +164,7 @@ specifically written by Leah Rowe, in 2014 and improved incrementally since. On newer platforms as alluded to above, `me_cleaner` is used instead. -Notes about specific types of blobs +Notes about specific types of vendor file =================================== VGA option ROMs @@ -175,7 +175,7 @@ Intel platforms that have it. The source code is provided by coreboot, under free license. In some cases, a laptop may have a graphics chip that is unsupported by -coreboot. In this situation, a binary blob called a *VGA Option ROM* must be +coreboot. In this situation, a vendor file called a *VGA Option ROM* must be used. Libreboot has *experimental* support for Nvidia GPU models of the Dell Latitude E6400, in an experimental branch where the build system automatically downloads the VGA ROM for it. This is currently *not* present in releases, or @@ -190,7 +190,7 @@ graphics on some ivybridge or haswell thinkpads. For *add-on* GPUs, SeaBIOS (payload) can typically scan a VGA ROM present on the card and execute it. This has been tested on certain desktop mainboards that Libreboot supports, and works just fine; Libreboot does not need to handle -these blobs at all. +these files at all. Libreboot's default is *always* freedom, when feasible in practise. Users who wish to have use of these additional GPUs, on such hardware, must take stock @@ -210,27 +210,28 @@ and W541) as of Libreboot 20230319 or higher. ARM platforms (chromebooks) ============= -Mostly blobless, except for the requirement on `daisy` and `peach` mainboards -to include BL1 bootloader blobs. These are: +Mostly free software, except for the requirement on `daisy` and `peach` mainboards +to include BL1 bootloader files from the vendor. These are: * HP Chromebook 11 G1 (daisy-spring) **(board removed from Libreboot, due to issues (will be re-added at a later date)** * Samsung Chromebook XE303 (daisy-snow) **(ditto)** * Samsung Chromebook 2 13” (peach-pi) **(ditto)** * Samsung Chromebook 2 11” (peach-pit) **(ditto)** -* nyan-* chromebooks also temporarily removed, but are blobless in Libreboot +* nyan-* chromebooks also temporarily removed, but are 100% free software in + Libreboot -List of blobs needed, specifically for each board +List of vendor files, specifically for each board ================================================= This article has thoroughly explained, in a detailed overview, the precise -nature as to *what* binary blobs are accomodated for in Libreboot. Again, +nature as to *what* vendor files are accomodated for in Libreboot. Again, fully libre init from coreboot is available *on all currently supported boards*. *From coreboot* is the critical aspect of this, but Libreboot's full scope is the main flash IC which (in some cases) contains software outside of coreboot. -Here is a list, *for each* board, of those blobs: +Here is a list, *for each* board, of those files: Intel/x86 --------- @@ -258,9 +259,9 @@ This applies to the following targets: `hp2170p_16mb`, `hp2560p_8mb`, is inserted into main boot flash, rather than being on a separate IC. This is *better* because libre replacements would be more easy to install in the future, and reverse engineering is made much easier by it. Libreboot's -build system handles such firmware in `blobutil`, automatically downloading +build system handles such firmware in a script, automatically downloading it during the build process. Libreboot 20230423 onwards does scrub EC firmware -and provide functionality in `blobutil` insert, to insert them with `cbfstool` +and provide functionality in a special script, to insert them with `cbfstool` at the correct offset as defined by coreboot config for each board. ### SMSC SCH5545 Environmental Control @@ -283,7 +284,7 @@ introducing non-standard broken behaviour and it may result in the machine being unable to boot properly. In other cases, doing so may break features such as S3 suspend/resume. -CPU microcode blobs included by default, on all x86 boards. While not needed +CPU microcode files included by default, on all x86 boards. While not needed in most cases, their use is highly recommended. For reasons why, see: [news/policy.md#more-detailed-insight-about-microcode](news/policy.md#more-detailed-insight-about-microcode) @@ -315,7 +316,7 @@ ARM/chromebooks BL1 bootloader needed on: `daisy_snow`, `daisy_spring` and `peach_pit`. These boards are *currently* not present. They were removed from Libreboot, -because the build system does not yet auto-insert the BL1 blobs. The boards +because the build system does not yet auto-insert the BL1 files. The boards are otherwise believed to work, using Alper's port of U-Boot in Libreboot. Conclusion @@ -326,7 +327,7 @@ blobs reduction policy*, with the emphasis on *reduction* being most critical. It can be asserted that Libreboot does in fact provide a reasonable level of *software freedom*, on all boards. -Libreboot *could* add a lot more blobs for various platforms, to enable various +Libreboot *could* add a lot more such files for many platforms, to enable various extra features, that it instead avoids adding, precisely because the *purpose* of the Libreboot project is to promote *libre* software and *minimise* the power that proprietary software developers have over users. diff --git a/site/freedom-status.uk.md b/site/freedom-status.uk.md index a2e139c..2f1950e 100644 --- a/site/freedom-status.uk.md +++ b/site/freedom-status.uk.md @@ -349,9 +349,9 @@ This applies to the following targets: `hp2170p_16mb`, `hp2560p_8mb`, is inserted into main boot flash, rather than being on a separate IC. This is *better* because libre replacements would be more easy to install in the future, and reverse engineering is made much easier by it. Libreboot's -build system handles such firmware in `blobutil`, automatically downloading +build system handles such firmware with scripts, automatically downloading it during the build process. Libreboot 20230423 onwards does scrub EC firmware -and provide functionality in `blobutil` insert, to insert them with `cbfstool` +and provide functionality in a special script, to insert them with `cbfstool` at the correct offset as defined by coreboot config for each board. ### SMSC SCH5545 Environmental Control diff --git a/site/news/censored-libreboot20230710.md b/site/news/censored-libreboot20230710.md index 29857f2..847d8cf 100644 --- a/site/news/censored-libreboot20230710.md +++ b/site/news/censored-libreboot20230710.md @@ -69,7 +69,7 @@ has been *removed* (censored), in this version, hence the name: *Censored Libreboot*. More information available here: -You can find out about the current status of binary blobs, on the [Freedom +You can find out about the current freedom status per board, on the [Freedom Status](../freedom-status.md) page. It describes how Libreboot policy is implemented, in great detail. diff --git a/site/news/e6400nvidia.md b/site/news/e6400nvidia.md index 8059688..1b3eff9 100644 --- a/site/news/e6400nvidia.md +++ b/site/news/e6400nvidia.md @@ -47,19 +47,6 @@ to Dell Latitude E6400 documentation in Libreboot; specifically, the [E6400 info page](../docs/hardware/e6400.md) and [E6400 flashing guide](../docs/install/e6400.md). -Nicholas Chin, author of the original Dell E6400 port, has been helping me and -I've been working on this experimental branch of Libreboot under his -guidance: - -* - -*These* patches were already merged in Libreboot's master branch, which the -changes in the WIP branch rely upon: - -* Import the `bios_extract` utilities in lbmk: -* Bug fixes from Nicholas for `bios_extract`: -* blobutil: support downloading VGA ROM for Nvidia E6400: - Ongoing development discussion is available, on the Libreboot bug tracker. See: * diff --git a/site/news/libreboot20221214.md b/site/news/libreboot20221214.md index e728208..4774961 100644 --- a/site/news/libreboot20221214.md +++ b/site/news/libreboot20221214.md @@ -22,11 +22,11 @@ yourself. FAILURE to adhere to this warning may result in you bricking your machine (rendering it unbootable), if you were to flash the release ROMs without modifying them in any way. For more information, please read:** -**[Insert binary blobs on Sandybridge/Ivybridge/Haswell](../docs/install/ivy_has_common.md)** +**[Insert vendor files on Sandybridge/Ivybridge/Haswell](../docs/install/ivy_has_common.md)** This isn't required on *all* Libreboot-supported boards, but if in doubt, follow -these instructions anyway. If you run `blobutil` on a board that doesn't need -blobs, nothing will happen. +these instructions anyway. If you run the vendor scripts on a board that doesn't +need vendor files, nothing will happen. Build from source ----------------- diff --git a/site/news/libreboot20230319.md b/site/news/libreboot20230319.md index fa51c3e..c3fc459 100644 --- a/site/news/libreboot20230319.md +++ b/site/news/libreboot20230319.md @@ -43,11 +43,11 @@ yourself. FAILURE to adhere to this warning may result in you bricking your machine (rendering it unbootable), if you were to flash the release ROMs without modifying them in any way. For more information, please read:** -**[Insert binary blobs on Sandybridge/Ivybridge/Haswell](../docs/install/ivy_has_common.md)** +**[Insert vendor files on Sandybridge/Ivybridge/Haswell](../docs/install/ivy_has_common.md)** This isn't required on *all* Libreboot-supported boards, but if in doubt, follow -these instructions anyway. If you run `blobutil` on a board that doesn't need -blobs, nothing will happen. +these instructions anyway. If you run the vendor scripts on a board that doesn't +need any vendor files, nothing will happen. Build from source ----------------- @@ -75,7 +75,7 @@ The changes can be summarised, thus: ThinkPad W541). This is using patches from Angel Pons (hell on coreboot IRC), that are currently still in review on coreboot master. The *old* configs that use `mrc.bin` for raminit are still available aswell, so this release - contains ROMs with libre raminit *and* ROMs with blob raminit. The reasons + contains ROMs with libre raminit *and* ROMs with vendor raminit. The reasons are explained below. * **FIXED S3 suspend/resume on Haswell (T440p/W541)** - but only on configs that use `mrc.bin`. The images with libre MRC still have broken S3. S3 @@ -139,17 +139,17 @@ In this release, and in the build system, the following targets are defined: * `t440p_12mb`: libre raminit code used (reverse engineered replacement of `mrc.bin`) * `w541_12mb`: ditto (libre raminit code) -* `t440pmrc_12mb`: blob `mrc.bin` used for raminit. GRUB and SeaBIOS payloads +* `t440pmrc_12mb`: vendor `mrc.bin` used for raminit. GRUB and SeaBIOS payloads both supported. -* `w541mrc_12mb`: blob `mrc.bin` used for raminit. GRUB and SeaBIOS payloads +* `w541mrc_12mb`: vendor `mrc.bin` used for raminit. GRUB and SeaBIOS payloads both supported. The libre raminit comes from this patchset: -The MRC blob (and Angel's replacement code) don't just do raminit, they handle -a few other init tasks aswell, including USB host controller. +The MRC vendor file (and Angel's replacement code) don't just do raminit, they +handle a few other init tasks aswell, including USB host controller. New boards, x86 ---------- diff --git a/site/news/libreboot20230413.md b/site/news/libreboot20230413.md index d1b570c..1809713 100644 --- a/site/news/libreboot20230413.md +++ b/site/news/libreboot20230413.md @@ -43,11 +43,11 @@ yourself. FAILURE to adhere to this warning may result in you bricking your machine (rendering it unbootable), if you were to flash the release ROMs without modifying them in any way. For more information, please read:** -**[Insert binary blobs on Sandybridge/Ivybridge/Haswell](../docs/install/ivy_has_common.md)** +**[Insert vendor files on Sandybridge/Ivybridge/Haswell](../docs/install/ivy_has_common.md)** This isn't required on *all* Libreboot-supported boards, but if in doubt, follow -these instructions anyway. If you run `blobutil` on a board that doesn't need -blobs, nothing will happen. +these instructions anyway. If you run the vendor scripts on a board that doesn't +need any vendor files, then nothing will happen. Build from source ----------------- diff --git a/site/news/libreboot20230423.md b/site/news/libreboot20230423.md index 09b7771..b0aa902 100644 --- a/site/news/libreboot20230423.md +++ b/site/news/libreboot20230423.md @@ -42,11 +42,11 @@ yourself. FAILURE to adhere to this warning may result in you bricking your machine (rendering it unbootable), if you were to flash the release ROMs without modifying them in any way. For more information, please read:** -**[Insert binary blobs on Sandybridge/Ivybridge/Haswell](../docs/install/ivy_has_common.md)** +**[Insert vendor files on Sandybridge/Ivybridge/Haswell](../docs/install/ivy_has_common.md)** This isn't required on *all* Libreboot-supported boards, but if in doubt, follow -these instructions anyway. If you run `blobutil` on a board that doesn't need -blobs, nothing will happen. +these instructions anyway. If you run the vendor scripts on a board that doesn't +need vendor files, nothing will happen. Build from source ----------------- diff --git a/site/news/libreboot20230625.md b/site/news/libreboot20230625.md index 442adcb..a50ab91 100644 --- a/site/news/libreboot20230625.md +++ b/site/news/libreboot20230625.md @@ -44,11 +44,11 @@ yourself. FAILURE to adhere to this warning may result in you bricking your machine (rendering it unbootable), if you were to flash the release ROMs without modifying them in any way. For more information, please read:** -**[Insert binary blobs on Sandybridge/Ivybridge/Haswell](../docs/install/ivy_has_common.md)** +**[Insert vendor files on Sandybridge/Ivybridge/Haswell](../docs/install/ivy_has_common.md)** This isn't required on *all* Libreboot-supported boards, but if in doubt, follow -these instructions anyway. If you run `blobutil` on a board that doesn't need -blobs, nothing will happen. +these instructions anyway. If you run the vendor scripts on a board that doesn't +need vendor files, nothing will happen. A note about the changelog -------------------------- diff --git a/site/news/microcode.md b/site/news/microcode.md index 5b62feb..ad157d9 100644 --- a/site/news/microcode.md +++ b/site/news/microcode.md @@ -21,17 +21,17 @@ about microcode on the [FAQ](../faq.md#microcode) and In the next Libreboot releases, ROM images that *exclude* CPU microcode updates will once again be available. Libreboot's [Binary Blob Reduction -Policy](policy.md) dictates that each mainboard must be provided with as few -binary blobs as possible, ideally none. *At present*, *all* x86 and ARM +Policy](policy.md) dictates that each mainboard must be provided with **as few** +binary blobs as possible, ideally **none**. *At present*, *all* x86 and ARM mainboards supported in Libreboot (in `lbmk.git` and in releases) can boot with entirely [free software](https://writefreesoftware.org/), -requiring *zero* blobs of any kind from *coreboot*. +requiring *zero* vendor files of any kind within *coreboot*. The nuance of how Libreboot *implements* this policy is described in the [Freedom Status](../freedom-status.md) page. Although coreboot (which Libreboot uses for hardware initialisation) *is* a [free software](https://writefreesoftware.org/) project, -certain binary blobs are needed on some platforms, for things like raminit +certain vendor files are needed on some platforms, for things like raminit (memory controller initialisation). Libreboot tries to reduce or eliminate these, or mitigate their existence (for example, `me_cleaner` is used on newer Intel platforms). @@ -54,7 +54,7 @@ Why? ---- Freedom of choice, that's why. Libreboot's policy explicitly -[states](policy.md#configuration), in the context of *adding* binary blobs: +[states](policy.md#configuration), in the context of *adding* vendor files: *It’s natural that the user may want to create a setup that is less libre than the default one in libreboot. This is perfectly acceptable; freedom is superior, @@ -87,15 +87,15 @@ In `board.cfg` for each mainboard defined (in Libreboot's build system, lbmk), the following entries are available: * `microcode_required="n" or "y"` (it's "n" on ALL boards) -* `blobs_required="n" or "y"`("n" on MOST boards) +* `vendorfiles="n" or "y"`("n" on MOST boards) -If `blobs_required="n"`, the given ROM image `filename.rom` +If `vendorfiles="n"`, the given ROM image `filename.rom` becomes `filename_noblobs.bin` for all versions of it. In this context, *noblobs* means *zero* blobs in the entire boot flash when the final ROM image is flashed to it, regardless of whether coreboot is blob-free, irrespective of microcode updates. ROM images containing `noblobs` in the filename *may* still contain microcode -updates, distinguishing *microcode* as a special kind of blob distinct +updates, distinguishing *microcode* as a special kind of vendor file distinct from all others. With or without `_noblobs` in the name: @@ -103,11 +103,11 @@ With or without `_noblobs` in the name: If `microcode_required="n"`, the given ROM image `filename.rom` is either: -* If no microcode blob exists within it already, such as on ARM +* If no microcode file exists within it already, such as on ARM mainboards, the ROM is simply copied to: `filename_nomicrocode.rom` * If the ROM contains microcode (default on most x86 boards, except Qemu or in rare cases where none are advised), `filename.rom` is retained and - is copied to `filename_nomicrocode.rom`, and the CPU microcode update blob + is copied to `filename_nomicrocode.rom`, and the CPU microcode update file shall be removed from `filename_nomicrocode.rom`. What this means is that ROMs *with* OR *without* microcode will be present, @@ -139,7 +139,7 @@ In previous releases of Libreboot, no-microcode was the default (microcode updates were excluded entirely, from all releases). This policy was changed during November 2022, as part of an ongoing campaign to support more hardware (from coreboot) within Libreboot, so as to provide many more people with -coreboot which, regardless of blob status on each platform, *does* provide +coreboot which, regardless of freedom status on each platform, *does* provide increased software freedom compared to fully proprietary boot firmware, which is what people would otherwise use; thus, Libreboot's modern policy is pragmatic, advancing further the cause of *software freedom*. diff --git a/site/news/policy.de.md b/site/news/policy.de.md index da708cd..a6b3016 100644 --- a/site/news/policy.de.md +++ b/site/news/policy.de.md @@ -72,9 +72,9 @@ Default configurations ---------------------- Coreboot, upon which Libreboot is based, is mostly libre software but does -require binary blobs on some platforms. A most common example might be raminit +require vendor files on some platforms. A most common example might be raminit (memory controller initialisation) or video framebuffer initialisation. The -coreboot firmware uses binary blobs for some of these tasks, on some mainboards, +coreboot firmware uses certain vendor code for some of these tasks, on some mainboards, but some mainboards from coreboot can be initialised with 100% libre source code, which you can inspect, and compile for your use. @@ -83,21 +83,21 @@ nature of this is what you're about to read. The libreboot project has the following policy: -* If a blob *can* be avoided, it should be avoided. For example, if VGA ROM +* If free software *can* be used, it *should* be used. For example, if VGA ROM initialization otherwise does a better job but coreboot has *libre* init code for a given graphics device, that code should be used in libreboot, when building a ROM image. Similarly, if *memory controller initialization* is - possible with a binary blob *or* libre code in coreboot, the *libre* code - should be used in ROMs built by the Libreboot build system, and the *blob* - for raminit should not be used; however, if no libre init code is available + possible with vendor code *or* libre code in coreboot, the *libre* code + should be used in ROMs built by the Libreboot build system, and the *vendor* + raminit code should not be used; however, if no libre init code is available for said raminit, it is permitted and Libreboot build system will use the - *blob*. + *vendor* code. * Some nuance is to be observed: on some laptop or desktop configurations, it's common that there will be *two* graphics devices (for example, an nvidia and an intel chip, using nvidia optimus technology, on a laptop). It may be that one of them has libre init code in coreboot, but the other one does not. It's perfectly acceptable, and desirable, for libreboot to support both devices, - and accomodate the required binary blob on the one that lacks native + and accomodate the required vendor code on the one that lacks native initialization. * An exception is made for CPU microcode updates: they are permitted, and in fact *required* as per libreboot policy. These updates fix CPU bugs, including @@ -111,8 +111,8 @@ The libreboot project has the following policy: to tell people how to *neuter* the ME, if possible on a given board. The `me_cleaner` program is very useful, and provides a much more secure ME configuration. -* Binary blobs should *never* be deleted, even if they are unused. In the - coreboot project, a set of `3rdparty` submodules are available, with binary +* Vendor blobs should *never* be deleted, even if they are unused. In the + coreboot project, a set of `3rdparty` submodules are available, with vendor blobs for init tasks on many boards. These must *all* be included in libreboot releases, even if unused. That way, even if the Libreboot build system does not yet integrate support for a given board, someone who downloads libreboot @@ -120,8 +120,8 @@ The libreboot project has the following policy: wish, to provide a configuration for their hardware. Generally speaking, common sense is applied. For example, an exception to the -minimalization might be if *blob* raminit and *libre* raminit are available, but -the *libre* one is so broken so as to be unusable. In that situation, the blob +minimalization might be if *vendor* raminit and *libre* raminit are possible, but +the *libre* one is so broken so as to be unusable. In that situation, the vendor one should be used instead, because otherwise the user might switch back to an otherwise fully proprietary system, instead of using coreboot (via libreboot). *Some* freedom is *better than none*. @@ -149,7 +149,7 @@ FREEDOM CATALOG =============== A *[freedom status](../freedom-status.md)* page should also be made available, -educating people about the status of binary blobs on each machine supported by +educating people about the software freedom status on each machine supported by the Libreboot build system. Please read: [Software and hardware freedom status for each mainboard supported by Libreboot](../freedom-status.md). @@ -283,7 +283,7 @@ provide incentive for levels of software freedom, such as: * FSF once endorsed the ThinkPad T400 with Libreboot, as sold by Minifree. This machine comes in two versions: with ATI+Intel GPU, or only Intel GPU. If ATI GPU, it's possible to configure the machine so that either GPU is used. If the - ATI GPU is to be used, a firmware blob is needed for initialization, though the + ATI GPU is to be used, a binary blob is needed for initialization, though the driver for it is entirely libre. *The FSF* ignored this fact and endorsed the hardware, so long as Libreboot does not enable the ATI GPU or tell people how to enable it. The *Intel* GPU on that machine has libre initialization code by @@ -314,13 +314,13 @@ what the FSF-endorsed GNU+Linux distros comply with. Basically, it bans all proprietary software, including device firmware. This may seem noble, but it's extremely problematic in the context of firmware. Food for thought: -* Excluding firmware blobs in the linux kernel is *bad*. Proprietary firmware +* Excluding vendor blobs in the linux kernel is *bad*. Proprietary firmware is *also bad*. Including them is a wiser choice, if strong education is also provided about *why they are bad* (less freedom). If you expose them to the user, and tell them about it, there is greater incentive (by simple reminder of their existence) to reverse engineer and replace them. * Firmware *in your OS kernel* is *good*. The FSF simultaneously gives the OK - for hardware *with those same firmware blobs* if the firmware is embedded + for hardware *with those same binary blobs* if the firmware is embedded into a ROM/flash chip on the device, or embedded in some processor. If the firmware is on separate ROM/flash, it could still be replaced by the user via reverse engineering, but then you would probably have to do some soldering diff --git a/site/news/policy.md b/site/news/policy.md index b66d751..82f92f6 100644 --- a/site/news/policy.md +++ b/site/news/policy.md @@ -1,4 +1,4 @@ -% Binary blob reduction policy +% Binary Blob Reduction Policy % Leah Rowe % 4 January 2022 (updated 15 November 2022) @@ -67,9 +67,9 @@ Default configurations ---------------------- Coreboot, upon which Libreboot is based, is mostly libre software but does -require binary blobs on some platforms. A most common example might be raminit +require certain vendor code on some platforms. A most common example might be raminit (memory controller initialisation) or video framebuffer initialisation. The -coreboot firmware uses binary blobs for some of these tasks, on some mainboards, +coreboot firmware uses certain vendor code for some of these tasks, on some mainboards, but some mainboards from coreboot can be initialised with 100% libre source code, which you can inspect, and compile for your use. @@ -78,21 +78,21 @@ nature of this is what you're about to read. The libreboot project has the following policy: -* If a blob *can* be avoided, it should be avoided. For example, if VGA ROM +* If free software *can* be used, it *should* be used. For example, if VGA ROM initialization otherwise does a better job but coreboot has *libre* init code for a given graphics device, that code should be used in libreboot, when building a ROM image. Similarly, if *memory controller initialization* is - possible with a binary blob *or* libre code in coreboot, the *libre* code - should be used in ROMs built by the Libreboot build system, and the *blob* - for raminit should not be used; however, if no libre init code is available + possible with vendor code *or* libre code in coreboot, the *libre* code + should be used in ROMs built by the Libreboot build system, and the *vendor* + raminit code should not be used; however, if no libre init code is available for said raminit, it is permitted and Libreboot build system will use the - *blob*. + *vendor* code. * Some nuance is to be observed: on some laptop or desktop configurations, it's common that there will be *two* graphics devices (for example, an nvidia and an intel chip, using nvidia optimus technology, on a laptop). It may be that one of them has libre init code in coreboot, but the other one does not. It's perfectly acceptable, and desirable, for libreboot to support both devices, - and accomodate the required binary blob on the one that lacks native + and accomodate the required vendor code on the one that lacks native initialization. * An exception is made for CPU microcode updates: they are permitted, and in fact *required* as per libreboot policy. These updates fix CPU bugs, including @@ -106,17 +106,17 @@ The libreboot project has the following policy: to tell people how to *neuter* the ME, if possible on a given board. The `me_cleaner` program is very useful, and provides a much more secure ME configuration. -* Binary blobs should *never* be deleted, even if they are unused. In the - coreboot project, a set of `3rdparty` submodules are available, with binary - blobs for init tasks on many boards. These must *all* be included in libreboot +* Vendor blobs should *never* be deleted, even if they are unused. In the + coreboot project, a set of `3rdparty` submodules are available, with vendor + code for init tasks on many boards. These must *all* be included in libreboot releases, even if unused. That way, even if the Libreboot build system does not yet integrate support for a given board, someone who downloads libreboot can still make changes to their local version of the build system, if they wish, to provide a configuration for their hardware. Generally speaking, common sense is applied. For example, an exception to the -minimalization might be if *blob* raminit and *libre* raminit are available, but -the *libre* one is so broken so as to be unusable. In that situation, the blob +minimalization might be if *vendor* raminit and *libre* raminit are available, but +the *libre* one is so broken so as to be unusable. In that situation, the vendor one should be used instead, because otherwise the user might switch back to an otherwise fully proprietary system, instead of using coreboot (via libreboot). *Some* freedom is *better than none*. @@ -145,7 +145,7 @@ FREEDOM CATALOG =============== A *[freedom status](../freedom-status.md)* page should also be made available, -educating people about the status of binary blobs on each machine supported by +educating people about the software freedom status on each machine supported by the Libreboot build system. Please read: [Software and hardware freedom status for each mainboard supported by Libreboot](../freedom-status.md). @@ -279,7 +279,7 @@ provide incentive for levels of software freedom, such as: * FSF once endorsed the ThinkPad T400 with Libreboot, as sold by Minifree. This machine comes in two versions: with ATI+Intel GPU, or only Intel GPU. If ATI GPU, it's possible to configure the machine so that either GPU is used. If the - ATI GPU is to be used, a firmware blob is needed for initialization, though the + ATI GPU is to be used, a binary blob is needed for initialization, though the driver for it is entirely libre. *The FSF* ignored this fact and endorsed the hardware, so long as Libreboot does not enable the ATI GPU or tell people how to enable it. The *Intel* GPU on that machine has libre initialization code by @@ -304,8 +304,8 @@ Problems with FSDG The FSF maintains another set of criteria, dubbed Free System Distribution Guidelines (GNU FSDG)]. They recommend a special version of the Linux kernel, -dubbed *linux-libre*, which removes all firmware blobs from upstream. These -firmware blobs are required for certain hardware to work correctly. +dubbed *linux-libre*, which removes all vendor code from upstream. These +vendor files are required for certain hardware to work correctly. The FSDG criteria is separate from RYF, but has similar problems. FSDG is what the FSF-endorsed GNU+Linux distros comply with. Basically, it bans @@ -322,13 +322,13 @@ freedom, but all it does is reduce freedom of choice; somebody else has already made that decision for you, *against* you.** You should not use linux-libre at all. Some wisdom: -* Excluding firmware blobs in the linux kernel is *bad*. Proprietary firmware +* Excluding vendor blobs in the linux kernel is *bad*. Proprietary firmware is *also bad*. Including them is a wiser choice, if strong education is also provided about *why they are bad* (less freedom). If you expose them to the user, and tell them about it, there is greater incentive (by simple reminder of their existence) to reverse engineer and replace them. * Firmware *in your OS kernel* is *good*. The FSF simultaneously gives the OK - for hardware *with those same firmware blobs* if the firmware is embedded + for hardware *with those same binary blobs* if the firmware is embedded into a ROM/flash chip on the device, or embedded in some processor. If the firmware is on separate ROM/flash, it could still be replaced by the user via reverse engineering, but then you would probably have to do some soldering diff --git a/site/news/safety.md b/site/news/safety.md index c1efa9b..d4bbd41 100644 --- a/site/news/safety.md +++ b/site/news/safety.md @@ -19,33 +19,33 @@ users have been bricking their machines, on the following mainboards: Why? ---- -On these platforms, the following binary blobs are required: +On these platforms, the following binary vendor files are required: * Intel ME firmware: all Sandy/Ivy/Haswell boards. Libreboot's build system runs `me_cleaner` to neuter the Intel ME, so that it's disabled after BringUp. * Intel MRC firmware: Haswell platforms (W541, T440p) - a libre MRC replacement - is available, but experimental, and the blob version is still recommended. + is available, but experimental, and the vendor version is still recommended. * KBC1126 EC firmware: HP laptops (all sandy/ivy/haswell) When you [build Libreboot from source](../docs/build/), Libreboot's automated -build system (lbmk) automatically downloads these blobs directly from the +build system (lbmk) automatically downloads these files directly from the hardware vendor, and inserts them into the ROM during build time. -However, these blobs are not redistributable, so Libreboot's build system (lbmk) -automatically scrubs (deletes) these blobs, from each ROM image, prior to +However, these files are not redistributable, so Libreboot's build system (lbmk) +automatically scrubs (deletes) these files, from each ROM image, prior to archiving the ROM images for release. What this means is exactly as implied: If you simply flash the release ROMs as-is, *without* modification, you will -be flashing them *without* these required blobs. This is exactly what some +be flashing them *without* these required files. This is exactly what some people have been doing. -Instructions are given here, for how to insert these blobs on release ROMs: +Instructions are given here, for how to insert these files on release ROMs: -[Insert binary blobs on Sandybridge/Ivybridge/Haswell](../docs/install/ivy_has_common.md) +[Insert vendor files on Sandybridge/Ivybridge/Haswell](../docs/install/ivy_has_common.md) -The linked guide makes use of `blobutil`, lbmk's single centralised utility that +The linked guide makes use of vendor scripts, that handles *all* firmwares, automatically for each given mainboard. It can automatically download and insert all of the following: @@ -97,7 +97,7 @@ Libreboot releases, on the affected machines: * If BIOS region blob-free (no MRC/EC firmware needed): set IFD, GbE and BIOS regions read-write by default, but lock the ME region. -* If BIOS region requires blobs inserted: set IFD and GbE regions read-write +* If BIOS region requires vendor files: set IFD and GbE regions read-write by default, but lock the ME and BIOS regions. In this configuration, internal flashing would still be possible, so that you @@ -120,7 +120,7 @@ one of three possible scenarios: Under this regime, some users may still brick their machines. For example, they might read the instructions for how to unlock regions, and then still -flash a ROM image without running `blobutil` on it - there is nothing we +flash a ROM image without running vendor scripts on it - there is nothing we can really do to prevent this, short of simply locking *all* regions, including the IFD region (if we did that, then users would need to externally re-flash their machine when updating).