Skip to content

USER_GROUP_API: typo fixes#1

Open
phomes wants to merge 109 commits intopoettering:homedfrom
phomes:homed
Open

USER_GROUP_API: typo fixes#1
phomes wants to merge 109 commits intopoettering:homedfrom
phomes:homed

Conversation

@phomes
Copy link

@phomes phomes commented Sep 15, 2019

Just a few typos I spotted while reading the documentation. Not sure if you want PRs for this at this stage. This is just for the USER_GROUP_API.md but I will do the others as well if you like.

@poettering
ordered-set: add ordered_set_first() helper
7062ae5
@poettering
errno: add new ERRNO_IS_NOT_SUPPORTED() and ERRNO_IS_DISK_SPACE() hel…
f39bbe7 
…pers
@poettering
errno-util: add ERRNO_IS_PRIVILEGE() helper
2fcfeea
@poettering
memory-util: introduce erase_and_free() helper
e94058b
@poettering
string-util: readd string_erase()
d4b1045 
This was dropped in 8e27167, but is
actually useful for some usecases still.
@poettering
loop-util: accept loopback flags when creating loopback device
b0dfc2a 
This way callers can choose if they want partition scanning or not.
@poettering
loop-util: add API to refresh loopback device size and opening existi…
682b899 
…ng loopback block devices
@poettering
loop-util: allow creating loopback block devices with offset/length
260101e
@poettering
loop-util: allow refreshing offset
9a7923a
@poettering
loop-util: add api for locking the block device with flock()
5210ce8
@poettering
loop-util: optionally also resize partitions
d38e8aa
@poettering
loop-util: fill in the loopback number, even a posteriori
b1d7789
@poettering
loop-util: if we fail to fully set up a loop device, detach it again
62777db
@poettering
chown-recursive: move src/core/chown-recursive.[ch] → src/shared/
614bc3c 
We want to use it outside of the core, hence let's moved it to the
shared code directory.
@poettering
chown-recursive: add fd based API
37eb258
@poettering
missing: add XFS magic
07631a8
@poettering
shared: add new wrapper for online fs resizing ioctls
40df083
@poettering
fileio: add an openat() flavour for fopen()
a464b10 
This adds xfopenat() which is to fopen() what xopendirat() is to
opendir(), i.e. the "at" counterpart to fopen().

(Similar to the xopendir() case, we prefix this with "x", in case libc
gains this natively eventually.)
@poettering
fileio: add 'dir_fd' parameter to read_full_file_full()
2130f80 
Let's introduce an "at" version of read_full_file().
@poettering
fileio: add WRITE_STRING_FILE_MODE_0600 flag for writing files
00d9ce3 
usually we want to create new files with mode 0666 (modulated by the
umask). Sometimes we want more restrictive access though, let's add an
explicit flag support for that.

(Note that we don't bother with arbitrary access modes to keep things
simple: just "open as umask permits" and "private to me", nothing else)
@poettering
json: beef up strv parser to also accept a single string instead of a…
e9a4da9 
…n array of strings

Let's be permissive in what we accept and take a single string instead
of an array of strings, when a string is requested, too.
@poettering
json: add new json_variant_is_blank_object() helper
7f84dbd
@poettering
json: add new API json_variant_filter() for dropping fields from objects
b5eeeb6
@poettering
json: add new json_variant_set_field() helper
9fd1d12
@poettering
json: add a new "sensitive" flags for JsonVariant objects
0e416fa 
An object marked with this flag will be erased from memory when it is
freed. This is useful for dealing with sensitive data (key material,
passphrases) encoded in JSON objects.
@poettering
json: add json_parse_file_at() helper
1224506 
This is an "at" function, similar to json_parse_file().
@poettering
json: add flags parameter to json_parse_file(), for parsing "sensitiv…
2a36786 
…e" data

This will call json_variant_sensitive() internally while parsing for
each allocated sub-variant. This is better than calling it a posteriori
at the end, because partially parsed variants will always be properly
erased from memory this way.
@poettering
json: optionally, make string checks stricter when dispatching strings
6d42301
@poettering
json: add json_variant_strv() helper that converts a json variant to …
886dda4 
…an strv

