Suppress warnings like the following from clang tidy:
```
../src/boot/addon.c:11:19: error: function 'efi_main' can be made static to enforce internal linkage [misc-use-internal-linkage,-warnings-as-errors]
11 | EFIAPI EFI_STATUS efi_main(EFI_HANDLE image, EFI_SYSTEM_TABLE *system_table);
| ^
```
Some warnings are suppressed simply by setting comments to ignore the warning,
some are by making global variables static, or include a suitable header.
Add missing NoSessionPIDFD error to the interface definition; the error
is emitted by vl_method_create_session() when the session leader process
does not have a pidfd available, but was never declared in the IDL.
Drop SD_JSON_MANDATORY from the ReleaseSession.Id dispatch entry so that
omitting the field (which the IDL allows via SD_VARLINK_NULLABLE)
resolves to the caller's own session via session_is_self(NULL).
It was noticed that cryptsetup luksDump outputs
tpm2-primary-alg: ecc
regardless of the actual primary key type. Namely, in the situation when
RSA SRK is passed to 'systemd-cryptenroll', the output is incorrect and
misleading. Turns out 'tpm2-primary-alg' is not currently used for
unsealing as 'tpm2_srk' object has it in its properties but the
misleading information problem stays.
Fix the issue with a two-fold fix:
- Put the SRK primary alg type to the JSON token so 'cryptsetup
luksDump' has a chance to actually print the right information without
the need to inspect SRK.
- Avoid printing 'tpm2-primary-alg' when it is unset in the JSON as the
default 'ECC' may not match the reality.
No real functional change for the sealing/unsealing expected.
Could ask to Bastien Nocera who originally commited the joysticks hwdb
integration
https://gitlab.freedesktop.org/libinput/libinput/-/merge_requests/1429#note_3338386
and stated that was for use in iio-sensor but later anything was done.
As the variable was never used replace it with the new variable actually
in the process to be use in libinput. Even more at least some of the
idea that was planed for ID_INPUT_JOYSTICK_INTEGRATION could be done in
libinput.
Actually ID_INPUT_JOYSTICK_INTEGRATION was never used anywhere, replace
it with ID_INTEGRATION.
Follow up: a4381cae8b.
The removed code in device_tag_index() in fact does nothing,
as sd_device.all_tags is never cleared. Moreover, not only the code
is meaningless, but it is theoretically/logically wrong, as the symlinks
in /run/udev/tags/ should be 'sticky', hence we should even not try to
remove them.
The current tag concept has been introduced by
e77b146f82 (v247) to make symlinks in
/run/udev/tags/ are 'sticky'.
However, when TAG= (rather than TAG+=) is specified, then the tags
assigned in the previous events were also cleared.
This fixes the issue and now symlinks in /run/udev/tags/ are really
'sticky'.
Fortunately, TAG= is mostly unused. So, the issue should not affect
and the fix should not change anything on almost all systems.
This makes the mstack_load() requires 'ret', as clearing the loaded
mstack without use is meaningless. All callers already pass non-NULL for
the argument.
Follow-up for 8343032a86.
Fixes CID#1645105.
Otherwise, OOM error will never checked, and the "preferred" setting
always emits warning that the field is unknown.
Follow-up for 450e0dce02.
Fixes CID#1645063.
The current code incorrectly subtracts ImageBase from section
VirtualAddress values when loading sections into memory. This is based
on a misunderstanding of the PE specification.
VirtualAddress in section headers is the address of the first byte of
the section relative to the image base when the section is loaded into
memory. In other words, VirtualAddress is already an RVA measured from
the image base, it is definitely NOT an absolute address that needs to
be adjusted.
So when loading a PE image into a newly allocated buffer, sections
should be copied to buffer + VirtualAddress, regardless of what
ImageBase says. The ImageBase field merely indicates the *preferred*
load address, it does not affect how section RVAs are interpreted.
This happens to not cause issues when ImageBase was 0 (since
VirtualAddress - 0 = VirtualAddress), which is why this bug went
undetected on modern kernels. However, it fails with kernels that have
non-zero ImageBase values.
So let's remove the nonsensical VirtualAddress < ImageBase check, and
remove the ImageBase subtractions from section loading offsets. This
lets all kernel UKIs work properly again.
Fixes: #40342
Mostly consists of fixes to
- use the same sector_size as the fdisk context we are using, when
converting between sectors returned by libfdisk to bytes. Fixes#30394 ,
Fixes#30393
- Use the explicit sector size if specified in the home record when are
probing the image file using libblkid. Fixes#30393
Also contains some other improvements with using physical block devices.
- Automatically probe sector size of physical block device, if user does
not pass luks-sector-size explicitly.
- Assign partitions to 1 MiB boundaries, as it is the standard practice
followed by all tools, fdisk, gptfdisk, gnu parted etc.
- Avoid stacking of loop device on top of physical block device in
home_create_luks as it leads to degradation of discard operations, and
mkfs getting stuck.
This is a general cleanup of the sensors hwdb file divides into several
commits per brand.
I have merged the devices that use the same matrices, clean up a little
some clear dmi matches, and apply a inline comment with the device where
is certainly very clear way to display.
My idea is to do more cleanup steps but actually will require more
effort to achieve complete dmis, I can do it with little time, and some
consensus for comment styling.
About the comment styling actually I thing we could follow two rules at
the same time: inline comment when the dmi match is short and there is
no additional many information than just the model, and the other one
comment above the dmi match when is too long or there are need to add
more info.
Emitting "oom" doesn't mesh with the org.freedesktop.oom1.Manager
Killed() API contract, which defines "memory-used" and "memory-pressure"
as possible reasons. Consumers that key off reason thus will either lose
policy attribution or may reject the unknown value completely.
Plumb the reason through so it is visible to consumers.
Also, this makes interfaces stored in OrderedSet rather than Set,
so interfaces becomes up/down in the specified order.
This also makes when multiple interfaces are specified, networkctl tries
to up/down all specfied interfaces even if some of them are failed.
Fixes#40017.
Actually we are defining databases to determine when a usb device is
inherent part of the system or if it's a external device.
Let's use the removable attribute of the port where it is connected to
say that. That gives us the ability to not rely on a particular vendor
only does external devices or to not having the need to be quirking
input subsystem for that purpose that will become unreliable as more and
more internal devices are connected over usb instead over ps2 or i2c
buses. Eg.
https://gitlab.freedesktop.org/libinput/libinput/-/commit/02b495e79022e64514015e1a3dea32997035dd4f?merge_request_iid=1389
Actually this has been seen as reliable in a small set of device from
normal laptops, to detachable ones. The need to check maxchild is 0 is
for detachable devices, pogo pin usbs are fixed, while we attach the
keyboard|touchpad dock the input devices tend to be directly connected
to that port and if the dock has more usbs tend to be a hub that then
exposes removable as unknow. If we don't set maxchild 0 we will not only
guess that the keyboard and touchpad are internal but also incorrectly
other input devices like mice connected to the dock's usb ports.
I have use a very generic name like INTEGRATION because is not actually
used for any other thing and is used to determine not only over usb bus
but for acpi, pci, platform actually.
Also a remap to actual libinput variables is done for compatibility
purposes. if it's possible to have only the INTEGRATION variable instead
multiple ones will be done in the future but is actually unclear.
This can also be used for example to achieve an actual feature that we
lack in linux, when a device with accelerometers and cameras is rotated
the video output is not, this tag the own device cameras as internal
while external ones as external to be able to only do that for the
internal ones.
Note that this has nothing to do with the removable attribute found in
usb storage devices where it's values can be 0 or 1. There is no
conflict at all because the removable attribute we check is specifically
the one found in usb port ones.
UEFI Block I/O Protocol has `Media->IoAlign` field dictating the minimum
alignment for I/O buffer. It's quite surprising this has been lingering
here unnoticed for years, seems like most UEFI implementations have
small or no alignment requirements. U-Boot is not the case here, and
requires at least 512 byte alignment, hence attempt to read GPT
partition table fail and in effect systemd-boot can not find XBOOTLDR
partition.
These patches allow to boot from XBOOTLDR partition on U-Boot - tested
with latest systemd revision and U-Boot master
(`8de6e8f8a076d2c9b6d38d8563db135c167077ec`) on x64 and ARM32, of which
both are failing without the patch.
Also fixes Bitlocker probing logic, which is the only other place where
raw block I/O is used, however this is untested.
It seems the device with modalias e.g. virtio:d00000013v, only appears
after the relevant module is loaded. So, we cannot use the string to
determine if we should load the module.
Fixes#40503.
When running in a container, EFI and XBOOTLDR partition check is
relaxed, hence /boot may be recognized as both EFI and XBOOTLDR
partition.
Before:
```
$ run0 systemd-nspawn -xD / --private-network --bind=/sys/firmware/efi/efivars --bind=/boot -E SYSTEMD_LOG_LEVEL=debug -- build/bootctl --variables=yes --no-pager -x
Failed to check file system type of "/efi": No such file or directory
Using EFI System Partition at /boot.
Using XBOOTLDR partition at /boot as $BOOT.
/boot
```
After:
```
$ run0 systemd-nspawn -xD / --private-network --bind=/sys/firmware/efi/efivars --bind=/boot -E SYSTEMD_LOG_LEVEL=debug -- build/bootctl --variables=yes -x
Failed to check file system type of "/efi": No such file or directory
Using EFI System Partition at /boot.
Didn't find an XBOOTLDR partition, using the ESP as $BOOT.
/boot
```
Yu Watanabe