site/docs/gnulinux/encryption.md

@@ -0,0 +1,102 @@
+# Fully Encrypted Boot and Root Partitions with Libreboot
+
+The following guide will explain how to create:
+
++ A boot partition (/dev/sda1 in this example) that GRUB can decrypt with 'passphrase1'
++ A root partition (/dev/sda2) with stronger encryption using 'passphrase2'
+
+This guide assumes you are working from a live disk of your preffered distro.
+
+# Creating Encrypted Boot Partition
+
+Grub2 currently (Oct 2021) supports luks2 encryption, which is great, but only the (not very strong) PBKDF2 algorithm.
+Start by creating a boot partition of around 1GB, you don't have to format it to anything as LUKS will overwrite it anyway.
+
+**Step 1:**
+Create a LUKS2 formatted device with the PBKDF2 algorithm.
+You can play around with the iteration count.
+A higher iteration is more secure but will take GRUB a **very** long time to decrypt.
+The [debian encrypted boot guide](https://cryptsetup-team.pages.debian.net/cryptsetup/encrypted-boot.html) recommends a count of 500,000 which will still take GRUB a very long time (around 25 seconds) but is faster than the default 1000,000.
+Use whatever count makes you feel comfortable.
+I'll use and arbitrarily low count.
+You'll also want to use a different password than you intend to use for your root partition.
+We don't want someone to be able to get our root key by brute-forcing our less secure boot key.
+
+`sudo cryptsetup luksFormat /dev/sda1 --type luks2 --pbkdf pbkdf2 --pbkdf-force-iterations 200000`
+
+**Step 2:**
+Format and mount the new LUKS2 device.
+
+```
+sudo cryptsetup luksOpen /dev/sda1 boot
+sudo mkfs.ext4 -L boot /dev/mapper/boot
+sudo mount /dev/mapper/boot /boot
+```
+**Note:**
+If you wish to change the passphrase for the boot partition in the future then you'll need to pass the same arguments to cryptsetup as when you created it.
+If you don't pass any special arguments, the key will be changed to the distro's default encryption and grub won't be able to decrypt it.
+The command to use is:
+
+`cryptsetup luksChangeKey /dev/sda1 --type luks2 --pbkdf pbkdf2 --pbkdf-force-iterations 200000`
+
+# Root Partition
+
+Setting up the root partion is generally simple.
+Use the same command without the given parametres used to make the device decryptable by GRUB.
+
+`cryptsetup luksFormat /dev/sda2 root`
+
+# Set Up Grub and Install
+
+You will need to pass the correct kernel parametres to your kernel on boot to allow you to use your encryption passphrase to decrypt the root partition.
+These parametres can be passed via a grub config in the boot partition by editing `/etc/default/grub.`
+
+Add the necessary parametres to the line `GRUB_CMDLINE_LINUX_DEFAULT` as follows:
+
+`GRUB_CMDLINE_LINUX_DEFAULT="loglevel=4 rd.auto=1 cryptdevice=/dev/sda2:root"`
+
+*rd.auto=1* tells linux that you want to decrypt all disks.
+*cryptdevice* tells linux the block device and mapped name you want to use for the root partition.
+Note that the mapped name **must** match what you have it `/etc/fstab.`
+
+From here, you can generally follow the install guide from your distro's docs.
+Make sure that the generated `/boot/grub/grub.cfg` file indeed contains the necessary kernel parametres and that the `/etc/default/grub` file on the disk has the same modifications described above.
+
+# Set up Fstab
+
+> The device holding the kernel (and the initramfs image) is unlocked by GRUB, but the root device needs to be unlocked again at initramfs stage, regardless whether it’s the same device. This is because GRUB boots with the given vmlinuz and initramfs images, but there is currently no way to securely pass cryptographic material (or Device Mapper information) to the kernel. Hence the Device Mapper table is initially empty at initramfs stage; in other words, all devices are locked, and the root device needs to be unlocked again.
+>
+> \- [Debian Guide](https://cryptsetup-team.pages.debian.net/cryptsetup/encrypted-boot.html)
+
+**Step 1:**
+Here, we're not trying to store the root key as we don't want to jeopardize the integrity of our root device.
+Instead, we want to store the key for the boot device on the root partition.
+
+```
+sudo mkdir -m0700 /etc/keys
+su -c '( umask 0077 && dd if=/dev/urandom bs=1 count=64 of=/etc/keys/boot.key conv=excl,fsync )'
+sudo cryptsetup luksAddKey /dev/sda1 /etc/keys/boot.key
+```
+
+**Step 2:**
+Add your boot device to your crypttab.
+You'll need to have the device's UUID.
+You can obtain the UUID from `blkid` or simply use the linux block device name `/dev/sda1,` acknowleding it may lead to another device if your disk configuration changes.
+
+```bash
+lsblk -o 'PATH,LABEL,UUID' # to get UUID
+sudo vim /etc/crypttab
+
+> boot_crypt UUID=YOUR_UUID /etc/keys/boot.key luks,key-slot=1
+```
+**Step 3:**
+Add the crypt device to your fstab.
+Use 'mount -a' to test your fstab configuration.
+NOTE: you will not be able to mount the device until it has been unlocked and mapped, rebooting with your new crypttab should do this automatically.
+
+```
+sudo vim /etc/fstab
+
+> /dev/mapper/boot_crypt /boot ext4 defaults 0 1
+sudo mount -a
+```

site/docs/gnulinux/index.md

@@ -26,14 +26,7 @@ Refer to the following pages:
 Encrypted (LUKS/dm-crypt) installations
 =======================================
 
-You should install with unencrypted `/boot` partition, but everything else
-encrypted. The GRUB payload has LUKSv1 support and (buggy) LUKSv2 support.
-
-There used to be guides for encrypted `/boot` on libreboot.org, but it's not
-really viable to do that anymore (with GRUB), due to buggy/incomplete LUKS
-support in GRUB.
-
-A better solution for that would be a Linux payload in flash, handling the
+A better solution for encryption would be a Linux payload in flash, handling the
 encryption, at least if you want to use Linux, because then it'll have
 perfect LUKS support.
 
@@ -43,18 +36,10 @@ logic in it that will try to automatically use whatever you have installed,
 by switching to it. In this way, most installations Just Work, so long as
 the `/boot` partition is accessible.
 
-If you do want encrypted /boot in your distro, please ensure that you have
-downgraded to LUKSv1, and generic advice for booting is this (press C to
-access a GRUB terminal, when you're in the GRUB payload):
-
-```
-set root=`lvm/bla-bla`
-linux /vmlinuz root=/dev/mapper/bla-bla cryptdevice=/dev/mapper/bla-bla:root
-initrd /initrd.img
-boot
-```
+Full encryption for basic LUKS2 is supported in libreboot.
+See [the guide](encryption.md) for more detail.
 
-Adapt according to your configuration.
+[The ZFSbootmenu guide](zfsbootmenu.md) builds upon the main encryption guide but describes a setup with ZFS native encryption and ZFSbootmenu.
 
 Rebooting system in case of freeze
 ===================================

site/docs/gnulinux/zfsbootmenu.md

@@ -0,0 +1,111 @@
+---
+title: ZFSbootmenu with Full Disk Encryption Guide
+x-toc-enable: true
+...
+
+As described in the [general encryption guide,](encryption.md) Libreboot allows for full disk encryption including the boot partition.
+Just as with the general guide, this explanation will demonstrate how to create a partition with moderate encryption for GRUB as well as a root partition with strong encryption.
+The major differences between the encryption method described in the general guide and this guide are:
+
++ `/boot` must remain on the *root* zfs encrypted partition
++ The root partition will be encrypted with ZFS native encryption rather than LUKS
++ ZFSbootmenu will be loaded at the second boot stage (after Libreboot itself) rather than directly loading the operating system kernel/initramfs
+
+[ZFSbootmenu](https://docs.zfsbootmenu.org/en/latest/) works by placing modified versions of the operating system kernel where they can be loaded by the system's bootloader.
+ZFSbootmenu provides installation guides for various major distros in their [official docs.](https://docs.zfsbootmenu.org/en/latest/)
+You should follow those docs for installation, only noting the differences necessary for full disk encryption described below.
+The only differences between this guide and the docs are:
+
++ You need not install/configure syslinux as GRUB in Libreboot will be used to load the ZFSbootmenu kernel/initramfs
++ The ZFSbootmenu kernel/initramfs will reside on a LUKS encrypted partition you will create in this guide
++ Cryptsetup must be installed and configured to mount the LUKS encrypted partition
+
+## Creating Encrypted Partition for GRUB
+
+The following section is mostly identical to the main encryption guide except for the naming conventions of the partition in question.
+When using ZFSbootmenu, the OS kernel/initramfs will reside on the root partion in the `/boot` directory; **not** on a separate boot partition.
+The partition created in this section is only used to load the ZFSbootmenu kernel/initramfs itself and is therefore referred to as the 'pre-boot environment' *(pbe)* partition.
+
+**Step 1:**
+Create a LUKS2 formatted device with the PBKDF2 algorithm.
+You can play around with the iteration count.
+A higher iteration is more secure but will take GRUB a **very** long time to decrypt.
+The [debian encrypted boot guide](https://cryptsetup-team.pages.debian.net/cryptsetup/encrypted-boot.html) recommends a count of 500,000 which will still take GRUB a very long time (around 25 seconds) but is faster than the default 1,000,000.
+Use whatever count makes you feel comfortable.
+I'll use an arbitrarily low count.
+You'll also want to use a different password than you intend to use for your root partition.
+We don't want someone to be able to get our root key by brute-forcing our less secure boot key.
+
+`sudo cryptsetup luksFormat /dev/sda1 --type luks2 --pbkdf pbkdf2 --pbkdf-force-iterations 200000`
+
+**Step 2:**
+Format and mount the new LUKS2 device.
+
+```
+sudo cryptsetup luksOpen /dev/sda1 pbe
+sudo mkfs.ext4 -L boot /dev/mapper/pbe
+sudo mkdir -p /boot/pbe
+sudo mount /dev/mapper/boot /boot/pbe
+```
+**Note:**
+If you wish to change the passphrase for the boot partition in the future then you'll need to pass the same arguments to cryptsetup as when you created it.
+If you don't pass any special arguments, the key will be changed to the distro's default encryption and grub won't be able to decrypt it.
+The command to use is:
+
+`cryptsetup luksChangeKey /dev/sda1 --type luks2 --pbkdf pbkdf2 --pbkdf-force-iterations 200000`
+
+## Configure ZFSbootmenu
+
+The [official ZFSbootmenu docs](https://docs.zfsbootmenu.org/en/latest/guides/general.html) will provide the most up-to-date information.
+The only differences from the official documentation relevant here are that anything related to syslinux can be ignored and the configuration must be tailored to create only a single kernel/initramfs set.
+Note that you should follow the *MBR/syslinux* guide for your distro if you are using the ZFSbootmenu guides.
+
+Here is an example configuration:
+
+```
+> vim /etc/zfsbootmenu/config.yaml
+
+Global:
+  ManageImages: true
+  BootMountPoint: /boot/pbe
+  DracutConfDir: /etc/zfsbootmenu/dracut.conf.d
+  PreHooksDir: /etc/zfsbootmenu/generate-zbm.pre.d
+  PostHooksDir: /etc/zfsbootmenu/generate-zbm.post.d
+  InitCPIOConfig: /etc/zfsbootmenu/mkinitcpio.conf
+Components:
+  ImageDir: /boot/pbe/zfsbootmenu
+  Versions: false
+  Enabled: true
+  syslinux:
+    Config: /boot/syslinux/syslinux.cfg
+    Enabled: false
+EFI:
+  ImageDir: /boot/pbe
+  Versions: false
+  Enabled: false
+Kernel:
+  CommandLine: ro quiet loglevel=4
+```
+
+## Final Steps
+
+Refer to the [general guide](encryption.md) on how to set up fstab/crypttab to mount the pre-boot environment on boot.
+Replace references to *boot* with *pbe* if copying commands from the guide.
+For example: make sure the partition is mounted at `/boot/pbe` rather than just `/boot.`
+
+Ensure that your OS kernel/initramfs is generated with LUKS support.
+LUKS support is generally automatically enabled in the kernel upon installing *cryptsetup.*
+
+Create a simulated grub configuration to point Libreboot's GRUB to ZFSbootmenu.
+Libreboot will search for and source a grub configuration file on boot/decryption automatically.
+**Do not** actually install GRUB.
+Simply create a file on the partition created for GRUB at `/boot/pbe/grub/grub.cfg` which points to the ZFSbootmenu kernel/initramfs.
+
+```
+mkdir -p /boot/pbe/grub
+> vim /boot/pbe/grub/grub.cfg
+
+linux /zfsbootmenu/vmlinuz-* loglevel=4
+initrd /zfsbootmenu/initramfs-*
+boot
+```

site/docs/install/ivy_has_common.md

@@ -92,6 +92,13 @@ 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.**
 
+**NOTE: In the Libreboot 20230319 src archive or git tag, the `blobutil`
+insert method is broken on Haswell configs that need `mrc.bin`, because it does
+not insert `mrc.bin` at the correct offset. This was fixed in revisions after
+the release, and will be available in the next release after that. Read
+the [Libreboot 20230319 update
+announcement](../../news/libreboot20230319_update.md) for more information.**
+
 NOTE: the MAC changer makes use of `nvmutil`, which you can read more about in
 the [nvmutil documentation](nvmutil.md).
 

site/faq.md

@@ -845,7 +845,7 @@ Some proof of concepts have been demonstrated. For HDDs:
 
 Viable free replacement firmware is currently unknown to exist. For
 SSDs, the
-[OpenSSD](http://www.openssd-project.org/wiki/The_OpenSSD_Project)
+[OpenSSD](https://web.archive.org/web/20220425071606/http://www.openssd-project.org/wiki/The_OpenSSD_Project)
 project may be interesting.
 
 Apparently, SATA drives themselves don't have DMA but can make use of

site/faq.uk.md

@@ -846,7 +846,7 @@ LUKS і зберігати їх у незашифрованому вигляді
 
 Про існування життєздатної вільної заміни прошивки наразі невідомо. Для
 SSD проект
-[OpenSSD](http://www.openssd-project.org/wiki/The_OpenSSD_Project)
+[OpenSSD](https://web.archive.org/web/20220425071606/http://www.openssd-project.org/wiki/The_OpenSSD_Project)
 може бути цікавим.
 
 Очевидно, диски SATA самі по собі не мають DMA, але можуть використовувати його

site/freedom-status.uk.md

@@ -0,0 +1,417 @@
+---
+title: Статус свободи програмного та апаратного забезпечення для кожної плати, яка підтримується Libreboot
+x-toc-enable: true
+...
+
+Вступ
+============
+
+Коротка версія історії: *всі* плати, які наразі підтримуються Libreboot
+можна ініціалізувати в coreboot з *вільним*, *поважаючим свободу* або *з відкритим джерелом* кодом, який
+користувач може вивчати глибинно та адаптувати для своїх потреб, але існують
+деякі застереження та підводні камні, які користувач повинен знати, для деяких машин.
+
+Як багато користувачів може знати, coreboot (який Libreboot використовує для апаратної
+ініціалізації) номінально *Вільне від слова Воля*, *вільне* або *з відкритим джерелом*
+програмне забезпечення; хоча, coreboot намагається надати вільний код для ініціалізації кожної
+машини. Розробники coreboot працюють дуже потужно для зворотньої розробки якомога більшої
+кількості можливого функціоналу, для надання джерельного кода під вільною ліцензією.
+Цих людей варто відзначити, оскільки Libreboot не міг би існувати без таких
+зусиль з їх боку.
+
+На *деяких* платах, які coreboot підтримує, деякі двійкові блоби вимагаються.
+Це може бути для речей подібних ініціалізації кадрового буфера відео, налаштування
+контролерів пам'яті і так далі. Двійковий блоб це, в цьому контексті, будь-яке програмне забезпечення,
+яке тільки іде в формі виконуваного двійкового коду *з джерельним кодом недоступним*. Це
+робить складнішим (але не неможливим) вивчення того, як програми працюють, і ці
+блоби часто ідуть з обмеженням або на їх використання та/або розповсюдження.
+
+Мета цього документа - чітко описати наявність (або відсутність)
+двійкових блобів на кожній даній апаратній платформі або, у межах кожної платформи,
+на певних варіантах материнської плати. На веб-сайті Libreboot подібна інформація була
+відсутня або викладена погано, тому було вирішено написати офіційну
+документацію. Причиною такої відсутності було те, що Libreboot раніше
+давав підтримку *лише* для тих плат, які *не* потребують двійкових блобів
+у головній флеш-схемі для завантажувального мікропрограмного забезпечення, тому така документація не була потрібна.
+
+Більш *прагматична* політика була опублікована протягом листопада 2022 року, з поглядом
+на допомогу настільки багатьом людям, наскільки можливо, у встановленні coreboot, навіть на менш-ніж-ідеальному
+апаратному забезпеченні (продовжуючи також підтримувати більше дружнє до свободи апаратне забезпечення).
+Libreboot досі має суворі стандарти про те, *які* точно блоби дозволені,
+які ви можете прочитати в наступному документі, так:
+
+[Політика зменшення бінарних блобів](news/policy.uk.md)
+
+В цій статті ви вивчите всі шляхи (на практиці), якими Libreboot
+реалізовує цю *політику зменшення блобів*, особливо в тому рядку в ній, який каже,
+цитати, "якщо блоб можна уникнути, його необхідно уникнути".
+
+Чому це має значення?
+---------------------
+
+*Практичною метою* проекта Libreboot є підтримка якомога більшої кількості апаратного забезпечення
+підтримки coreboot, повністю протестованого з попередньо зібраними образами ROM
+та легкими інструкціями прошивки, направленими на нетехнічних користувачів, щоб привнести
+якомога більше користувачів в спільноту coreboot. З більшою кількістю користувачів, набагато
+більше людей відкриються coreboot і це неминуче призведе до більшої кількості
+людей, які розробляють coreboot, що є критичним проектом руху за вільне
+програмне забезпечення. З більшою кількістю розробників, більше *користувачів* матимуть змогу досягти рівень
+свободи або *суверенітету* в їх обчисленнях та, тому, цикл має продовжитись.
+
+Ця мета існує, тому що *ідеологічною метою* Libreboot є поширення
+свободи програмного забезпечення будь-якими необхідними засобами, настільки багатьом людям, наскільки можливо.
+Універсальний доступ до джерельного кода, здатність вивчати та змінювати код або
+перерозповсюджувати його, та виконувати його нескінченно з будь-якою метою надзвичайно важлива.
+Таким свободам варто бути *за замовчуванням* для всього програмного забезпечення. Це робить coreboot
+надзвичайно корисним, навіть у випадках, де двійковий блоб є необхідним для певної
+функціональності. Свободі варто бути *за замовчуванням* для всього програмного забезпечення, і це є
+метою *Libreboot* допомогти продемонструвати це реальністю.
+
+*Політика* проекта Libreboot, в межах цієї мети, надання такої
+підтримки апаратного забезпечення з якомога *меншою* можливою кількостю двійкових блобів, в ідеалі *відсутньою*, як
+у видку з багатьма конфігураціями, які підтримує Libreboot. Libreboot *спробує*
+підтримувати будь-яку дану одиницю апаратного забезпечення, навіть у випадках, де *повна*
+свобода програмного забезпечення не є можливою; наприклад, якщо coreboot вимагає блоб для
+raminit на даній платі, блоб було би надано Libreboot.
+
+*Ви можете прочитати політику зменшення/мінімалізації блобів Libreboot в більших подробицях.
+Будь ласка, прочитайте документ, названий: [Політика зменшення бінарних
+блобів](news/policy.uk.md).*
+
+Архітектура Coreboot
+---------------------
+
+Хоча не *суворо* необхідно для не-розробників, Ви можете знайти корисним
+набуття розуміння на високому рівні того, *як* працює coreboot, для набуття
+деякого контексту про деякі із тем, які обговорено в цій статті. Дивіться:
+
+<https://doc.coreboot.org/getting_started/architecture.html>
+
+100% вільна ініціалізація coreboot
+===========================
+
+*Всі* плати, які наразі підтримуються Libreboot можуть мати 100%
+вільну ініціалізацію *зі сторони coreboot*. В цьому контексті, це має на увазі
+будь-яку ініціалізацію, яка виконується головним процесором, для підняття машини для
+виконання кода.
+
+Завантажувальна прошивка не є *єдиним* програмним забезпеченням, присутнім в будь-якій машині, та існують
+деякі контексти, які потрібно зрозуміти, щоб побачити більшу картину.
+
+Причина, чому ця різниця має значення (посилаючись конкретно на сторону
+ініціалізації coreboot), стане зрозуміліше, в наступних секціях:
+
+Універсальний захист зроблено в Libreboot, дозволяючи (читайте: вимагаючи, згідно з
+політикою проекту) включення оновлень мікрокоду ЦП, якщо доступно. Ви можете
+прочитати більше про це і причини *чому*, прочитавши наступну статтю:
+
+[Оновлення мікрокоду ЦП
+є **нормальним**](news/policy.uk.md#більш-детальна-інформація-про-мікрокод)
+
+Платформи Intel
+===============
+
+Дескрипторне проти бездескрипторного налаштування
+----------------------------------
+
+Libreboot підтримує декілька материнських плат, які використовують платформи Intel. Серед них існує
+суттєво два класи машин (для цілей цієї статті):
+
+* Бездескрипторне налаштування
+* Дескрипторне налаштування
+
+Що означає *дескриптор*? Гаразд, традиційно, основна флеш інтегральна мікросхема (яка містить
+завантажувальну прошивку, зазвичай на яку посилаються як на *BIOS*) на машинах Intel,
+містила тільки виконуваний код *x86*, який відповідає за ініціалізацію всього
+апаратного забезпечення, такого як ЦП, контролер пам'яті та периферії. Це те, що
+ми будемо називате *бездескрипторне* налаштування; в таких конфігураціях,
+прошивка Intel ME є відсутньою за замовчуванням.
+
+В *дескрипторному* налаштуванні, флеш поділений на регіони, такі як:
+
+* Intel flash descriptor: завжди перші 4Кбайт флеш. Закодовані двійково
+  конфігураційні дані для машини, та регіони (такі як цей, або
+  інші нижче) оголошено тут. Деяким чином, ви можете думати про це
+  аналогічно до *Master Boot Record* на жорсткому диску.
+* Intel GbE NVM (неволатильна пам'ять gigabit ethernet): закодовані двійково
+  конфігураційні дані, для пристроя Intel gigabit ethernet на платі, якщо такий
+  є присутнім. Вона містить багато налаштувань, таких як MAC-адреса, на якій швидкості мережева карта
+  має працювати, PCI ID, *швидкісті мерехтіння LED* та більше.
+  Якщо використовується мережева карта не Intel, цей флеш-регіон не буде присутнім.
+* ME (Intel Management Engine): *брудний* недолік безпеки в своєму стані
+  за замовчуванням, ME надає багато функцій, таких як віддалене керування, з повним
+  мережевим функціоналом, ME є виділеним сопроцесором, окремим від головного ЦП, та
+  прошивка ініціалізації плюс операційна система для нього завантажується з
+  цього виділеного регіона в основній завантажувальній флеш-пам'яті. Більше інформації доступно [в
+  частих запитаннях](faq.uk.md#intelme) - там де в іншому випадку прошивка ME є присутньою, Libreboot
+  або видаляє її, або (за допомогою програми `me_cleaner`) переналаштовує її таким
+  чином, що його вимкнено в процесі ініціалізації машини.
+* Регіон платформи: непрограмні дані, зазвичай просто купа рядків розміщено тут
+  продавцем апаратного забезпечення.
+* Регіон BIOS: цей містить основну завантажувальну прошивку, відповідальну за
+  ініціалізацію ЦП, контролера пам'яті та периферії, призводячи
+  машину в стан, де вона може виконувати програми (скоріше за все, що завантажувач,
+  а потім операційну систему). Код coreboot (наданий Libreboot) іде
+  тут.
+
+*По суті*, ви можете думати про такі "регіони" за аналогією до *розділів* на
+жорсткому диску. Що важливо так це те, що інтегральна мікросхема флеш-пам'яті *розділена* на такі
+регіони, де кожний регіон призначено для конкретної мети.
+
+На деяких новіших дескрипторних платформах Intel, існує більше регіонів, ніж
+ці. В деяких випадках, *[вбудований
+контролер](faq.uk.md#прошивка-ec-вбудований-контролер)* (EC) може також
+бути в своєму власному гіоні на завантажувальній флеш-пам'яті; щонайменш, наразі, це не є
+актуальним ні на якому апаратному забезпеченні, яке підтримує Libreboot (натомість, це зберігається
+на окремій інтегральній мікросхемі).
+
+Вміст регіонів *дескриптора* та *GbE* описано в даташітах Intel,
+але ті даташіти часто містять *зарезервовані* секції, де
+частини залишені незадокументованими. Зусилля зворотної розробки протягом років
+задокументували деякі з цих прогалин.
+
+Libreboot *не* розповсюджує образи Intel ME
+-----------------------------------------------
+
+ME містить багато модулів в собі, і один з цих модулів це
+код BringUp. Цей код BringUp є *власною* прошивкою ініціалізації ME,
+подібною coreboot. Згідно з тією самою аналогією, інші модулі
+Intel ME (такі як: ядро ME) є подібними (концептуально) до
+*корисного навантаження coreboot*.
+
+Так, налаштування *нейтралізованого ME* є, на сопроцесорі intel ME, аналогічним до
+виконання coreboot без корисного навантаження. В цьому стані, ME ініціалізує себе
+готовим до виконання коду, але потім *насправді не виконує код*. Він таким чином не шкідливий,
+обидва з точки зору безпеки- та точки зору свободи. Іншими словами, ME
+є *вимкненим*.
+
+Libreboot *не* розповсюджує прошивку Intel ME жодним чином, ні в сховищі
+Git, ні в випусках. Де необхідно, Libreboot надає
+сценарії, які автоматично отримують та встановлюють її, в *нейтралізованому* стані, за
+допомогою виконання програми `me_cleaner`, про яку ви можете почитати тут:
+
+<https://github.com/corna/me_cleaner/wiki/How-does-it-work%3F>
+
+Це повністю автоматизовано. Якщо ви будуєте образи ROM з `lbmk.git`,
+автоматизованої системи побудови libreboot, прошивка ME буде завантажена,
+нейтралізована за допомогою `me_cleaner` та вставлена в фінальний образ ROM автоматично.
+
+*Випущені* образи ROM, надані попередньо зібраними, упускають прошивку Intel ME. На
+платформах, які вимагають її, *ті самі* сценарії, які вставляють її в процесі
+побудови, можуть *також* виконувати після-побудову, перевставляючи Intel ME в завантажувальну ROM. Це в
+зв'язку з проблемними питаннями ліцензіювання, оточуючими розповсюдження образів Intel ME.
+
+Система побудови Libreboot отримує її напряму від продавця для даної
+машини або набору машин (в якості приклада, Lenovo надає образи для декількох
+машин ThinkPad). Це гарантує, що кожен користувач отримує точно таку саму
+конфігурацію (іншою альтернативою є витаскування прошивки Intel ME з
+оригінального образа продавця, в регіоні ME інтегральної схеми флеш-пам'яті).
+
+Ви можете дізнатись про це більше на наступній сторінці:
+[docs/install/ivy_has_common.md](docs/install/ivy_has_common.md)
+
+Прошивка ME є *обов'язковою* на майже всіх платформах Intel, або машина
+*вимкнеться* після 30 хвилин. В нейтралізованому налаштуванні, код BringUp
+Intel ME вимкне той час скидання в 30 хвилин, дозволяючи вам використовувати ваш
+комп'ютер нормально, навіть незважаючи на те, що ME *не* виконує нічого після цього.
+
+Нейтралізований ME дійсно є вимкненим
+------------------------------
+
+Зважайте на це: якщо ME тільки робить свій власний BringUp, але потім не
+виконує нічого, чи це дійсно щось більше ніж незначний відтік часу життя вашої
+батареї? В нейтралізованому стані, Intel ME є лише неактивним комп'ютером
+на вашій материнській платі, таким, що нічого не робить, який вам не потрібен і який ви
+ніколи не будете використовувати. Таким чином, його можна розцінювати нешкідливим з обох перспективи свободи
+програмного забезпечення та перспективи безпеки, і це є поглядом, який взято
+проектом Libreboot.
+
+Якщо триматись цих припущень, і ви погодились зі статтею Libreboot про
+мікрокод, на яку наведено посилань зверху, і зважаєте *факт*, що (щонайменш, станом на
+зараз) Libreboot є здатним на повністю вільну ініціалізацію в межах coreboot, тоді
+ми можемо не без причини бути впевненими, що Libreboot надає гарний рівень свободи
+програмного забезпечення. Так, незважаючи на те, як дехто може інакше почувати, якщо вони *не* мають
+такої перспективи.
+
+Тобто, хоча код BringUp, який залишається для Intel ME *є* пропрієтарним,
+та не може бути модифікованим, в зв'язку з перевіркою криптографічного підпису
+апаратним забезпечення, це є програмним забезпеченням для пристрою, який ви ніколи не захочете насправді
+використовувати в реальному світі, тобто якщо він *не робить нічого* в нейтралізованому стані, тоді
+його може бути проігноровано на практиці. Це залежить від вашої точки зори, і деякі
+люди можуть займати більш догматичний підхід, ніж цей. Проект Libreboot
+зважає нейтралізовані налаштування ME прийнятними, обидва з перспекти безпеки
+та перспективи свободи програмного забезпечення.
+
+Більше про видалення/вимкнення Intel ME
+----------------------------------
+
+*Libreboot* надає шлях повністю видалити прошивку ME, зберігаючи
+повне використання машини, на платформах GM45 з південним мостом ICH9M. Це 
+ноутбуки: ThinkPad X200/T400/T500/W500 і так далі з того покоління. Дивіться:
+[docs/install/ich9utils.md](docs/install/ich9utils.md)
+
+На новіших платформах використовується `me_cleaner`. Ви можете прочитати про це тут:
+
+<https://github.com/corna/me_cleaner/wiki/How-does-it-work%3F>
+
+Option ROM VGA
+============
+
+*Нативна* ініціалізація відео підтримується та *увімкнена*, для всіх платформ
+Intel, які підтримуються, що мають її. Джерельний код надано coreboot, під
+вільною ліцензією.
+
+На *деяких* машинах, подвійна графіка є можливою. Наприклад, конкретні ThinkPad
+T440p материнські плати ідуть з обома графічними картками Intel та Nvidia, де ви можете
+або використовувати *обидві* або тільки Intel; для використання графічної картки Nvidia, двійковий блоб
+вимагається, який Libreboot не надає (і не захоче надавати), натомість вибираючи
+увімкнення тільки графічної карти *Intel* (де вільний код ініціалізації є доступним
+в coreboot). В більшості материнських плат T440p, *тільки* графічна картка Intel є фізично
+присутньою.
+
+На деяких материнських платах ThinkPad T400, W500 та T500, графічні карти ATI та Intel є
+присутніми, і ви можете використовувати або одну, або обидві. Ще раз, Libreboot *тільки* підтримує
+графічну картку Intel, де coreboot має вільний код ініціалізації.
+
+Це є прикладом нюансованого характеру в політиці Libreboot. Libreboot
+*міг* надавати подібні блоби, з судженням, що *необхідно*
+використовувати ці додаткові процесори. Однак, на практиці, ці машини є повністю придатними
+для використання лише з графікою Intel, для якої джерельний код є доступним.
+
+За замовчуванням Libreboot є *завжди* свобода, коли можливо на практиці. Користувачі, які
+бажають мати використання додаткових графічних процесорів, на такому апаратному забезпеченні, мають взяти до уваги
+наступний параграф у політиці Libreboot:
+
+*"Принципам зверху варто бути застосованими до конфігурацій за замовчування. Однак,	
+libreboot є налаштовуваним, дозволяючи користувачу робити все, що заманеться."* -
+налаштовуваний, напевно! Дивіться: [docs/maintain/](docs/maintain/)
+
+Ініціалізація контролера пам'яті
+--------------------------------
+
+Libreboot має *повністю вільну* ініціалізацію, доступну для всіх контролерів пам'яті Intel
+на платформах, які підтримуються. Це *включає* Haswell (ThinkPad T440p
+та W541), станом на Libreboot 20230319 та пізніші.
+
+Платформи AMD
+=============
+
+Libreboot наразі *бракує* підтримки для платформ AMD, але інформація про
+них буде написана, коли цей факт зміниться.
+
+Платформи ARM (chromebook)
+=============
+
+В більшості без блобі, за вийнятком вимоги на материнських платах `daisy` та `peach`
+включати блоби завантажувача BL1. Це:
+
+* HP Chromebook 11 G1 (daisy-spring)
+* Samsung Chromebook XE303 (daisy-snow)
+* Samsung Chromebook 2 13” (peach-pi)
+* Samsung Chromebook 2 11” (peach-pit)
+
+Libreboot *наразі* не розміщує ці блоби взагалі, і це
+вважається *помилкою*; це задокументовано на сторінці сумісності
+апаратного забезпечення. Їх можна додати вручну користувачем, але документації для цього
+наразі бракує на веб-сайті Libreboot.
+
+Список необхідних блобів, конкретно для кожної плати
+=================================================
+
+Ця стаття ретельно пояснила, в деталізованому огляді, точний
+характер того, *які* бінарні блоби розміщуються в Libreboot. Знову,
+повністю вільна ініціалізація з coreboot є доступною *на всіх наразі підтримуваних платах*.
+
+*З coreboot* є критичним аспектом цього, але повні межі Libreboot це
+основна завантажувальна інтегральна схема, яка (в деяких випадках) містить програмне забезпечення не з coreboot.
+
+Ось список, *для кожної* плати, цих блобів:
+
+Intel/x86
+---------
+
+Нейтралізований ME потрібен на цих цілях: `t420_8mb`, `t420s_8mb`, `t430_12mb`,
+`t440p_12mb`, `t440pmrc_12mb`, `t520_8mb`, `t530_12mb`, `w530_12mb`,
+`w541_12mb`, `w541mrc_12mb`, `x220_8mb`, `x230_12mb`, `x230_16mb`,
+`x230edp_12mb`, `x230t_12mb` та `x230t_16mb`.
+
+Як заявлено, Libreboot надає це в стані, де ME більше не є
+загрозою для безпеки. Він ініціалізує себе, але потім нічого не робить, тому його
+вимкнено. Це зроблено використовуючи `me_cleaner`. Дивіться:
+<https://github.com/corna/me_cleaner/wiki/How-does-it-work%3F>
+
+Оновлення *мікрокоду* для ЦП надано на *всіх* платформах x86, за замовчуванням. Не
+вимагається технічно, але надзвичайно рекомендовано. Виконайте для видалення:
+
+	cbfstool filename.rom remove -n cpu_microcode_blob.bin
+
+Видалення оновлень мікрокоду вплине на стабільність системи негативно,
+впроваджуючи нестандартну поламану поведінку і його результатом може бути
+неможливість машини правильно завантажуватись. В інших випадках, видалення його може поламати такі функції,
+як S3 suspend/resume.
+
+Intel Flash Descriptor надано в якості блобів на деяких платах, але це не є
+блобами *програмного забезпечення*. Це конфігурації, які надано в двійковому форматі,
+повністю придатному для читання вільним програмним забезпеченням. Наприклад:
+
+* Програма Libreboot `ich9gen` створює флеш-дескриптори ICH9M з нуля.
+* Програма Coreboot `ifdtool` має обширні функції для маніпуляції Intel
+  flash descriptor.
+* Програма Coreboot `bincfg` створює будь-який вид бінарних з файлу `.spec`,
+  який може описувати будь-який бінарний формат в форматі, який можна прочитати людині. Вона містить
+  декілька Intel flash descriptor для декількох платформ, але Libreboot не використовує
+  їх.
+
+Конфігурація Intel GbE NVM (конфігураційні дані, закодовані двійково, для гігабітної мережевої картки):
+
+* Програма Libreboot `ich9gen` *також* створює образи GbE NVM, конкретно
+  для мережевих карток Intel, які використані в Thinkpad GM45.
+* Програма Libreboot `nvmutil` може маніпулювати образами GbE NVM
+
+Блоби мікрокоду ЦП включено за замовчуванням, на всіх платах x86. В той час як не потрбіні
+в більшості випадків, їх використання надзвичайно рекомендовано. Дивіться для причин чому:
+[news/policy.uk.md#більш-детальна-інформація-про-мікрокод](news/policy.uk.md#більш-детальна-інформація-про-мікрокод)
+
+ARM/chromebook
+---------------
+
+BL1 завантажувач потрібен на: `daisy_snow`, `daisy_spring` та `peach_pit`.
+
+Висновки
+==========
+
+З вищезазначеного, ви можете бачити, що Libreboot в дійсності *надає* *політику зменшення
+бінарних блобів*, з наголошенням на *зменшенні*, що є найбільш критичним.
+
+Libreboot *міг би* додати багато блобів для різних платформ, для увімкнення різноманітних
+додаткових функцій, які натомість він уникати додавати, в точності тому, що *метою*
+проекта Libreboot є поширення *вільного* програмног забезпечення та *мінімізація* сили,
+яку розробники пропрієтарного програмного забезпечення мають над користувачами.
+
+Я сподіваюсь, що ця стаття надала їжу для роздумів.
+
+Відступ: свобода обладнання
+--------------------------
+
+Жодна з машин, які наразі підтримуються Libreboot не має вільного *апаратного забезпечення*, в тому
+сенсі, що інтегральні схеми не ідуть з публічного доступними файлами *verilog* та
+подібним. Ви не змогли би виготовити власну заміну цих машин.
+
+Деякі схеми та файли бордв'ю описують друковані плати окремих
+машин, які доступні онлайн, через різноманітні канали. Ви маєте знайти їх
+власноруч; одного дня, рух Право на ремонт, сподіваюся, принесе
+універсальний доступ до таких документів спільноті.
+
+Для подальшого читання
+===============
+
+В цій статті описано код, який міститься в *основній завантажувальній флеш-пам'яті*, але
+будь-який комп'ютер, який ви придбаєте, матиме *тони* мікропрограм в інших частинах системи. Деякі
+відомості доступні на сторінці частих запитань Libreboot. Дивіться:
+
+* [faq.uk.md#який-рівень-програмної-свободи-дає-мені-libreboot](faq.uk.md#який-рівень-програмної-свободи-дає-мені-libreboot)
+* [faq.uk.md#яке-ще-мікропрограмне-забезпечення-існує-за-межами-libreboot](faq.uk.md#яке-ще-мікропрограмне-забезпечення-існує-за-межами-libreboot)
+
+З них найбільш критичним є прошивка жорстких дисків/твердотілих накопичувачів та прошивка EC. Проблема описана
+в цих двох посиланнях застосовується до багатьох різних комп'ютерів, включаючи
+Libreboot, та практично кожний інший комп'ютер в світі.

site/index.fr.md

@@ -12,7 +12,7 @@ Des canaux d'aide sont disponibles
 dans le canal [\#libreboot](https://web.libera.chat/#libreboot) sur le serveur IRC [Libera](https://libera.chat/).
 
 **NOUVELLE VERSION: La dernière version est [Libreboot 20230319](news/libreboot20230319.md), sortie
-le 14 Mars 2022.**
+le 19 Mars 2023.**
 
 Pourquoi devriez-vous utiliser Libreboot?
 -----------------------------------

site/news/libreboot20230319.md

@@ -2,6 +2,9 @@
 % Leah Rowe
 % 19 March 2023
 
+Introduction
+============
+
 Libreboot provides boot firmware for supported x86/ARM machines, starting a
 bootloader that then loads your operating system. It replaces proprietary
 BIOS/UEFI firmware on x86 machines, and provides an *improved* configuration
@@ -78,6 +81,19 @@ The changes can be summarised, thus:
 * util/nvmutil: Massively re-factored the codebase, making it more efficient
   and *correct*.
 
+NOTE: T440p/W541 images with `mrc.bin` must be compiled from source. They were
+removed from the release, due to a bug reported in scripts used for preparing
+them post-build, when users install them. The bug was fixed in a revision
+after the release. If you still have those ROM images from prior to deletion,
+and want to use them, you should apply the following patch to your archive
+of the release, or just use latest `lbmk` from the Git repository; see:
+
+<https://browse.libreboot.org/lbmk.git/commit/?id=da6bf57a3f57f2625a4903cafb5cfd10ea4a1dae>
+
+Pre-compiled ROM images will for the `t440pmrc_12mb` and `w541mrc_12mb` targets
+will be available in the next release; the `t440p_12mb` and `w541_12mb` images
+are still available in this release, pre-compiled.
+
 REMARK: libre raminit on Haswell
 --------------------------------