Only works for arrays of strings, of course.
@poettering
nspawn-oci: use new json_variant_strv() helper
b3c05e5
@poettering poettering force-pushed the homed branch 4 times, most recently from 65f8733 to 6893197 Compare January 26, 2020 16:50
@poettering poettering force-pushed the homed branch 2 times, most recently from bf96976 to c809ed7 Compare January 28, 2020 21:43
poettering pushed a commit that referenced this pull request May 6, 2020
@evverx @keszybz
build-system: bring back 'nonnull'
7f3a5eb 
Having taken a look at https://github.com/systemd/systemd/runs/645252074?check_suite_focus=true
where fuzz-journal-remote failed with
```
AddressSanitizer:DEADLYSIGNAL
=================================================================
==16==ERROR: AddressSanitizer: SEGV on unknown address 0x000000000000 (pc 0x7f864f98948e bp 0x7ffde5c6b7c0 sp 0x7ffde5c6b560 T0)
==16==The signal is caused by a READ memory access.
==16==Hint: address points to the zero page.
SCARINESS: 10 (null-deref)
    #0 0x7f864f98948e in output_short /work/build/../../src/systemd/src/shared/logs-show.c
    #1 0x7f864f984624 in show_journal_entry /work/build/../../src/systemd/src/shared/logs-show.c:1154:15
    #2 0x7f864f984b63 in show_journal /work/build/../../src/systemd/src/shared/logs-show.c:1239:21
    #3 0x4cabab in LLVMFuzzerTestOneInput /work/build/../../src/systemd/src/fuzz/fuzz-journal-remote.c:67:21
    systemd#4 0x51fd16 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) /src/libfuzzer/FuzzerLoop.cpp:556:15
    systemd#5 0x51c330 in fuzzer::Fuzzer::RunOne(unsigned char const*, unsigned long, bool, fuzzer::InputInfo*, bool*) /src/libfuzzer/FuzzerLoop.cpp:470:3
    systemd#6 0x523700 in fuzzer::Fuzzer::ReadAndExecuteSeedCorpora(std::__1::vector<fuzzer::SizedFile, fuzzer::fuzzer_allocator<fuzzer::SizedFile> >&) /src/libfuzzer/FuzzerLoop.cpp:765:7
    systemd#7 0x5246cd in fuzzer::Fuzzer::Loop(std::__1::vector<fuzzer::SizedFile, fuzzer::fuzzer_allocator<fuzzer::SizedFile> >&) /src/libfuzzer/FuzzerLoop.cpp:792:3
    systemd#8 0x4de3d1 in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) /src/libfuzzer/FuzzerDriver.cpp:824:6
    systemd#9 0x4cfb47 in main /src/libfuzzer/FuzzerMain.cpp:19:10
    systemd#10 0x7f864e69782f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f)
    systemd#11 0x41f2a8 in _start (out/fuzz-journal-remote+0x41f2a8)

AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: SEGV /work/build/../../src/systemd/src/shared/logs-show.c in output_short
==16==ABORTING
MS: 0 ; base unit: 0000000000000000000000000000000000000000
0x44,0x3d,0xa,0x5f,0x5f,0x52,0x45,0x41,0x4c,0x54,0x49,0x4d,0x45,0x5f,0x54,0x49,0x4d,0x45,0x53,0x54,0x41,0x4d,0x50,0x3d,0x31,0xa,0xa,
D=\x0a__REALTIME_TIMESTAMP=1\x0a\x0a
artifact_prefix='./'; Test unit written to ./crash-d635b9dd31cceff3c912fd45e1a58d7e90f0ad73
Base64: RD0KX19SRUFMVElNRV9USU1FU1RBTVA9MQoK
```
I was wondering why it hadn't been caught by the compiler even though clang should have failed to compile it with
```
../src/shared/logs-show.c:624:25: warning: null passed to a callee that requires a non-null argument [-Wnonnull]
                        print_multiline(f, 4 + fieldlen + 1, 0, OUTPUT_FULL_WIDTH, 0, false,
                        ^
../src/shared/logs-show.c:161:24: note: callee declares array parameter as static here
                size_t highlight[static 2]) {
                       ^        ~~~~~~~~~~
../src/shared/logs-show.c:1239:21: warning: null passed to a callee that requires a non-null argument [-Wnonnull]
                r = show_journal_entry(f, j, mode, n_columns, flags, NULL, NULL, ellipsized);
                    ^                                                      ~~~~
../src/shared/logs-show.c:1133:30: note: callee declares array parameter as static here
                const size_t highlight[static 2],
                             ^        ~~~~~~~~~~
2 warnings generated.
```

Given that judging by systemd#13039 it doesn't seem to be
the first time issues like that have been missed I think it would be better to turn nonnull on
and get around false positives on a case-by-case basis with DISABLE_WARNING_NONNULL .. REENABLE_WARNING

Reopens systemd#6119
poettering pushed a commit that referenced this pull request May 18, 2020
@mrc0mmand @poettering
shared: fix integer overflow in calendarspec
c07f18f 
Fixes: oss-fuzz#22208

```
test/fuzz/fuzz-calendarspec/oss-fuzz-22208... ../src/shared/calendarspec.c:666:48: runtime error: signed integer overflow: 2147000000 + 1000000 cannot be represented in type 'int'
    #0 0x7f0b9f6cc56a in prepend_component ../src/shared/calendarspec.c:666
    #1 0x7f0b9f6cd03a in parse_chain ../src/shared/calendarspec.c:718
    #2 0x7f0b9f6cea1c in parse_calendar_time ../src/shared/calendarspec.c:845
    #3 0x7f0b9f6d1397 in calendar_spec_from_string ../src/shared/calendarspec.c:1084
    systemd#4 0x401570 in LLVMFuzzerTestOneInput ../src/fuzz/fuzz-calendarspec.c:17
    systemd#5 0x401ae0 in main ../src/fuzz/fuzz-main.c:39
    systemd#6 0x7f0b9e31b1a2 in __libc_start_main (/lib64/libc.so.6+0x271a2)
    systemd#7 0x40122d in _start (/home/fsumsal/repos/systemd/build/fuzz-calendarspec+0x40122d)

SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior ../src/shared/calendarspec.c:666:48 in
```
poettering pushed a commit that referenced this pull request May 22, 2020
@ssahani
network: Fix crash when SendOption= is invalid
1eb7342 
```
p11-kit-0.23.20-1.fc32.x86_64 pam-1.3.1-26.fc33.x86_64 xz-libs-5.2.5-1.fc33.x86_64 zlib-1.2.11-21.fc32.x86_64
(gdb) bt
    lvalue=0x560e10 "SendOption", ltype=2, rvalue=0x560e1b "11:string", data=0x561e20, userdata=0x561cd0) at ../src/network/networkd-dhcp-common.c:580
    table=0x4392e0 <network_network_gperf_lookup>, section=0x560ef0 "DHCPv4", section_line=14, lvalue=0x560e10 "SendOption", rvalue=0x560e1b "11:string", flags=CONFIG_PARSE_WARN,
    userdata=0x561cd0) at ../src/shared/conf-parser.c:132
    lookup=0x7ffff7d2f76d <config_item_perf_lookup>, table=0x4392e0 <network_network_gperf_lookup>, flags=CONFIG_PARSE_WARN, section=0x7fffffffc9f8, section_line=0x7fffffffc9a0,
    section_ignored=0x7fffffffc99d, l=0x560e10 "SendOption", userdata=0x561cd0) at ../src/shared/conf-parser.c:270
    lookup=0x7ffff7d2f76d <config_item_perf_lookup>, table=0x4392e0 <network_network_gperf_lookup>, flags=CONFIG_PARSE_WARN, userdata=0x561cd0) at ../src/shared/conf-parser.c:395
    lookup=0x7ffff7d2f76d <config_item_perf_lookup>, table=0x4392e0 <network_network_gperf_lookup>, flags=CONFIG_PARSE_WARN, userdata=0x561cd0) at ../src/shared/conf-parser.c:452
    dropin_dirname=0x7fffffffcbd0 "veth99.network.d", sections=0x4f3a18 "Match", lookup=0x7ffff7d2f76d <config_item_perf_lookup>, table=0x4392e0 <network_network_gperf_lookup>,
    flags=CONFIG_PARSE_WARN, userdata=0x561cd0) at ../src/shared/conf-parser.c:511
(gdb) q
A debugging session is active.

	Inferior 1 [process 118718] will be killed.
```

