Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1713394 > unrolled thread

[PATCHv2 2/2] extract early boot entropy from the passed cmdline

Started byLaura Abbott <labbott@redhat.com>
First post2017-08-17 00:50 +0200
Last post2017-08-17 07:00 +0200
Articles 4 — 4 participants

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  [PATCHv2 2/2] extract early boot entropy from the passed cmdline Laura Abbott <labbott@redhat.com> - 2017-08-17 00:50 +0200
    Re: [kernel-hardening] [PATCHv2 2/2] extract early boot entropy from  the passed cmdline Kees Cook <keescook@chromium.org> - 2017-08-17 07:00 +0200
      Re: [kernel-hardening] [PATCHv2 2/2] extract early boot entropy  from the passed cmdline Daniel Micay <danielmicay@gmail.com> - 2017-08-17 07:20 +0200
    Re: [kernel-hardening] [PATCHv2 2/2] extract early boot entropy from  the passed cmdline Nick Kralevich <nnk@google.com> - 2017-08-17 07:00 +0200

#1713394 — [PATCHv2 2/2] extract early boot entropy from the passed cmdline

FromLaura Abbott <labbott@redhat.com>
Date2017-08-17 00:50 +0200
Subject[PATCHv2 2/2] extract early boot entropy from the passed cmdline
Message-ID<uffip-4yt-5@gated-at.bofh.it>
From: Daniel Micay <danielmicay@gmail.com>

Existing Android bootloaders usually pass data useful as early entropy
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).

Signed-off-by: Daniel Micay <danielmicay@gmail.com>
[labbott: Line-wrapped command line]
Signed-off-by: Laura Abbott <labbott@redhat.com>
---
 init/main.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/init/main.c b/init/main.c
index 21d599eaad06..cb051aec46ef 100644
--- a/init/main.c
+++ b/init/main.c
@@ -533,6 +533,7 @@ asmlinkage __visible void __init start_kernel(void)
 	 */
 	add_latent_entropy();
 	boot_init_stack_canary();
+	add_device_randomness(command_line, strlen(command_line));
 	mm_init_cpumask(&init_mm);
 	setup_command_line(command_line);
 	setup_nr_cpu_ids();
-- 
2.13.0

[toc] | [next] | [standalone]


#1713540 — Re: [kernel-hardening] [PATCHv2 2/2] extract early boot entropy from the passed cmdline

FromKees Cook <keescook@chromium.org>
Date2017-08-17 07:00 +0200
SubjectRe: [kernel-hardening] [PATCHv2 2/2] extract early boot entropy from the passed cmdline
Message-ID<ufl4t-8gG-1@gated-at.bofh.it>
In reply to#1713394
On Wed, Aug 16, 2017 at 9:56 PM, Nick Kralevich <nnk@google.com> wrote:
> On Wed, Aug 16, 2017 at 3:46 PM, Laura Abbott <labbott@redhat.com> wrote:
>> From: Daniel Micay <danielmicay@gmail.com>
>>
>> Existing Android bootloaders usually pass data useful as early entropy
>> on the kernel command-line. It may also be the case on other embedded
>> systems. Sample command-line from a Google Pixel running CopperheadOS:
>>
>
> Why is it better to put this into the kernel, rather than just rely on
> the existing userspace functionality which does exactly the same
> thing? This is what Android already does today:
> https://android-review.googlesource.com/198113

That's too late for setting up the kernel stack canary, among other
things. The kernel will also be generating some early secrets for slab
cache canaries, etc. That all needs to happen well before init is
started.

-Kees

-- 
Kees Cook
Pixel Security

[toc] | [prev] | [next] | [standalone]


#1713547 — Re: [kernel-hardening] [PATCHv2 2/2] extract early boot entropy from the passed cmdline

FromDaniel Micay <danielmicay@gmail.com>
Date2017-08-17 07:20 +0200
SubjectRe: [kernel-hardening] [PATCHv2 2/2] extract early boot entropy from the passed cmdline
Message-ID<uflnP-es-7@gated-at.bofh.it>
In reply to#1713540
On Wed, 2017-08-16 at 21:58 -0700, Kees Cook wrote:
> On Wed, Aug 16, 2017 at 9:56 PM, Nick Kralevich <nnk@google.com>
> wrote:
> > On Wed, Aug 16, 2017 at 3:46 PM, Laura Abbott <labbott@redhat.com>
> > wrote:
> > > From: Daniel Micay <danielmicay@gmail.com>
> > > 
> > > Existing Android bootloaders usually pass data useful as early
> > > entropy
> > > on the kernel command-line. It may also be the case on other
> > > embedded
> > > systems. Sample command-line from a Google Pixel running
> > > CopperheadOS:
> > > 
> > 
> > Why is it better to put this into the kernel, rather than just rely
> > on
> > the existing userspace functionality which does exactly the same
> > thing? This is what Android already does today:
> > https://android-review.googlesource.com/198113
> 
> That's too late for setting up the kernel stack canary, among other
> things. The kernel will also be generating some early secrets for slab
> cache canaries, etc. That all needs to happen well before init is
> started.
> 
> -Kees
> 

It's also unfortunately the kernel's global stack canary for the entire
boot since unlike x86 there aren't per-task canaries. GCC / Clang access
it via a segment register on x86 vs. a global on other architectures.

In theory it could be task-local elsewhere but doing it efficiently
would imply reserving a register to store the random value. I think that
may actually end up helping performance more than it hurts by not
needing to read the global stack canary value from cache repeatedly. If
stack canaries were augmented into something more (XOR in the retaddr
and offer the option of more coverage than STRONG) it would be more
important.

[toc] | [prev] | [next] | [standalone]


#1713541 — Re: [kernel-hardening] [PATCHv2 2/2] extract early boot entropy from the passed cmdline

FromNick Kralevich <nnk@google.com>
Date2017-08-17 07:00 +0200
SubjectRe: [kernel-hardening] [PATCHv2 2/2] extract early boot entropy from the passed cmdline
Message-ID<ufl4t-8gG-3@gated-at.bofh.it>
In reply to#1713394
On Wed, Aug 16, 2017 at 3:46 PM, Laura Abbott <labbott@redhat.com> wrote:
> From: Daniel Micay <danielmicay@gmail.com>
>
> Existing Android bootloaders usually pass data useful as early entropy
> on the kernel command-line. It may also be the case on other embedded
> systems. Sample command-line from a Google Pixel running CopperheadOS:
>

Why is it better to put this into the kernel, rather than just rely on
the existing userspace functionality which does exactly the same
thing? This is what Android already does today:
https://android-review.googlesource.com/198113

-- Nick

[toc] | [prev] | [standalone]


Back to top | Article view | linux.kernel


csiph-web