This reverts commit 35fc10756b.
Although DocBook 4.5 states that `cmdsynopsis` can be used within `term` [1],
and `term` within `varlistentry`, `man` does not display the list of commands
after this change. FWIW, `cmdsynopsis` is used tree-wide within `refsynopsisdiv`
only.
[1] https://tdg.docbook.org/tdg/4.5/term
This is a supplement to #24419. On macOS Intel machines, detection needs to be done through cpuid.
In macOS, `dmi_vendors` detection is only applicable to M series.
Signed-off-by: Black-Hole1 <bh@bugs.cc>
This also introduce an extra argument for route_dup(), but it is
currently unused, will be used later.
No functional change, just preparation for later commits.
The OVMF UEFI firmware is measuring PK and KEK when secure boot is
disabled, and those variables are absent. This can be checked via the
event log to see that there are extensions for PCR 7 associated with PK
and KEK events of type EV_EFI_VARIABLE_DRIVER_CONFIG.
When running the "lock-secureboot-policy" verb, pcrlock complains that
those variables are not found and refuse to generate the
240-secureboot-policy.pcrlock.d/generated.pcrlock file.
The "TCG PC Client Platform Firmware Profile Specification Version 1.05
Revision 23"[1] from May 7, 2021, in section "3.3.4.8 PCR[7] - Secure
Boot Policy Measurements", point 10.b:
If reading a UEFI variable returns UEFI_NOT_FOUND, platform firmware
SHALL measure the absence of the variable. The
UEFI_VARIABLE_DATA.VariableDataLength field MUST be set to zero and
UEFI_VARIABLE_DATA.VariableData field will have a size of zero.
This patch mark those variables to be marked as "synthesize empty",
generating the correct hash for those variables.
Signed-off-by: Alberto Planas <aplanas@suse.com>
So far, if some component mounts a DDI in some local mount namespace we
created a temporary mountpoint in /tmp/ for that. Let's instead use the
same directory inode in /run/ instead. This is safe, since if everything
runs in a local mount namespace (with propagation on /run/ off) then
they shouldn't fight for the inode. And it relieves us from having to
clean up the directory after use. Morever, it allows us to run without
/tmp/ mounted.
This only moves dissect-image.c and the dissec tool over. More stuff is
moved over later.
Our dumbed down example PAM stacks do not contain cracklib/pwq modules,
hence using use_authtok on the pam_unix.so password change stack won't
work, because it has the effect that pam_unix.so never asks for a
password on its own, expecting the cracklib/pwq modules to have
queried/validated them beforehand.
I noticed this issue because of #30969: Debian's PAM setup suffers by
the same issue – even though they don't actually use our suggested PAM
fragments at all.
See: #30969
Let's make things nice for desktops, and provide a mime type for
credential files.
This uses the 128bit header identifier that our credential files start
with. However, the files are always base64 encoded, hence we have to
match the base64 string, hence add a small test case that generates them
properly for us, and truncates them at the right place (since 128 is not
evently divisable by 6).
The branch explicitly checks that all of these ret_ variables are NULL,
so they will never be used.
Follow-up for 83e9b584db
CID#1533239
CID#1533240
CID#1533241
/sys/power/resume is always populated by the initrd, while
/sys/power/resume_offset might have been populated by
the kernel itself. Therefore, if the user is using an initrd
that doesn't include resume hook, the hibernation would fail,
which is expected. However, it was hard to track down the real
problem, since the previous log message suggested that resume=
is not set through kernel cmdline.
As it turns out we do this in a similar way at various times (and
sometimes incorrectly), hence add a common implementation to share the
code and fix the incorrect behaviour.
The parameter returns the flags field of the reply message. This is only
relevant in very few cases, hence drop it from the call, but keep it in
a more generic varlink_call_full() call for those who need it.
Do something similar for varlink_callb().
It's OK if callers don't want to know the varlink error string. But in
that case return the fact the call failed via the return value, as a
negative errno as usual, to make sure it's not accidentally ignored.
Similar for varlink_observe()
In varlink errors can have parameters (and they regularly do, for
example the io.systemd.System error we generate carries the errno in its
parameter), hence it's essential that varlink_oberserve collects that
properly and returns it too.
This gets enabled by default in gcc-14 and complains everywhere where we
use assert() on an expression that is always true (i.e. using
`int x[static 2]` in function declaration, etc.):
[153/2414] Compiling C object src/basic/libbasic.a.p/fs-util.c.o
In file included from ../src/basic/macro.h:13,
from ../src/basic/alloc-util.h:10,
from ../src/basic/fs-util.c:11:
../src/basic/fd-util.h: In function ‘format_proc_fd_path’:
../src/fundamental/macro-fundamental.h:74:41: warning: ‘nonnull’ argument ‘buf’ compared to NULL [-Wnonnull-compare]
74 | #define _unlikely_(x) (__builtin_expect(!!(x), 0))
| ^~~~~
../src/basic/macro.h:150:21: note: in expansion of macro ‘_unlikely_’
150 | if (_unlikely_(!(expr))) \
| ^~~~~~~~~~
../src/basic/macro.h:167:22: note: in expansion of macro ‘assert_message_se’
167 | #define assert(expr) assert_message_se(expr, #expr)
| ^~~~~~~~~~~~~~~~~
../src/basic/fd-util.h:129:9: note: in expansion of macro ‘assert’
129 | assert(buf);
| ^~~~~~
Disabling this selectively only for asserts is a bit painful, since the
option is not available in all compilers, and it'd need to be handled in
the EFI stuff as well.
Yu Watanabe
Antonio Alvarez Feijoo
Black-Hole1
Alberto Planas
Nick Cao
Luca Boccassi
Nandakumar Raghavan
Lennart Poettering
Andres Beltran
Mike Yuan
Frantisek Sumsal