```
$ printf '[DHCPv4]\nSendOption=1:uint8' >crash

$ ./out/fuzz-network-parser ./crash
INFO: Seed: 1158717610
INFO: Loaded 2 modules   (199728 inline 8-bit counters): 136668 [0x7faf3e91a930, 0x7faf3e93bf0c), 63060 [0xadf190, 0xaee7e4),
INFO: Loaded 2 PC tables (199728 PCs): 136668 [0x7faf3e93bf10,0x7faf3eb51cd0), 63060 [0xaee7e8,0xbe4d28),
./out/fuzz-network-parser: Running 1 inputs 1 time(s) each.
Running: ./crash
Assertion 's' failed at src/basic/parse-util.c:458, function int safe_atou8(const char *, uint8_t *)(). Aborting.
==5588== ERROR: libFuzzer: deadly signal
    #0 0x51811e in __sanitizer_print_stack_trace (/home/vagrant/systemd/out/fuzz-network-parser+0x51811e)
    #1 0x46b921 in fuzzer::PrintStackTrace() (/home/vagrant/systemd/out/fuzz-network-parser+0x46b921)
    #2 0x44ded6 in fuzzer::Fuzzer::CrashCallback() (.part.0) (/home/vagrant/systemd/out/fuzz-network-parser+0x44ded6)
    #3 0x44df9d in fuzzer::Fuzzer::StaticCrashSignalCallback() (/home/vagrant/systemd/out/fuzz-network-parser+0x44df9d)
    systemd#4 0x7faf3d6d7b1f  (/lib64/libpthread.so.0+0x14b1f)
    systemd#5 0x7faf3d3c2624 in raise (/lib64/libc.so.6+0x3c624)
    systemd#6 0x7faf3d3ab8d8 in abort (/lib64/libc.so.6+0x258d8)
    systemd#7 0x7faf3e12593a in log_assert_failed_realm /home/vagrant/systemd/build/../src/basic/log.c:819:9
    systemd#8 0x7faf3e140ce1 in safe_atou8 /home/vagrant/systemd/build/../src/basic/parse-util.c:458:9
    systemd#9 0x68089c in config_parse_dhcp_send_option /home/vagrant/systemd/build/../src/network/networkd-dhcp-common.c:517:21
    systemd#10 0x7faf3debed4e in next_assignment /home/vagrant/systemd/build/../src/shared/conf-parser.c:132:32
    systemd#11 0x7faf3deb7783 in parse_line /home/vagrant/systemd/build/../src/shared/conf-parser.c:270:16
    systemd#12 0x7faf3deb606c in config_parse /home/vagrant/systemd/build/../src/shared/conf-parser.c:395:21
    systemd#13 0x7faf3deb85ee in config_parse_many_files /home/vagrant/systemd/build/../src/shared/conf-parser.c:452:21
    systemd#14 0x7faf3deb8c57 in config_parse_many /home/vagrant/systemd/build/../src/shared/conf-parser.c:511:16
    systemd#15 0x57c2eb in network_load_one /home/vagrant/systemd/build/../src/network/networkd-network.c:470:13
    systemd#16 0x543490 in LLVMFuzzerTestOneInput /home/vagrant/systemd/build/../src/network/fuzz-network-parser.c:26:16
    systemd#17 0x44e3e8 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) (/home/vagrant/systemd/out/fuzz-network-parser+0x44e3e8)
    systemd#18 0x433505 in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) (/home/vagrant/systemd/out/fuzz-network-parser+0x433505)
    systemd#19 0x43c449 in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) (/home/vagrant/systemd/out/fuzz-network-parser+0x43c449)
    systemd#20 0x42c4a6 in main (/home/vagrant/systemd/out/fuzz-network-parser+0x42c4a6)
    systemd#21 0x7faf3d3ad1a2 in __libc_start_main (/lib64/libc.so.6+0x271a2)
    systemd#22 0x42c4fd in _start (/home/vagrant/systemd/out/fuzz-network-parser+0x42c4fd)

NOTE: libFuzzer has rudimentary signal handlers.
      Combine libFuzzer with AddressSanitizer or similar for better crash reports.
SUMMARY: libFuzzer: deadly signal

```
poettering pushed a commit that referenced this pull request Jun 23, 2020
@keszybz
bus-message: avoid dereferencing a NULL pointer
b17af3e 
We'd try to map a zero-byte buffer from a NULL pointer, which is undefined behaviour.

