summaryrefslogtreecommitdiffstats
path: root/src/fundamental (follow)
Commit message (Collapse)AuthorAgeFilesLines
* fundamental: Fix buffer size in get_chidanonymix0072024-11-071-2/+2
| | | | NUL byte should not be hashed
* fundamental: Fix iteration count in chid_calculateanonymix0072024-11-071-1/+2
|
* fundamental: move string includes from chid-fundamental.c to headeranonymix0072024-11-072-2/+6
|
* fundamental: Add userspace efi_guid_equalanonymix0072024-11-071-0/+7
|
* tree-wide: use Device*T*ree spellingZbigniew Jędrzejewski-Szmek2024-11-061-1/+1
| | | | | | | | We used both, in fact "Devicetree" was more common. But we have a general rule that we capitalize all words in names and also we have a DeviceTree= configuration setting, which we cannot change. If we use two different spelllings, this will make it harder for people to use the correct one in config files. So use the "DeviceTree" spelling everywhere.
* uki: add new .dtbauto PE section typeanonymix0072024-11-052-0/+2
| | | | | | | | .dtbauto section contains DT blobs, just like .dtb, the difference is that multiple .dtbauto sections are allowed to be in a UKI and only one is selected automatically Temporarily drop an assert_cc() check in systemd-measure to make it compilable before the next commit
* measure: introduce support for a .hwids sectionanonymix0072024-11-052-0/+2
|
* fundamental: Add HWID calculationanonymix0072024-11-053-0/+142
|
* bootctl: Add --secure-boot-auto-enrollDaan De Meyer2024-11-031-0/+61
| | | | | | When specified, bootctl install will also set up secure boot auto-enrollment. For now, We sign all variables using the same certificate and key pair.
* boot: stop appending NUL to .sdmagic and .sbat sectionsZbigniew Jędrzejewski-Szmek2024-10-311-1/+0
| | | | | | | | | | | | | | | | | Those text sections had a trailing NUL byte. It's debatable whether this is a good idea or not. Correctly written consumers will look at the section size so they wouldn't need this. Shim doesn't use a trailing NUL, so let's follow suit. Fixes https://github.com/systemd/systemd/issues/33731. 898e9edc469f87fdb6018128bac29eef0a5fe698 reworked this code, but didn't actually change the logic. We have always been appending the trailing zero by using a NUL-terminated string as the section contents. (I checked this with v253.18 from before the elf2efi rework.) .sdmagic contains a string like "#### LoaderInfo: systemd-boot 257~devel ####", which changes with each version, so previous versions would compare unequal anyway, so we don't need to worry about backwards compatibility.
* sha256: use memory-util-fundamental.hYu Watanabe2024-10-121-7/+1
| | | | Prompted by https://github.com/systemd/systemd/pull/34722#discussion_r1797352922.
* fundamental: Import SHA1 implementation from libxcryptanonymix0072024-10-113-0/+320
|
* macro: Add DISABLE_WARNING_STRINGOP_OVERREADanonymix0072024-10-111-0/+4
| | | | While at it, also add -Wunknown-warning-option to basic_disabled_warnings to fix compilation with clang
* fundamental: Add EFI_GUID userspace definitionanonymix0072024-10-111-0/+13
|
* macro: add voffsetof() helper, that operates like offsetof() but on variablesLennart Poettering2024-10-111-0/+1
|
* stub: Add support for .initrd addon filesTobias Fleig2024-10-091-0/+3
| | | | | | | Teaches systemd-stub how to load additional initrds from addon files. This is very similar to the support for .ucode sections in addon files, but with different ordering. Initrds from addons have a chance to overwrite files from the base initrd in the UKI.
* pe-binary: add pe_is_native() for checking if PE is nativeLennart Poettering2024-09-121-0/+22
|
* stub: add StubDevicePartUUID/StubImageIdentifierLennart Poettering2024-09-111-0/+1
| | | | | | | | | | | | These variables closely mirror the existing LoaderDevicePartUUID/LoaderImageIdentifier variables. But the Stub… variables indicate the location of the stub/UKI (i.e. of systemd-stub), while the Loader… variables indicate the location of the boot loader (i.e. of systemd-boot). (Except of course, there is no boot loader used, in which case both sets point to the stub/UKI, as a special case). This actually matters, as we support that sd-boot runs off the ESP, while a UKI then runs off XBOOTLDR, i.e. two distinct partitions.
* boot: synthesize a separate menu entry from each .profile sectionLennart Poettering2024-09-102-0/+4
| | | | | | This iterates through the .profile sections a UKI provides and uses it to generate multiple menu entries from them, one for each .profile section.
* stub: add ability to place multiple alternative PE sections of a specific ↵Lennart Poettering2024-09-102-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | type in the same UKI ("Multi-Profile UKIs") This adds a ability to add alternative sections of a specific type in the same UKI. The primary usecase is for supporting multiple different kernel cmdlines that are baked into a UKI. The mechanism is relatively simple (I think), in order to make it robust. 1. A new PE section ".profile" is introduced, that is a lot like ".osrel", but contains information about a specific "profile" to boot. The ".profile" section can appear multiple times in the same PE, and acts as delimiter indicating where a new profile starts. Everything before the first ".profile" is called the "base profile", and is shared among all other profiles, which can then override or add addition PE sections on top. 2. An UKI's command line can be prefixed with an argument such as "@0" or "@1" or "@2" which indicates the "profile" to boot. If no argument is specified the default is profile 0. Also, a UKI that lacks any .profile section is treated like one with only a profile 0, but with no data in that profile section. 3. The stub will first search for its usual set of PE sections (hereafter called "base sections"), and stop at the first .profile PE section if any. It will then find the .profile matching the selected profile by its index, and any sections found as part of that profile on top of the base sections. And that's already it. Example: let's say a distro wants to provide a single UKI that can be invoked in one of three ways: 1. The regular profile that just boots the system 2. A profile that boots into storagetm 3. A profile that initiates factory reset and reboots. For this it would define a classic UKI with sections .linux, .initrd, .cmdline, and whatever else it needs. The .cmdline section would contain the kernel command line for the regular profile. It would then insert one ".profile" section, with a contents like the following: ID=regular This is the profile for profile 0. It would immediately afterwards add another ".profile" section: ID=storagetm TITLE=Boot into Storage Target Mode This would then followed with a .cmdline section that is just like the basic one, but with "rd.systemd.unit=storage-target-mode.target" suffixed. Then, another .profile section would be added: ID=factory-reset TITLE=Factory Reset Which is then followed by one last PE section: a .cmdline one with "systemd.unit=factory-reset.target" suffixed to te regular command line. i.e. expressed in tabular form the above would be: The base profile: .linux .initrd .cmdline .osrel The regular boot profile: .profile The storagetm profile: .profile .cmdline The factory reset profile: .profile .cmdline You might wonder why the first .cmdline in the list above is placed in the base profile rather than in the regular boot profile, given that it is overriden in all other profiles anyway. And you are right. The only reason I'd place it in the base profile is that it makes the UKI more nicely extensible if later profiles are added that want to replace something else instead of the .cmdline, for example .ucode or so. But it really doesn't matter much. While the primary usecase is of course multiple alternative command lines, the concept is more powerful than that: for various usecases it might be valuable to offer multiple choices of devicetree, ucode or initrds. The .profile contents is also passed to the invoked kernel as a file in /.extra/profile (via a synthetic initrd). Thus, this functionality can even be useful without overriding any section at all, simply by means of reading that file from userspace. Design choices: 1. On purposes I used a special command line marker (i.e. the "@" thing, which maybe we should call the "profile selector"), that doesn't look like a regular kernel command line option. This is because this is really not a regular kernel command line option – we process it in the stub, then remove it as prefix, and measure the unprefixed command line only after that. The kernel will not see the profile selector either. I think these special semantics are best communicated by making it look substantially different from regular options. 2. This moves around measurements a bit. Previously we measured our UKI sections right after finding them. Now we first parse the profile number from the command line, then search for the profile's sections, and only then measure the sections we actually end up using for this profile. I think that this logic makes most sense: measure what we are using, not what we are overriding. Or in other words, if you boot profile @3, then we'll measure .cmdline (assuming it exists) of profile 3, and *not* measure .cmdline of the base profile. Also note that if the user passes in a custom kernel command line via command line arguments we'll strip off the profile selector (i.e. the initial "@X" thing) before we pass it on. 3. The .profile stuff is supposed to be generic and extensible. For example we could use it in future to mark "dangerous" options such as factory reset, so that boot menus can ask for confirmation before booting into it. Or we could introduce match expressions against SMBIOS or other system identifiers, to filter out profiles on specific hw. Note btw, that PE allows defining multiple sections that point to the same offsets in the file. This allows sharing payload under different names. For example, if profile @4 and @7 shall carry the same .ucode section, they can define .ucode in each profile and then make it point to the same offset. Also note that that one can even "mask" a base section in a profile, by inserting an empty section. For example, if the base .dtb section should not be used for profile @4, then add a section .dtb right after the fourth .profile with a zero size to the UKI, and you will get your wish fulfilled. This code only contains changes to sd-stub. A follow-up commit will teach sd-boot to also find this profile PE sections to synthesize additional menu entries from a single UKI. A later commit will add support for gnerating this via ukify. Fixes: #24539
* uki: add new ".profile" PE section typeLennart Poettering2024-09-062-0/+2
| | | | | | | | This is the most basic preparatory work for supporting multi-profile UKIs. (This temporarily drops an assert_cc() check which we'll address in the next commit)
* Fix detection of TDX confidential VM on Azure platformDaniel P. Berrangé2024-07-301-0/+1
| | | | | | | | | | | The original CVM detection logic for TDX assumes that the guest can see the standard TDX CPUID leaf. This was true in Azure when this code was originally written, however, current Azure now blocks that leaf in the paravisor. Instead it is required to use the same Azure specific CPUID leaf that is used for SEV-SNP detection, which reports the VM isolation type. Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
* stub: Add support for .ucode EFI addonsTobias Fleig2024-07-081-0/+3
| | | | This extends #31872 to also load microcode from addon files.
* iovec-util: make "struct iovec" and some helpers also available in EFI modeLennart Poettering2024-06-262-0/+38
| | | | | | The construct is a POSIX invention, but it's just so useful, let's also define it in EFI mode, so that we can use similar constructs in EFI mode and userspace.
* macro: move PTR_TO_SIZE() macros to fundamentalLennart Poettering2024-06-261-0/+3
|
* macro: also move FOREACH_ARRAY()/FOREACH_ELEMENT() to fundamentalLennart Poettering2024-06-261-0/+12
| | | | This is also very useful in EFI code.
* macro: move sizeof_field() macro into src/fundamental/Lennart Poettering2024-06-261-0/+3
| | | | Let's make this macro available for our EFI code too.
* macro-fundamental: correct comment and remove trailing ';' for macroMike Yuan2024-06-151-2/+2
| | | | Follow-up for 3c2f2146f50c75662987541719bedc4aee9df939
* fundamental: declare flex array updated for gcc15 and clang 19Cristian Rodríguez2024-06-141-0/+5
| | | | | | | | | Silly workaround that: - allowed flexible arrays in unions - allowed flexible arrays in otherwise empty structs Is no longer needed since https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=adb1c8a0f167c3a1f7593d75f5a10eb07a5d741a (GCC15) or clang 19 https://github.com/llvm/llvm-project/commit/14ba782a87e16e9e15460a51f50e67e2744c26d9
* stub: Add support for .ucode UKI sectionTobias Fleig2024-04-192-0/+2
| | | | | | This commit adds support for loading, measuring and handling a ".ucode" UKI section. This section is functionally an initrd, intended for microcode updates. As such it will always be passed to the kernel first.
* basic: Add some sha256 helper functionsAdrian Vovk2024-02-133-2/+2
| | | | | | Adds a util function to sha256 an open fd (moved from dissect). Also adds functions to check if a string contains a valid sha256 hash, and parse it into a sha256 array.
* fundamental: Add overflow-safe math helpersAdrian Vovk2024-02-131-1/+25
| | | | | | | | | | ADD_SAFE/SUB_SAFE/MUL_SAFE do addition/subtraction/multiplication respectively with an overflow check. If an overflow occurs these return false, otherwise true. Example: (c = a + b) would become ADD_SAFE(&c, a, b) INC_SAFE/DEC_SAFE/MUL_ASSIGN_SAFE are like above but they also reassign the first argument. Example: (a += b) would become INC_SAFE(&a, b)
* string-util-fundamental: postfix -> suffix, use streqMike Yuan2024-01-042-10/+10
|
* stub: pick up confexts from the ESP as wellLennart Poettering2024-01-031-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | This does what we do for system extension also for configuration extension. This is complicated by the fact that we previously looked for <uki-binary>.d/*.raw for system extensions. We want to measure sysexts and confexts to different PCRs (13 vs. 12) hence we must distinguish them, but *.raw would match both kinds. This commit solves this via the following mechanism: we'll load confexts from *.confext.raw and sysexts from *.raw but will then enclude *.confext.raw from the latter. This preserves compatibility but allows us to somewhat reasonable distinguish both types of images. The documentation is updated not going into this detail though, and instead now claims that sysexts shall be *.sysext.raw and confexts *.confext.raw even though we actually are more lenient than this. This is simply to push people towards using the longer, more descriptive suffixes. I added an XML comment (<!-- … -->) about this to the docs, so that whenever somebody notices the difference between code and docs understands why and leaves it that way.
* fundamental: prefer byte swap builtins over byte swapping manuallyRose2024-01-031-9/+2
| | | | This builtin reduces complexity and GCC/Clang have supported these builtins for a long time.
* macro-fundamental: add U64_{K,M,G}BMike Yuan2023-12-131-0/+4
|
* string-util: add on_offSam Leonard2023-11-021-0/+4
|
* Merge pull request #29601 from yuwata/mmap-check-overflowLuca Boccassi2023-10-241-1/+34
|\ | | | | mmap: check offset and size more carefully
| * macro: introduce several helper functions for alignmentYu Watanabe2023-10-191-0/+33
| | | | | | | | Some of them are not used in this commit, but will be used later.
| * macro: paranoia about overflowYu Watanabe2023-10-191-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | E.g. Consider the case ALIGN_TO(SIZE_MAX - 3, 4). The overflow check passes as the condition ``` SIZE_MAX - 3 > SIZE_MAX - (4 - 1) ``` is false. However, the value ``` l + ali - 1 ``` may overflow as it is equivalent to ``` SIZE_MAX - 3 + 4 - 1 ```
* | tpm2: move event tag sd-boot/sd-stub to make measurements with into ↵Lennart Poettering2023-10-201-0/+6
|/ | | | | | | | | | src/fundamental/ Ultimately we want to be able to recognize these in userspace, hence make them available in both UEFI mode and userspace. While we are at it, let's rename the fields a bit, reflecting more what they measure, not what the metadata is that we store about them.
* sd-boot: add way to disable the 100ms delay when timeout=0Emil Velikov2023-10-171-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* Merge pull request #29502 from keszybz/sd-boot-config-tweaksLuca Boccassi2023-10-131-0/+72
|\ | | | | Tweaks to sd-boot UX
| * basic/macro.h: move a bunch of stuff to macro-fundamental.hZbigniew Jędrzejewski-Szmek2023-10-071-0/+72
| | | | | | | | We should start using this functionality in src/boot/efi/ too.
* | stub: add support for dtb addonsLuca Boccassi2023-10-091-0/+1
| | | | | | | | Same as kernel command line addons.
* | Move CLEANUP_ARRAY to src/fundamentalLuca Boccassi2023-10-091-0/+36
|/
* macro: use __builtin_unreachable on NDEBUGNRK2023-10-031-1/+1
| | | | | | | | | | | | note that this slightly changes the semantic of assert when NDEBUG is defined. if there's an extern function call (without attribute pure or similar) then the compiler has to assume it has side effects and still emit the function call. whereas the old assert guaranteed that nothing will be evaluated on NDEBUG. Closes: https://github.com/systemd/systemd/issues/29408
* memory-util: move memzero() to src/fundamental/ to share with UEFILennart Poettering2023-10-021-0/+6
| | | | | (and while we are at it, make sure it returns the input pointer as output)
* elf2efi: Add --copy-sections optionJan Janssen2023-09-291-2/+8
| | | | | | | | | | This makes the special PE sections available again in our output EFI images. Since the compiler provides no way to mark a section as not allocated, we use GNU assembler syntax to emit the sections instead. This ensures the section data isn't emitted twice as load segments will only contain allocating input sections.
* boot: use separate SBAT project names for stub and bootLuca Boccassi2023-09-192-4/+16
| | | | | | The implementations are not 100% overlapping, so use different identifiers, so that revocations can be done independently. e.g.: a bug that affects only sd-boot won't necessarily cause old UKIs to be revoked.
generated by cgit v1.2.3 (git 2.39.1) at 2024-12-02 03:41:54 +0100