The RNG can't actually be seeded from a shell script, due to the
reliance on ioctls and the fact that entropy written into the
unprivileged /dev/urandom device is not immediately mixed in, making
subsequent seed reads dangerous. For this reason, the seedrng project
provides a basic "C script" meant to be copy and pasted into projects
like Busybox and tweaked as needed: <https://git.zx2c4.com/seedrng/about/>.
The SeedRNG construction has been part of systemd's seeder since
January, and recently was added to Android, OpenRC, and Void's Runit,
with more integrations on their way depending on context. Virtually
every single Busybox-based distro I have seen seeds things in wrong,
incomplete, or otherwise dangerous way. For example, fixing this issue
in Buildroot requires first for Busybox to have this fix.
This commit imports it into Busybox and wires up the basic config. The
utility itself is tiny, and unlike the example code from the SeedRNG
project, we can re-use libbb's existing hash functions, rather than
having to ship a standalone BLAKE2s, which makes this even smaller.
function old new delta
seedrng_main - 1463 +1463
.rodata 107858 108665 +807
seed_from_file_if_exists - 697 +697
packed_usage 34414 34519 +105
static.longopts - 38 +38
static.seedrng_prefix - 26 +26
seed_dir - 8 +8
non_creditable_seed - 8 +8
lock_file - 8 +8
creditable_seed - 8 +8
applet_names 2747 2755 +8
applet_main 3192 3200 +8
------------------------------------------------------------------------------
(add/remove: 9/0 grow/shrink: 4/0 up/down: 3184/0) Total: 3184 bytes
text data bss dec hex filename
973776 4219 1816 979811 ef363 busybox_old
977035 4227 1848 983110 f0046 busybox_unstripped
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Signed-off-by: Bernhard Reutner-Fischer <rep.dot.nop@gmail.com>
The result of looking at "grep -F -B2 '*fill*' busybox_unstripped.map"
function old new delta
.rodata 108586 108460 -126
------------------------------------------------------------------------------
(add/remove: 0/0 grow/shrink: 0/1 up/down: 0/-126) Total: -126 bytes
text data bss dec hex filename
970412 4219 1848 976479 ee65f busybox_old
970286 4219 1848 976353 ee5e1 busybox_unstripped
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
The specification requires volume label to be space padded.
Latest fsck.vfat will remove the zero padded volume label
as invalid. See also:
https://github.com/dosfstools/dosfstools/issues/172
Make the default label also "NO NAME" which has the special meaning
that label is not set.
function old new delta
mkfs_vfat_main 1470 1502 +32
static.NO_NAME_11 - 12 +12
.rodata 104309 104318 +9
------------------------------------------------------------------------------
(add/remove: 1/0 grow/shrink: 2/0 up/down: 53/0) Total: 53 bytes
Signed-off-by: Timo Teräs <timo.teras@iki.fi>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
The MBR partition type 0xF8 is used by the Arm EBBR specification[1] for
protective partitions over fixed-location firmware images.
[1]: https://github.com/ARM-software/ebbr
Signed-off-by: Vincent Stehlé <vincent.stehle@arm.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
The reported case was an attempt to remount,rw a CD-ROM:
mount -o remount,rw /mnt/sr0
which "succeeded" by falling back to RO:
mount("/dev/sr0", "/mnt/sr0", 0x412862, MS_REMOUNT|MS_SILENT|MS_RELATIME, "nojoliet,check=s,map=n,blocksize"...) = -1 EROFS (Read-only file system)
...
mount("/dev/sr0", "/mnt/sr0", 0x412862, MS_RDONLY|MS_REMOUNT|MS_SILENT|MS_RELATIME, "nojoliet,check=s,map=n,blocksize"...) = 0
Clearly, not what was intended!
function old new delta
parse_mount_options 241 267 +26
mount_main 1198 1211 +13
singlemount 1301 1313 +12
inetd_main 1919 1911 -8
------------------------------------------------------------------------------
(add/remove: 0/0 grow/shrink: 3/1 up/down: 51/-8) Total: 43 bytes
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
Some people prefer the week to start on Monday. Add the '-m'
option to support this.
function old new delta
cal_main 926 966 +40
day_array 316 337 +21
packed_usage 34151 34158 +7
.rodata 99224 99225 +1
------------------------------------------------------------------------------
(add/remove: 0/0 grow/shrink: 4/0 up/down: 69/0) Total: 69 bytes
Signed-off-by: Ron Yorston <rmy@pobox.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
The input buffer is initialised to a reasonable size and extended
if necessary. When this happened the offset into the buffer wasn't
reset to zero so subsequent lines were appended to the long line.
Fix this and add some tests.
function old new delta
rev_main 377 368 -9
------------------------------------------------------------------------------
(add/remove: 0/0 grow/shrink: 0/1 up/down: 0/-9) Total: -9 bytes
Signed-off-by: Ron Yorston <rmy@pobox.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
Should we validate that PID is a number for "taskset -ap PID"?
We don't actually need it, and pathological input like
"../../DIR_WITH_LOTS_OF_PIDS" can only cause "taskset"ing
of many pids. Which is something user can do anyway.
function old new delta
taskset_main 190 181 -9
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
This lets bb mount build for limited targets without syslog.h,
as long as the parts using it like NFS are disabled.
Signed-off-by: Lauri Kasanen <cand@gmx.com>
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
When mounting, in parallel, multiple loop devices (squashfs for the
submitter's case), the following behavior can be observed:
stat64(/path/to/image, {st_mode=S_IFREG|0644, st_size=4096, ...}) = 0
openat(AT_FDCWD, /path/to/image, O_RDWR|O_LARGEFILE) = 3
openat(AT_FDCWD, /dev/loop-control, O_RDWR|O_LARGEFILE|O_CLOEXEC) = 4
ioctl(4, LOOP_CTL_GET_FREE) = 12
close(4) = 0
openat(AT_FDCWD, /dev/loop12, O_RDWR|O_LARGEFILE) = 4
ioctl(4, LOOP_GET_STATUS64, {lo_offset=0, lo_number=12, lo_flags=LO_FLAGS_AUTOCLEAR, lo_file_name=/path/to/image, ...}) = 0
close(4) = 0
close(3) = 0
write(2, "mount: can't setup loop device\n", 31mount: can't setup loop device
) = 31
exit_group(0) = ?
+++ exited with 0 +++
The ioctl LOOP_CTL_GET_FREE has resulted in the same result for
a competing mount process. The subsequent ioctl LOOP_GET_STATUS64
fails, having succeeded for the competing mount process.
Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com>
