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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
While it doesn't really make much sense to set "auto-reboot-to-firmware"
as oneshot boot item, let's still support it properly, by also
dispatching such a menu item if selected.
Let's stick to one nomenclature. In userspace we usually call this
"reboot to firmware setup", hence use the same name in sd-boot too.
This name was previously only relevant internally, but since the
addition of the LoaderEntries EFI var is exposed to userspace, hence
let's get this right with the first release adding this.
We keep adding new features, let's advertise to the host OS what these
are in a new variable LoaderFeatures.
It works a bit like OsIndicationsSupported, but is about Loader
features.
This should help to catch issues that are easily detectable by
bad_build_check like the one being fixed in https://github.com/systemd/systemd/pull/10793,
which would totally break the build tomorrow if I hadn't run
`helper.py check_build` manually.
asan doesn't like it if we use strndup() (i.e. a string function) on a
non-NULL terminated buffer (i.e. something that isn't really a string).
Let's hence use memdup_suffix0() instead of strndup(), which is more
appropriate for binary data that is to become a string.
Fixes: #10385
This is a follow-up to 8857fb9beb that prevents the fuzzer from crashing with
```
==220==ERROR: AddressSanitizer: ABRT on unknown address 0x0000000000dc (pc 0x7ff4953c8428 bp 0x7ffcf66ec290 sp 0x7ffcf66ec128 T0)
SCARINESS: 10 (signal)
#0 0x7ff4953c8427 in gsignal (/lib/x86_64-linux-gnu/libc.so.6+0x35427)
#1 0x7ff4953ca029 in abort (/lib/x86_64-linux-gnu/libc.so.6+0x37029)
#2 0x7ff49666503a in log_assert_failed_realm /work/build/../../src/systemd/src/basic/log.c:805:9
#3 0x7ff496614ecf in safe_close /work/build/../../src/systemd/src/basic/fd-util.c:66:17
#4 0x548806 in server_done /work/build/../../src/systemd/src/journal/journald-server.c:2064:9
#5 0x5349fa in LLVMFuzzerTestOneInput /work/build/../../src/systemd/src/fuzz/fuzz-journald-kmsg.c:26:9
#6 0x592755 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) /src/libfuzzer/FuzzerLoop.cpp:571:15
#7 0x590627 in fuzzer::Fuzzer::RunOne(unsigned char const*, unsigned long, bool, fuzzer::InputInfo*, bool*) /src/libfuzzer/FuzzerLoop.cpp:480:3
#8 0x594432 in fuzzer::Fuzzer::MutateAndTestOne() /src/libfuzzer/FuzzerLoop.cpp:708:19
#9 0x5973c6 in fuzzer::Fuzzer::Loop(std::__1::vector<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >, fuzzer::fuzzer_allocator<std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> > > > const&) /src/libfuzzer/FuzzerLoop.cpp:839:5
#10 0x574541 in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) /src/libfuzzer/FuzzerDriver.cpp:764:6
#11 0x5675fc in main /src/libfuzzer/FuzzerMain.cpp:20:10
#12 0x7ff4953b382f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f)
#13 0x420f58 in _start (/out/fuzz-journald-kmsg+0x420f58)
```
The function takes a pointer to a random block of memory and
the length of that block. It shouldn't crash every time it sees
a zero byte at the beginning there.
This should help the dev-kmsg fuzzer to keep going.
With gcc-7.1.1-3.fc26.aarch64:
../src/basic/json.c: In function ‘json_format’:
../src/basic/json.c:1409:40: warning: comparison is always true due to limited range of data type [-Wtype-limits]
if (*q >= 0 && *q < ' ')
^~
../src/basic/json.c: In function ‘inc_lines_columns’:
../src/basic/json.c:1762:31: warning: comparison is always true due to limited range of data type [-Wtype-limits]
} else if (*s >= 0 && *s < 127) /* Process ASCII chars quickly */
^~
Cast to (signed char) silences the warning, but a cast to (int) for some reason
doesn't.
Now that we don't (mis-)use the env file parser to parse kernel command
lines there's no need anymore to override the used newline character
set. Let's hence drop the argument and just "\n\r" always. This nicely
simplifies our code.