src/systemd/src/libsystemd/sd-bus/bus-message.c:3161:60: runtime error: applying zero offset to null pointer
    #0 0x7f6ff064e691 in find_part /work/build/../../src/systemd/src/libsystemd/sd-bus/bus-message.c:3161:60
    #1 0x7f6ff0640788 in message_peek_body /work/build/../../src/systemd/src/libsystemd/sd-bus/bus-message.c:3283:16
    #2 0x7f6ff064e8db in enter_struct_or_dict_entry /work/build/../../src/systemd/src/libsystemd/sd-bus/bus-message.c:3967:21
    #3 0x7f6ff06444ac in bus_message_enter_struct /work/build/../../src/systemd/src/libsystemd/sd-bus/bus-message.c:4009:13
    systemd#4 0x7f6ff0641dde in sd_bus_message_enter_container /work/build/../../src/systemd/src/libsystemd/sd-bus/bus-message.c:4136:21
    systemd#5 0x7f6ff0619874 in sd_bus_message_dump /work/build/../../src/systemd/src/libsystemd/sd-bus/bus-dump.c:178:29
    systemd#6 0x4293d9 in LLVMFuzzerTestOneInput /work/build/../../src/systemd/src/fuzz/fuzz-bus-message.c:39:9
    systemd#7 0x441986 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) /src/libfuzzer/FuzzerLoop.cpp:558:15
    systemd#8 0x44121e in fuzzer::Fuzzer::RunOne(unsigned char const*, unsigned long, bool, fuzzer::InputInfo*, bool*) /src/libfuzzer/FuzzerLoop.cpp:470:3
    systemd#9 0x443164 in fuzzer::Fuzzer::ReadAndExecuteSeedCorpora(std::__1::vector<fuzzer::SizedFile, fuzzer::fuzzer_allocator<fuzzer::SizedFile> >&) /src/libfuzzer/FuzzerLoop.cpp:770:7
    systemd#10 0x4434bc in fuzzer::Fuzzer::Loop(std::__1::vector<fuzzer::SizedFile, fuzzer::fuzzer_allocator<fuzzer::SizedFile> >&) /src/libfuzzer/FuzzerLoop.cpp:799:3
    systemd#11 0x42d2bc in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) /src/libfuzzer/FuzzerDriver.cpp:846:6
    systemd#12 0x42978a in main /src/libfuzzer/FuzzerMain.cpp:19:10
    systemd#13 0x7f6fef13c82f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f)
    systemd#14 0x407808 in _start (out/fuzz-bus-message+0x407808)
poettering pushed a commit that referenced this pull request Jun 24, 2020
@keszybz
fuzz-netdev-parser: add test case for earlier version of preceding pa…
804a436 
…tches

AddressSanitizer:DEADLYSIGNAL
=================================================================
==12==ERROR: AddressSanitizer: ABRT on unknown address 0x00000000000c (pc 0x7f0a518b3428 bp 0x7fffa463bfd0 sp 0x7fffa463be68 T0)
SCARINESS: 10 (signal)
    #0 0x7f0a518b3428 in raise (/lib/x86_64-linux-gnu/libc.so.6+0x35428)
    #1 0x7f0a518b5029 in abort (/lib/x86_64-linux-gnu/libc.so.6+0x37029)
    #2 0x7f0a52ca635a in log_assert_failed_realm /work/build/../../src/systemd/src/basic/log.c:819:9
    #3 0x4eea92 in config_parse_wireguard_endpoint /work/build/../../src/systemd/src/network/netdev/wireguard.c:808:9
    systemd#4 0x7f0a52b2f74e in next_assignment /work/build/../../src/systemd/src/shared/conf-parser.c:133:32
    systemd#5 0x7f0a52b2954e in parse_line /work/build/../../src/systemd/src/shared/conf-parser.c:242:16
    systemd#6 0x7f0a52b28911 in config_parse /work/build/../../src/systemd/src/shared/conf-parser.c:377:21
    systemd#7 0x7f0a52b29ec6 in config_parse_many_files /work/build/../../src/systemd/src/shared/conf-parser.c:439:21
    systemd#8 0x7f0a52b2a5a6 in config_parse_many /work/build/../../src/systemd/src/shared/conf-parser.c:507:16
    systemd#9 0x4d8d6c in netdev_load_one /work/build/../../src/systemd/src/network/netdev/netdev.c:732:13
    systemd#10 0x4d3e2b in LLVMFuzzerTestOneInput /work/build/../../src/systemd/src/network/fuzz-netdev-parser.c:23:16
    systemd#11 0x6b3266 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) /src/libfuzzer/FuzzerLoop.cpp:558:15
    systemd#12 0x6af860 in fuzzer::Fuzzer::RunOne(unsigned char const*, unsigned long, bool, fuzzer::InputInfo*, bool*) /src/libfuzzer/FuzzerLoop.cpp:470:3
    systemd#13 0x6b6970 in fuzzer::Fuzzer::ReadAndExecuteSeedCorpora(std::__1::vector<fuzzer::SizedFile, fuzzer::fuzzer_allocator<fuzzer::SizedFile> >&) /src/libfuzzer/FuzzerLoop.cpp:770:7
    systemd#14 0x6b7376 in fuzzer::Fuzzer::Loop(std::__1::vector<fuzzer::SizedFile, fuzzer::fuzzer_allocator<fuzzer::SizedFile> >&) /src/libfuzzer/FuzzerLoop.cpp:799:3
    systemd#15 0x67573f in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) /src/libfuzzer/FuzzerDriver.cpp:846:6
    systemd#16 0x667097 in main /src/libfuzzer/FuzzerMain.cpp:19:10
    systemd#17 0x7f0a5189e82f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f)
    systemd#18 0x4295a8 in _start (out/fuzz-netdev-parser+0x4295a8)

DEDUP_TOKEN: raise--abort--log_assert_failed_realm
AddressSanitizer can not provide additional info.
SUMMARY: AddressSanitizer: ABRT (/lib/x86_64-linux-gnu/libc.so.6+0x35428) in raise
==12==ABORTING
poettering pushed a commit that referenced this pull request Aug 25, 2020
@daandemeyer
kernel-install: Use "Default" as fallback instead of "Linux"
6426c98 
"Linux" conflicts /efi/Linux when /efi is the install location.
/efi/Linux is already reserved for unified kernel images so we can't use
it for type #1 images. Instead, we use "Default".
poettering pushed a commit that referenced this pull request Sep 18, 2020
@keszybz
shared/libcrypt-util: use libcrypt_ra()
a937ce2 
This lets the libc/xcrypt allocate as much storage area as it needs.
Should fix systemd#16965:

