We try to read again from the beginning, hence let's seek back.
Apparently efivarfs doesn't strictly require this, but it's really weird
that it doesn't.
writev() returns the full size, not just the payload size, hence always
add sizeof(attr) where necessary.
Let's also change a couple of "4" into sizeof(attr) all over the place,
to make clear what they are about.
Fixes: #39695
Follow-up for: 9db9d6806e
We shouldn't ask glibc to keep the old data around (which realloc() is
about), given we overwrite it entirely anyway. Let's hence speed things
up here, and allow glibc to just allocate a new block for us (and
shorten the code a bit)
Follow-up for 3ac4d68498
We have no sensible way to detect why strptime() fails, hence
the fallback path as it is now would fire on glibc systems too,
pointlessly. Let's guard it behind ifdeffery.
glibc defines HOST_NAME_MAX as 64 and our code rely on that, but musl
defines the constant as 255. Let's provide our own definition for the
maximum length.
glibc defines AT_FDCWD as -100, but musl defines it as (-100).
In basic-forward.h, we also define AT_FDCWD as -100, hence musl's fcntl.h
conflicts with forward.h. This is for avoiding the conflict.
musl does not set tm_wday when it is explicitly requested.
The check is not necessary at all, it is just for safety.
Let's skip it when built with musl.
musl v1.2.5 does not support %z specifier in strptime(). Since
https://github.com/kraj/musl/commit/fced99e93daeefb0192fd16304f978d4401d1d77
%z is supported, but it only supports strict RFC-822/ISO 8601 format,
that is, 4 digits with sign (e.g. +0900 or -1400), but does not support
extended format: 2 digits or colon separated 4 digits (e.g. +09 or -14:00).
Let's add fallback logic to make it support the extended timezone spec.
sys/prctl.h anyway includes linux/prctl.h and actually these .c files
includes sys/prctl.h. Hence, it is not necessary to explicitly include
linux/prctl.h.
musl's newlocale() always provides a locale object even the requested
locale does not exist. Let's explicitly check the existence of the
requested locale file.
shim is often used as part of the EFI boot chain with Linux kernels.
shim has an option to disable all verification of binaries it loads.
This can be performed by end-user using mokutil / mokmanager EFI app,
which set BootServices only variable MokSBState. shim honors that, and
mirrors it as readonly MokSBStateRT for the post-ExitBootService access.
Thus presense of MokSBStateRT is an indicator that shim was used during
boot chain.
Some OEM vendors are known to set MokSBState variable, without user
having done so.
When verification is disabled, one should assume secureboot is insecure,
because any EFI binary was allowed to run, including but not limited to
unsigned or revoked:
- grub
- systemd-boot
- UKI
- linux kernel
Linux kernel also has code to check this variable, and correctly report
that Secure Boot is disabled, see:
-
https://github.com/torvalds/linux/blob/3a8660878839faadb4f1a6dd72c3179c1df56787/drivers/firmware/efi/libstub/secureboot.c#L57
With this change bootctl output changes like this:
```diff
System:
Firmware: n/a (n/a)
Firmware Arch: x64
- Secure Boot: enabled (user)
+ Secure Boot: disabled (insecure)
TPM2 Support: yes
Measured UKI: no
Boot into FW: supported
```
This implementation is trying to mimic mokutil behaviour like this one:
```
$ mokutil --sb-state
SecureBoot enabled
SecureBoot validation is disabled in shim
```
As well as the linux kernel behavior of:
```
$ journalctl -b | grep 'Secure boot disabled'
kernel: Secure boot disabled
```
Note that MokSBState is extended into PCR7 as well as also into PCR14.
For more details see https://github.com/rhboot/shim/blob/main/README.tpm
When VirtIO VSOCK device is not present, IOCTL_VM_SOCKETS_GET_LOCAL_CID
returns VMADDR_CID_LOCAL/1, and we issue a hint to connect to vsock%1.
This does not work. Filter out VMADDR_CID_LOCAL and VMADDR_CID_HOST,
those are not real addresses that can be used from the outside.
When Type=notify-reload got introduced, it wasn't intended to be
mutually exclusive with ExecReload=. However, currently ExecReload=
is immediately forked off after the service main process is signaled,
leaving states in between essentially undefined. Given so broken
it is I doubt any sane user is using this setup, hence I took a stab
to rework everything:
1. Extensions are refreshed (unchanged)
2. ExecReload= is forked off without signaling the process
3a. If RELOADING=1 is sent during the ExecReload= invocation,
we'd refrain from signaling the process again, instead
just transition to SERVICE_RELOAD_NOTIFY directly and
wait for READY=1
3b. If not, signal the process after ExecReload= finishes
(from now on the same as Type=notify-reload w/o ExecReload=)
4. To accomodate the use case of performing post-reload tasks,
ExecReloadPost= is introduced which executes after READY=1
The new model greatly simplifies things, as no control processes
will be around in SERVICE_RELOAD_SIGNAL and SERVICE_RELOAD_NOTIFY
states.
See also: https://github.com/systemd/systemd/issues/37515#issuecomment-2891229652
In btrfs-progs 6.15 it is planned to add a new parameter in mkfs.btrfs
--inode-flags, that can set attributes for subvolumes, directories, and
files.
The current supported attributes are "nodatacow", to disable CoW, and
"nodatasum", to disable the checksum.
This commit extend the "Subvolunes=" option to understand the
"nodatacow" flag for subvolums only.
If RepartOffline is enabled it will build the image without loopback
devices, using the correct --inode-flags parameters.
If RepartOffline is disabled it will use loopback devices and set the
btrfs attributes accordingly.
Signed-off-by: Alberto Planas <aplanas@suse.com>
Let's extract common capability parsing code into a generic function
parse_capability_set() with a comprehensive set of unit tests.
We also replace usages of UINT64_MAX with CAP_MASK_UNSET where
applicable and replace the default value of CapabilityBoundingSet
with CAP_MASK_ALL which more clearly identifies that it is initialized
to all capabilities.
AI (copilot) was used to extract the generic function and write the
unit tests, with manual review and fixing afterwards to make sure
everything was correct.
Previously, we limit the length of process name by 8.
This relax the restriction then at least process comm or
program_invocation_name contains the untrucated process name.
Closes#38367.
Check whether the argument of the `--background` option of
`systemd-run`, `run0`, `systemd-nspawn`, `systemd-vmspawn`, and
`systemd-pty-forward` is either empty or looks like an ANSI color code,
and reject invalid values when parsing arguments.
We consider a string to look like an ANSI color code if it consists of
one or more sequences of ASCII digits separated by semicolons. This
permits every valid ANSI color code, and should reject anything that
results in garbled output.
Daan De Meyer
Mike Yuan
Yu Watanabe
Lennart Poettering
Zbigniew Jędrzejewski-Szmek
Dimitri John Ledkov
Alberto Planas
Daniel Hast