user/sven/linux.git/init, branch v4.9.328

random: only call boot_init_stack_canary() once

2022-08-25T09:09:22Z

In commit 166a592cad36 ("random: move rand_initialize() earlier") the boot_init_stack_canary() call was added after the new random_init() call. However, the upstream commit d55535232c3d ("random: move rand_initialize() earlier") also included removing the earlier call to boot_init_stack_canary(), making sure this call is done after random_init(). Hence fix what I assume is a wrong merge conflict resolution on the linux-4.9.y stable branch. Signed-off-by: Hans-Christian Noren Egtvedt Signed-off-by: Greg Kroah-Hartman

init/main.c: extract early boot entropy from the passed cmdline

2022-08-25T09:09:22Z

commit 33d72f3822d7ff8a9e45bd7413c811085cb87aa5 upstream. Feed the boot command-line as to the /dev/random entropy pool Existing Android bootloaders usually pass data which may not be known by an external attacker on the kernel command-line. It may also be the case on other embedded systems. Sample command-line from a Google Pixel running CopperheadOS.... console=ttyHSL0,115200,n8 androidboot.console=ttyHSL0 androidboot.hardware=sailfish user_debug=31 ehci-hcd.park=3 lpm_levels.sleep_disabled=1 cma=32M@0-0xffffffff buildvariant=user veritykeyid=id:dfcb9db0089e5b3b4090a592415c28e1cb4545ab androidboot.bootdevice=624000.ufshc androidboot.verifiedbootstate=yellow androidboot.veritymode=enforcing androidboot.keymaster=1 androidboot.serialno=FA6CE0305299 androidboot.baseband=msm mdss_mdp.panel=1:dsi:0:qcom,mdss_dsi_samsung_ea8064tg_1080p_cmd:1:none:cfg:single_dsi androidboot.slot_suffix=_b fpsimd.fpsimd_settings=0 app_setting.use_app_setting=0 kernelflag=0x00000000 debugflag=0x00000000 androidboot.hardware.revision=PVT radioflag=0x00000000 radioflagex1=0x00000000 radioflagex2=0x00000000 cpumask=0x00000000 androidboot.hardware.ddr=4096MB,Hynix,LPDDR4 androidboot.ddrinfo=00000006 androidboot.ddrsize=4GB androidboot.hardware.color=GRA00 androidboot.hardware.ufs=32GB,Samsung androidboot.msm.hw_ver_id=268824801 androidboot.qf.st=2 androidboot.cid=11111111 androidboot.mid=G-2PW4100 androidboot.bootloader=8996-012001-1704121145 androidboot.oem_unlock_support=1 androidboot.fp_src=1 androidboot.htc.hrdump=detected androidboot.ramdump.opt=mem@2g:2g,mem@4g:2g androidboot.bootreason=reboot androidboot.ramdump_enable=0 ro root=/dev/dm-0 dm="system none ro,0 1 android-verity /dev/sda34" rootwait skip_initramfs init=/init androidboot.wificountrycode=US androidboot.boottime=1BLL:85,1BLE:669,2BLL:0,2BLE:1777,SW:6,KL:8136 Among other things, it contains a value unique to the device (androidboot.serialno=FA6CE0305299), unique to the OS builds for the device variant (veritykeyid=id:dfcb9db0089e5b3b4090a592415c28e1cb4545ab) and timings from the bootloader stages in milliseconds (androidboot.boottime=1BLL:85,1BLE:669,2BLL:0,2BLE:1777,SW:6,KL:8136). [tytso@mit.edu: changelog tweak] [labbott@redhat.com: line-wrapped command line] Link: http://lkml.kernel.org/r/20170816231458.2299-3-labbott@redhat.com Signed-off-by: Daniel Micay Signed-off-by: Laura Abbott Acked-by: Kees Cook Cc: "Theodore Ts'o" Cc: Laura Abbott Cc: Nick Kralevich Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Hans-Christian Noren Egtvedt Signed-off-by: Greg Kroah-Hartman

init: move stack canary initialization after setup_arch

2022-08-25T09:09:22Z

commit 121388a31362b0d3176dc1190ac8064b98a61b20 upstream. Patch series "Command line randomness", v3. A series to add the kernel command line as a source of randomness. This patch (of 2): Stack canary intialization involves getting a random number. Getting this random number may involve accessing caches or other architectural specific features which are not available until after the architecture is setup. Move the stack canary initialization later to accommodate this. Link: http://lkml.kernel.org/r/20170816231458.2299-2-labbott@redhat.com Signed-off-by: Laura Abbott Signed-off-by: Laura Abbott Acked-by: Kees Cook Cc: "Theodore Ts'o" Cc: Daniel Micay Cc: Nick Kralevich Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Hans-Christian Noren Egtvedt Signed-off-by: Greg Kroah-Hartman

init/main: properly align the multi-line comment

2022-08-25T09:09:22Z

commit 1b3b3b49b9961401331a1b496db5bec5c7b41ae6 upstream. Add a tab before it to follow standard practices. Also add the missing full stop '.'. Signed-off-by: Viresh Kumar Signed-off-by: Jiri Kosina Signed-off-by: Hans-Christian Noren Egtvedt Signed-off-by: Greg Kroah-Hartman

init/main: Fix double "the" in comment

2022-08-25T09:09:22Z

commit 6623f1c6150c09ce946c8e27a4c814d64919495b upstream. s/the\ the/the Signed-off-by: Viresh Kumar Signed-off-by: Jiri Kosina Signed-off-by: Hans-Christian Noren Egtvedt Signed-off-by: Greg Kroah-Hartman