testsuite-46.sh[74]: ==74==ERROR: AddressSanitizer: stack-buffer-overflow on address 0x7f3e972e1080 at pc 0x7f3e9be8deed bp 0x7ffce4f28530 sp 0x7ffce4f27ce0
testsuite-46.sh[74]: WRITE of size 131232 at 0x7f3e972e1080 thread T0
testsuite-46.sh[74]:     #0 0x7f3e9be8deec  (/usr/lib/clang/10.0.1/lib/linux/libclang_rt.asan-x86_64.so+0x9feec)
testsuite-46.sh[74]:     #1 0x559cd05a6412 in user_record_make_hashed_password /systemd-meson-build/../build/src/home/user-record-util.c:818:21
testsuite-46.sh[74]:     #2 0x559cd058fb03 in create_home /systemd-meson-build/../build/src/home/homectl.c:1112:29
testsuite-46.sh[74]:     #3 0x7f3e9b5b3058 in dispatch_verb /systemd-meson-build/../build/src/shared/verbs.c:103:24
testsuite-46.sh[74]:     systemd#4 0x559cd058c101 in run /systemd-meson-build/../build/src/home/homectl.c:3325:16
testsuite-46.sh[74]:     systemd#5 0x559cd058c00a in main /systemd-meson-build/../build/src/home/homectl.c:3328:1
testsuite-46.sh[74]:     systemd#6 0x7f3e9a88b151 in __libc_start_main (/usr/lib/libc.so.6+0x28151)
testsuite-46.sh[74]:     systemd#7 0x559cd0583e7d in _start (/usr/bin/homectl+0x24e7d)
testsuite-46.sh[74]: Address 0x7f3e972e1080 is located in stack of thread T0 at offset 32896 in frame
testsuite-46.sh[74]:     #0 0x559cd05a60df in user_record_make_hashed_password /systemd-meson-build/../build/src/home/user-record-util.c:789
testsuite-46.sh[74]:   This frame has 6 object(s):
testsuite-46.sh[74]:     [32, 40) 'priv' (line 790)
testsuite-46.sh[74]:     [64, 72) 'np' (line 791)
testsuite-46.sh[74]:     [96, 104) 'salt' (line 809)
testsuite-46.sh[74]:     [128, 32896) 'cd' (line 810)
testsuite-46.sh[74]:     [33152, 33168) '.compoundliteral' <== Memory access at offset 32896 partially underflows this variable
testsuite-46.sh[74]:     [33184, 33192) 'new_array' (line 832) <== Memory access at offset 32896 partially underflows this variable
testsuite-46.sh[74]: HINT: this may be a false positive if your program uses some custom stack unwind mechanism, swapcontext or vfork
testsuite-46.sh[74]:       (longjmp and C++ exceptions *are* supported)
testsuite-46.sh[74]: SUMMARY: AddressSanitizer: stack-buffer-overflow (/usr/lib/clang/10.0.1/lib/linux/libclang_rt.asan-x86_64.so+0x9feec)

It seems 'struct crypt_data' is 32896 bytes, but libclang_rt wants more, at least 33168?
poettering pushed a commit that referenced this pull request Feb 11, 2021
@keszybz
udev: add assert to make coverity happy
b5f1c0d 
Coverity says:
CID 1446387 (#1 of 1): Bad bit shift operation (BAD_SHIFT)
8. negative_shift: In expression 1U << (int)cmd, shifting by a negative amount
has undefined behavior. The shift amount, cmd, is -22.

I don't think there's any issue, unless we forget to set token->data
appropriately. Let's add an assert.
poettering pushed a commit that referenced this pull request Aug 10, 2021
@Werkov
ci: Detect shell prompt with higher specificity
7e5e604 
The current pattern '#' triggers on the openSUSE kernel version that is
printed early during boot when no actual prompt is ready
> [    0.000000] Linux version 5.12.10-1-default (geeko@buildhost) (gcc (SUSE Linux) 11.1.1 20210510 [revision 23855a176609fe8dda6abaf2b21846b4517966eb], GNU ld (GNU Binutils; openSUSE Tumbleweed) 2.36.1.20210326-4) #1 SMP Fri Jun 11 05:05:06 UTC 2021 (b92eaf7)

Instead wait for pattern that: a) should have fewer false positives, b)
still be with working on distro shells:

openSUSE (red color)
^[[1m^[[31mimage:~ #^[[m^O

arch
[root@image ~]#

debian
root@image:~#

ubuntu
root@image:~#

fedora
[root@image ~]#
poettering pushed a commit that referenced this pull request Nov 23, 2021
@mrc0mmand
test: suppress certain leaks reported by LSan
f201f34 
so we can run TEST-46 under sanitizers once again.

`systemd-homed` runs fsck on home directories, which reports a memory
leak we're not interested in. Let's introduce an LSan suppression file
to get around this. Since the patterns in the suppression file are
matched using basic substring match[0], they're a bit cumbersome, but
should get the work one.

[0] https://github.com/google/sanitizers/wiki/AddressSanitizerLeakSanitizer#suppressions

Example leaks (as reported by TEST-46):
```
systemd-homed[1333]: =================================================================
systemd-homed[1333]: ==1333==ERROR: LeakSanitizer: detected memory leaks
systemd-homed[1333]: Direct leak of 24 byte(s) in 1 object(s) allocated from:
systemd-homed[1333]:     #0 0x7f0c8facccd1 in calloc (/usr/lib/clang/12.0.1/lib/linux/libclang_rt.asan-x86_64.so+0xf4cd1)
systemd-homed[1333]:     #1 0x558d9494ff67  (/usr/bin/fsck+0x3f67)
systemd-homed[1333]: Direct leak of 6 byte(s) in 1 object(s) allocated from:
systemd-homed[1333]:     #0 0x7f0c8fa906c1 in strdup (/usr/lib/clang/12.0.1/lib/linux/libclang_rt.asan-x86_64.so+0xb86c1)
systemd-homed[1333]:     #1 0x558d949518fd  (/usr/bin/fsck+0x58fd)
systemd-homed[1333]: SUMMARY: AddressSanitizer: 30 byte(s) leaked in 2 allocation(s).
systemd-homed[1337]: ==1337==WARNING: Symbolizer was blocked from starting itself!
systemd-homed[1337]: =================================================================
systemd-homed[1337]: ==1337==ERROR: LeakSanitizer: detected memory leaks
systemd-homed[1337]: Direct leak of 67584 byte(s) in 1 object(s) allocated from:
systemd-homed[1337]:     #0 0x7f01edb84b19  (/usr/lib/clang/12.0.1/lib/linux/libclang_rt.asan-x86_64.so+0xf4b19)
systemd-homed[1337]:     #1 0x7f01e8326829  (/usr/bin/../lib/libLLVM-12.so+0xb46829)
systemd-homed[1337]: SUMMARY: AddressSanitizer: 67584 byte(s) leaked in 1 allocation(s).
```

With the suppression file:
```
systemd-homed[1339]: -----------------------------------------------------
systemd-homed[1339]: Suppressions used:
systemd-homed[1339]:   count      bytes template
systemd-homed[1339]:       2         30 /bin/fsck$
systemd-homed[1339]: -----------------------------------------------------
systemd-homed[1343]: ==1343==WARNING: Symbolizer was blocked from starting itself!
systemd-homed[1343]: -----------------------------------------------------
systemd-homed[1343]: Suppressions used:
systemd-homed[1343]:   count      bytes template
systemd-homed[1343]:       1      67584 /lib/libLLVM
systemd-homed[1343]: -----------------------------------------------------
```
poettering pushed a commit that referenced this pull request Jan 31, 2022
@keszybz
seccomp: move arch_prctl to @default
5f02870 
It was reported as used by the linker:

> [It is] called in the setup of ld-linux-x86-64.so.2 from _dl_sysdep_start.
> My local call stack (with LTO):
>
> #0 init_cpu_features.constprop.0 (/usr/lib64/ld-linux-x86-64.so.2)
> #1 _dl_sysdep_start (/usr/lib64/ld-linux-x86-64.so.2)
> #2 _dl_start (/usr/lib64/ld-linux-x86-64.so.2)
> #3 _start (/usr/lib64/ld-linux-x86-64.so.2)
>
> Looking through the source, I think it's this (links for glibc 2.34):
> - First dl_platform_init calls _dl_x86_init_cpu_features, a wrapper for init_cpu_features.
> - Then init_cpu_features calls get_cet_status.
> - At last, get_cet_status invokes arch_prctl.

Fixes systemd#22033.
poettering pushed a commit that referenced this pull request Jan 31, 2022
@evverx @yuwata
tests: make fuzz-journal-remote less flaky
381ccb5 
by always calling journal_remote_server_destroy, which resets global
variables like journal_remote_server_global. It should prevent crashes like
```
Assertion 'journal_remote_server_global == NULL' failed at src/journal-remote/journal-remote.c:312, function int journal_remote_server_init(RemoteServer *, const char *, JournalWriteSplitMode, _Bool, _Bool)(). Aborting.
AddressSanitizer:DEADLYSIGNAL
=================================================================
==24769==ERROR: AddressSanitizer: ABRT on unknown address 0x0539000060c1 (pc 0x7f23b4d5818b bp 0x7ffcbc4080c0 sp 0x7ffcbc407e70 T0)
SCARINESS: 10 (signal)
    #0 0x7f23b4d5818b in raise /build/glibc-eX1tMB/glibc-2.31/sysdeps/unix/sysv/linux/raise.c:51:1
    #1 0x7f23b4d37858 in abort /build/glibc-eX1tMB/glibc-2.31/stdlib/abort.c:79:7
    #2 0x7f23b5731809 in log_assert_failed systemd/src/basic/log.c:866:9
```
poettering pushed a commit that referenced this pull request Jan 31, 2022
@evverx
tests: fuzz client_handle_offer
4158af3 
Turns out that part of systemd isn't covered by any fuzz targets and
that's not ideal considering that it parses data sent remotely. The
fuzzer triggers an infinite loop in lease_parse_routes as soon as it
starts so it seems to be working :-)
```
INFO: Running with entropic power schedule (0xFF, 100).
INFO: Seed: 23620602
INFO: Loaded 2 modules   (182073 inline 8-bit counters): 176548 [0x7fdf511fc8d0, 0x7fdf51227a74), 5525 [0x5f6ef0, 0x5f8485),
INFO: Loaded 2 PC tables (182073 PCs): 176548 [0x7fdf51227a78,0x7fdf514d94b8), 5525 [0x5f8488,0x60ddd8),
./build/fuzz-dhcp-client: Running 1 inputs 1 time(s) each.
Running: test/fuzz/fuzz-dhcp-client/timeout-ed34161922c7075c4773f2ada3dee8685d220980
ALARM: working on the last Unit for 31 seconds
       and the timeout value is 30 (use -timeout=N to change)
==80731== ERROR: libFuzzer: timeout after 31 seconds
    #0 0x51b32e in __sanitizer_print_stack_trace (/home/vagrant/systemd/build/fuzz-dhcp-client+0x51b32e)
    #1 0x4689e9 in fuzzer::PrintStackTrace() (/home/vagrant/systemd/build/fuzz-dhcp-client+0x4689e9)
    #2 0x44a0f4 in fuzzer::Fuzzer::StaticAlarmCallback() (/home/vagrant/systemd/build/fuzz-dhcp-client+0x44a0f4)
    #3 0x7fdf4f8b474f  (/lib64/libc.so.6+0x4274f)
    systemd#4 0x465fee in __sanitizer_cov_trace_const_cmp4 (/home/vagrant/systemd/build/fuzz-dhcp-client+0x465fee)
    systemd#5 0x57eee5 in lease_parse_routes /home/vagrant/systemd/build/../src/libsystemd-network/sd-dhcp-lease.c:495:23
    systemd#6 0x57baf3 in dhcp_lease_parse_options /home/vagrant/systemd/build/../src/libsystemd-network/sd-dhcp-lease.c:701:21
    systemd#7 0x572450 in parse_options /home/vagrant/systemd/build/../src/libsystemd-network/dhcp-option.c:348:33
    systemd#8 0x571cea in dhcp_option_parse /home/vagrant/systemd/build/../src/libsystemd-network/dhcp-option.c:381:21
    systemd#9 0x559a01 in client_handle_offer /home/vagrant/systemd/build/../src/libsystemd-network/sd-dhcp-client.c:1543:13
    systemd#10 0x5592bd in LLVMFuzzerTestOneInput /home/vagrant/systemd/build/../src/libsystemd-network/fuzz-dhcp-client.c:78:9
    systemd#11 0x44a379 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) (/home/vagrant/systemd/build/fuzz-dhcp-client+0x44a379)
    systemd#12 0x42ae1f in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) (/home/vagrant/systemd/build/fuzz-dhcp-client+0x42ae1f)
    systemd#13 0x432ade in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) (/home/vagrant/systemd/build/fuzz-dhcp-client+0x432ade)
    systemd#14 0x421f86 in main (/home/vagrant/systemd/build/fuzz-dhcp-client+0x421f86)
    systemd#15 0x7fdf4f89f55f in __libc_start_call_main (/lib64/libc.so.6+0x2d55f)
    systemd#16 0x7fdf4f89f60b in __libc_start_main@GLIBC_2.2.5 (/lib64/libc.so.6+0x2d60b)
    systemd#17 0x421fd4 in _start (/home/vagrant/systemd/build/fuzz-dhcp-client+0x421fd4)

SUMMARY: libFuzzer: timeout
```
poettering pushed a commit that referenced this pull request Jan 31, 2022
@evverx
sd-dhcp-lease: fix a memory leak in dhcp_lease_parse_search_domains
9591c0a 
=================================================================
==81071==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 16 byte(s) in 1 object(s) allocated from:
    #0 0x51245c in __interceptor_reallocarray (/home/vagrant/systemd/build/fuzz-dhcp-client+0x51245c)
    #1 0x7f01440c67e6 in strv_push /home/vagrant/systemd/build/../src/basic/strv.c:435:13
    #2 0x7f01440ca9e1 in strv_consume /home/vagrant/systemd/build/../src/basic/strv.c:506:13
    #3 0x7f01440ca9e1 in strv_extend /home/vagrant/systemd/build/../src/basic/strv.c:558:16
    systemd#4 0x5806e3 in dhcp_lease_parse_search_domains /home/vagrant/systemd/build/../src/libsystemd-network/sd-dhcp-lease.c:900:21
    systemd#5 0x57c1be in dhcp_lease_parse_options /home/vagrant/systemd/build/../src/libsystemd-network/sd-dhcp-lease.c:727:21
    systemd#6 0x572450 in parse_options /home/vagrant/systemd/build/../src/libsystemd-network/dhcp-option.c:348:33
    systemd#7 0x571c6a in dhcp_option_parse /home/vagrant/systemd/build/../src/libsystemd-network/dhcp-option.c:376:13
    systemd#8 0x559a01 in client_handle_offer /home/vagrant/systemd/build/../src/libsystemd-network/sd-dhcp-client.c:1543:13
    systemd#9 0x5592bd in LLVMFuzzerTestOneInput /home/vagrant/systemd/build/../src/libsystemd-network/fuzz-dhcp-client.c:74:16
    systemd#10 0x44a379 in fuzzer::Fuzzer::ExecuteCallback(unsigned char const*, unsigned long) (/home/vagrant/systemd/build/fuzz-dhcp-client+0x44a379)
    systemd#11 0x42ae1f in fuzzer::RunOneTest(fuzzer::Fuzzer*, char const*, unsigned long) (/home/vagrant/systemd/build/fuzz-dhcp-client+0x42ae1f)
    systemd#12 0x432ade in fuzzer::FuzzerDriver(int*, char***, int (*)(unsigned char const*, unsigned long)) (/home/vagrant/systemd/build/fuzz-dhcp-client+0x432ade)
    systemd#13 0x421f86 in main (/home/vagrant/systemd/build/fuzz-dhcp-client+0x421f86)
    systemd#14 0x7f0142fff55f in __libc_start_call_main (/lib64/libc.so.6+0x2d55f)
poettering pushed a commit that referenced this pull request Mar 21, 2022
@keszybz
man: cross-link to BLS in more places, use "Type #1", "Type #2" as ap…
a0aa383 
…propriate
poettering added a commit that referenced this pull request Mar 21, 2022
@poettering
man: clarify where the settings in type #1 entries are documented
d212b86 
So (maybe weirdly) loader.conf(5) documents both loader.conf and type #1
entries (because they share a similar syntax). But it then only lists
the options of loader.conf. Let's add an explicit hint where to find
the documentation of the type #1 entries.
poettering added a commit that referenced this pull request Mar 21, 2022
@poettering
man: clarify that type #1 entries are also read from the XBOOTLDR par…
cafa9d8 
…tition
poettering added a commit that referenced this pull request Mar 23, 2022
@poettering
bootspec: don't use conf_files_list() for finding type #1 entries
1121e04 
We can't really use conf_files_list() for finding type #1 entries, since
it is case-sensitive, but type #1 entries are typically placed on VFAT,
i.e. are case-insensitive.

hence, use readdir_all() instead, which is quite similar, but gives us
all files, and allows us to do a case-insensitive check.

While we are at it, use openat() on the open dir to open the file, and
pass that around, to make things a tiny bit more race-free.
poettering added a commit that referenced this pull request Mar 24, 2022
@poettering
bootspec: don't use conf_files_list() for finding type #1 entries
2615fd9 
We can't really use conf_files_list() for finding type #1 entries, since
it is case-sensitive, but type #1 entries are typically placed on VFAT,
i.e. are case-insensitive.

hence, use readdir_all() instead, which is quite similar, but gives us
all files, and allows us to do a case-insensitive check.

While we are at it, use openat() on the open dir to open the file, and
pass that around, to make things a tiny bit more race-free.
poettering added a commit that referenced this pull request Mar 24, 2022
@poettering
bootspec: don't use conf_files_list() for finding type #1 entries
890aca6 
We can't really use conf_files_list() for finding type #1 entries, since
it is case-sensitive, but type #1 entries are typically placed on VFAT,
i.e. are case-insensitive.

hence, use readdir_all() instead, which is quite similar, but gives us
all files, and allows us to do a case-insensitive check.

While we are at it, use openat() on the open dir to open the file, and
pass that around, to make things a tiny bit more race-free.
poettering added a commit that referenced this pull request Mar 28, 2022
@poettering
bootspec: don't use conf_files_list() for finding type #1 entries
d04f033 
We can't really use conf_files_list() for finding type #1 entries, since
it is case-sensitive, but type #1 entries are typically placed on VFAT,
i.e. are case-insensitive.

hence, use readdir_all() instead, which is quite similar, but gives us
all files, and allows us to do a case-insensitive check.

While we are at it, use openat() on the open dir to open the file, and
pass that around, to make things a tiny bit more race-free.
poettering pushed a commit that referenced this pull request May 9, 2022
@evverx @yuwata
timedatectl: fix a memory leak
a2e37d5 
```
timedatectl list-timezones --no-pager
...
==164329==ERROR: LeakSanitizer: detected memory leaks

Direct leak of 8192 byte(s) in 1 object(s) allocated from:
    #0 0x7fe8a74b6f8c in reallocarray (/lib64/libasan.so.6+0xaef8c)
    #1 0x7fe8a63485dc in strv_push ../src/basic/strv.c:419
    #2 0x7fe8a6349419 in strv_consume ../src/basic/strv.c:490
    #3 0x7fe8a634958d in strv_extend ../src/basic/strv.c:542
    systemd#4 0x7fe8a643d787 in bus_message_read_strv_extend ../src/libsystemd/sd-bus/bus-message.c:5606
    systemd#5 0x7fe8a643db9d in sd_bus_message_read_strv ../src/libsystemd/sd-bus/bus-message.c:5628
    systemd#6 0x4085fb in list_timezones ../src/timedate/timedatectl.c:314
    systemd#7 0x7fe8a61ef3e1 in dispatch_verb ../src/shared/verbs.c:103
    systemd#8 0x410f91 in timedatectl_main ../src/timedate/timedatectl.c:1025
    systemd#9 0x41111c in run ../src/timedate/timedatectl.c:1043
    systemd#10 0x411242 in main ../src/timedate/timedatectl.c:1046
    systemd#11 0x7fe8a489df1f in __libc_start_call_main (/lib64/libc.so.6+0x40f1f)
```
poettering added a commit that referenced this pull request May 11, 2022
@poettering
efi: include UEFI monotonic boot counter in random seed
f183c4f 
UEFI provides a "monotonic boot counter" which is supposed to increase on
each reboot. We can include this in our random seed hash logic, which
makes things more robust in case our changes to the ESP end up not
actually being as persistent as we assume. As long as the monotonic boot
counter increases we should be good, as each boot we'll anyway end up
with a new seed that way.

This in fact should also pave the way that we can eventually enable the
random seed logic even on SecureBoot enabled systems. Why that? With
this change the input for the random seed hash is now:

1. the old seed file contents
2. (optionally) some bits from the UEFI RNG
3. (optionally) a per system random "token" stored in an UEFI variable,
   initialized at OS install
4. the UEFI monotonic counter
5. a counter integer used by the random seed logic.

We can ignore systemd#5 entirely for security considerations, it's always going
to be a constant series of values determined by the random seed logic.

The #1 file is under control of the attacker. (Since it resides in the
unprotected ESP)

The #2 data is possibly low quality. (it's hard enough to trust the
quality of the Linux RNG, let's not go as far as trusting the UEFI one)

The #3 data should not be under control of the attacker, and should only
exist if explicitly set. Unless you have privileged access to the system
you should not be able to read or set it. (well, within limits of flash
chip security and its connectivity to the firmware)

The systemd#4 data is provided by the firmware, and should not be under control
of the attacker. If it works correctly then it might still be guessable
(i.e. a new system might have the counter close to zero).

Thus: 1+2+5 are guessable/under control of attacker, but 3+4 should not
be. Thus, if 3 is not known to attacker and not guessable, and 4
strictly monotonically increasing then it should be enough to guarantee
that every boot will get a different seed passed in, that should not be
known or guessable by the attacker.

That all said, this patch does not enable the random seed logic on
SecureBoot. That is left for a later patch.
poettering pushed a commit that referenced this pull request Jul 5, 2022
@keszybz
docs/BLS: rework the description of directory layout
0f5a416 
We said "`$BOOT/loader/` is the directory containing all files needed
for Type #1 entries" which is blatantly wrong. And also saying that we
define two directories, /loader and /loader/entries, but only ever defining
the second one was not very consistent.

Instead, let's say that /loader/ is for "boot loader configuration", and
/loader/entries has the snippets. A new section about /<entry-token>/<version>/
is added. This is described as the "recommended layout for additional files".

Also, we said that ID= should be used in the file name, but in fact it
wasn't in the example that was given, and afaik, nobody ever did that. So
this part is reduced to say "kernel version (as returned by `uname -r`,
including the OS identifier)". AFAIK, all distros include some form of
OS identifier in the version, so this should be good enough.

Since we now don't depend on autodetection (e.g. with entry-token and layout
configured), the installed doesn't need to always create /loader/entries and
things will still work. So don't say that the installer needs to create it.

Part of the discussion is moved to the Discussion section.

Overall, this brings the specification more in line with actual practice.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

2 participants

@phomes @poettering