IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
This reverts commit 5e8ff010a1.
This broke all the URLs, we can't have that. (And actually, we probably don't
_want_ to make the change either. It's nicer to have all the pages in one
directory, so one doesn't have to figure out to which collection the page
belongs.)
Currently we have a 100ms delay which allows for people to enter/show
the boot menu even when timeout is set to zero.
In a handful of cases, that may not be needed - both in terms of access
policy, as well as latency.
For example: the option to provide the boot menu may be hidden behind an
"expert only" UX in the OS, to avoid end users from accidentally
entering it.
In addition, the current 100ms input polling may cause unexpected
additional delays in the boot. Some example numbers from my SteamDeck:
- boot counting/rename/flush doubles 300us -> 600us
- seed/hash setup doubles 900us -> 1800us
- kernel/image load gets ~40% slower 107ms -> 167ms
It's not entirely clear why the UEFI calls gets slower, nevertheless the
information in itself proves useful.
This commit introduces a new option "menu-disabled", which omits the
100ms delay. The option is documented throughout the manual pages as
well as the Boot Loader Specification.
v2:
- use STR_IN_SET
v3:
- drop erroneous whitespace
v4:
- add a new LoaderFeature bit,
- don't change ABI keep TIMEOUT_* tokens the same
- move new token in the 64bit range, update API and storage for it
- change inc/dec behaviour to TIMEOUT_MIN : TIMEOUT_MENU_FORCE
- user cannot opt-in from sd-boot itself, add assert_not_reached()
v5:
- s/Menu disablement control/Menu can be disabled/
- rewrap comments to 109
- use SYNTHETIC_ERRNO(EOPNOTSUPP)
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
To be on the safe side, explicitly mention that apart from the numerical
entries we can allow string ones.
Implementation-wise, bootctl will use internal numerical values that
match sd-boot's ABI. The latter also accepts the string options.
Going forward we'd like to avoid adding more internal magic and be more
explicit.
Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
Rather than passing seeds up to userspace via EFI variables, pass seeds
directly to the kernel's EFI stub loader, via LINUX_EFI_RANDOM_SEED_TABLE_GUID.
EFI variables can potentially leak and suffer from forward secrecy
issues, and processing these with userspace means that they are
initialized much too late in boot to be useful. In contrast,
LINUX_EFI_RANDOM_SEED_TABLE_GUID uses EFI configuration tables, and so
is hidden from userspace entirely, and is parsed extremely early on by
the kernel, so that every single call to get_random_bytes() by the
kernel is seeded.
In order to do this properly, we use a bit more robust hashing scheme,
and make sure that each input is properly memzeroed out after use. The
scheme is:
key = HASH(LABEL || sizeof(input1) || input1 || ... || sizeof(inputN) || inputN)
new_disk_seed = HASH(key || 0)
seed_for_linux = HASH(key || 1)
The various inputs are:
- LINUX_EFI_RANDOM_SEED_TABLE_GUID from prior bootloaders
- 256 bits of seed from EFI's RNG
- The (immutable) system token, from its EFI variable
- The prior on-disk seed
- The UEFI monotonic counter
- A timestamp
This also adjusts the secure boot semantics, so that the operation is
only aborted if it's not possible to get random bytes from EFI's RNG or
a prior boot stage. With the proper hashing scheme, this should make
boot seeds safe even on secure boot.
There is currently a bug in Linux's EFI stub in which if the EFI stub
manages to generate random bytes on its own using EFI's RNG, it will
ignore what the bootloader passes. That's annoying, but it means that
either way, via systemd-boot or via EFI stub's mechanism, the RNG *does*
get initialized in a good safe way. And this bug is now fixed in the
efi.git tree, and will hopefully be backported to older kernels.
As the kernel recommends, the resultant seeds are 256 bits and are
allocated using pool memory of type EfiACPIReclaimMemory, so that it
gets freed at the right moment in boot.
I have no idea if this is going to cause rendering problems, and it is fairly
hard to check. So let's just merge this, and if it github markdown processor
doesn't like it, revert.
The boot loader specification link points to the boot loader interface
documentation.
This fixes the link to point to BOOT_LOADER_SPECIFICATION instead of
BOOTLOADER_INTERFACE which is itself.
I think it makes sense to keep the "The" in place for the actual page's
title, but let's drop it from the categorization header, to make it
easier to find stuff, as the "The" isn't helpful to that.
In particular as we sometimes do it this and sometimes the other way so
far, hence let's stick to one common rule.
It turns out Jekyll (the engine behind GitHub Pages) requires that pages
include a "Front Matter" snippet of YAML at the top for proper rendering.
Omitting it will still render the pages, but including it opens up new
possibilities, such as using a {% for %} loop to generate index.md instead of
requiring a separate script.
I'm hoping this will also fix the issue with some of the pages (notably
CODE_OF_CONDUCT.html) not being available under systemd.io
Tested locally by rendering the website with Jekyll. Before this change, the
*.md files were kept unchanged (so not sure how that even works?!), after this
commit, proper *.html files were generated from it.
From WordNet (r) 3.0 (2006) [wn]:
time-out
n 1: a brief suspension of play; "each team has two time-outs left"
From The Free On-line Dictionary of Computing (18 March 2015) [foldoc]:
timeout
A period of time after which an error condition is raised if
some event has not occured. A common example is sending a
message. If the receiver does not acknowledge the message
within some preset timeout period, a transmission error is
assumed to have occured.
The existing text already said "See below regarding a recommended
vocabulary for boot loader entry identifiers.", but the section for it
was still missing. Let's fill in the missing bits, and describe basic
suggested rules for the boot menu entry identifier vocabulary, in
particular how to identify Windows and MacOS X installations, and how to
name automatic entries vs. explicitly configured ones.
This basically follows the logic implemented in sd-boot these days.