random: handle latent entropy and command line from random_init()

2022-06-25T09:45:15Z

commit 2f14062bb14b0fcfcc21e6dc7d5b5c0d25966164 upstream. Currently, start_kernel() adds latent entropy and the command line to the entropy bool *after* the RNG has been initialized, deferring when it's actually used by things like stack canaries until the next time the pool is seeded. This surely is not intended. Rather than splitting up which entropy gets added where and when between start_kernel() and random_init(), just do everything in random_init(), which should eliminate these kinds of bugs in the future. While we're at it, rename the awkwardly titled "rand_initialize()" to the more standard "random_init()" nomenclature. Reviewed-by: Dominik Brodowski Signed-off-by: Jason A. Donenfeld Signed-off-by: Greg Kroah-Hartman

init: call time_init() before rand_initialize()

2022-06-25T09:45:12Z

commit fe222a6ca2d53c38433cba5d3be62a39099e708e upstream. Currently time_init() is called after rand_initialize(), but rand_initialize() makes use of the timer on various platforms, and sometimes this timer needs to be initialized by time_init() first. In order for random_get_entropy() to not return zero during early boot when it's potentially used as an entropy source, reverse the order of these two calls. The block doing random initialization was right before time_init() before, so changing the order shouldn't have any complicated effects. Cc: Andrew Morton Reviewed-by: Stafford Horne Signed-off-by: Jason A. Donenfeld Signed-off-by: Greg Kroah-Hartman

workqueue: make workqueue available early during boot

2022-06-25T09:45:09Z

commit 3347fa0928210d96aaa2bd6cd5a8391d5e630873 upstream. Workqueue is currently initialized in an early init call; however, there are cases where early boot code has to be split and reordered to come after workqueue initialization or the same code path which makes use of workqueues is used both before workqueue initailization and after. The latter cases have to gate workqueue usages with keventd_up() tests, which is nasty and easy to get wrong. Workqueue usages have become widespread and it'd be a lot more convenient if it can be used very early from boot. This patch splits workqueue initialization into two steps. workqueue_init_early() which sets up the basic data structures so that workqueues can be created and work items queued, and workqueue_init() which actually brings up workqueues online and starts executing queued work items. The former step can be done very early during boot once memory allocation, cpumasks and idr are initialized. The latter right after kthreads become available. This allows work item queueing and canceling from very early boot which is what most of these use cases want. * As systemd_wq being initialized doesn't indicate that workqueue is fully online anymore, update keventd_up() to test wq_online instead. The follow-up patches will get rid of all its usages and the function itself. * Flushing doesn't make sense before workqueue is fully initialized. The flush functions trigger WARN and return immediately before fully online. * Work items are never in-flight before fully online. Canceling can always succeed by skipping the flush step. * Some code paths can no longer assume to be called with irq enabled as irq is disabled during early boot. Use irqsave/restore operations instead. v2: Watchdog init, which requires timer to be running, moved from workqueue_init_early() to workqueue_init(). Signed-off-by: Tejun Heo Suggested-by: Linus Torvalds Link: http://lkml.kernel.org/r/CA+55aFx0vPuMuxn00rBSM192n-Du5uxy+4AvKa0SBSOVJeuCGg@mail.gmail.com Signed-off-by: Jason A. Donenfeld Signed-off-by: Greg Kroah-Hartman

random: move rand_initialize() earlier

2022-06-25T09:45:01Z

commit d55535232c3dbde9a523a9d10d68670f5fe5dec3 upstream. Right now rand_initialize() is run as an early_initcall(), but it only depends on timekeeping_init() (for mixing ktime_get_real() into the pools). However, the call to boot_init_stack_canary() for stack canary initialization runs earlier, which triggers a warning at boot: random: get_random_bytes called from start_kernel+0x357/0x548 with crng_init=0 Instead, this moves rand_initialize() to after timekeeping_init(), and moves canary initialization here as well. Note that this warning may still remain for machines that do not have UEFI RNG support (which initializes the RNG pools during setup_arch()), or for x86 machines without RDRAND (or booting without "random.trust=on" or CONFIG_RANDOM_TRUST_CPU=y). Signed-off-by: Kees Cook Signed-off-by: Theodore Ts'o Signed-off-by: Jason A. Donenfeld Signed-off-by: Greg Kroah-Hartman

random: do not ignore early device randomness

2022-06-25T09:44:58Z

commit ee7998c50c2697737c6530431709f77c852bf0d6 upstream. The add_device_randomness() function would ignore incoming bytes if the crng wasn't ready. This additionally makes sure to make an early enough call to add_latent_entropy() to influence the initial stack canary, which is especially important on non-x86 systems where it stays the same through the life of the boot. Link: http://lkml.kernel.org/r/20170626233038.GA48751@beast Signed-off-by: Kees Cook Cc: "Theodore Ts'o" Cc: Arnd Bergmann Cc: Greg Kroah-Hartman Cc: Ingo Molnar Cc: Jessica Yu Cc: Steven Rostedt (VMware) Cc: Viresh Kumar Cc: Tejun Heo Cc: Prarit Bhargava Cc: Lokesh Vutla Cc: Nicholas Piggin Cc: AKASHI Takahiro Signed-off-by: Andrew Morton Signed-off-by: Linus Torvalds Signed-off-by: Jason A. Donenfeld Signed-off-by: Greg Kroah-Hartman