lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date:   Fri, 10 May 2019 21:28:35 -0700
From:   Stephen Boyd <>
To:     Hsin-Yi Wang <>,
        Rasmus Villemoes <>,
        Rob Herring <>
        Mark Rutland <>,
        Catalin Marinas <>,
        Will Deacon <>,
        Frank Rowand <>,
        Andrew Morton <>,
        Mike Rapoport <>,
        Michal Hocko <>,
        Ard Biesheuvel <>,
        James Morse <>,
        Andrew Murray <>,,
        "" <>,
        Architecture Mailman List <>,
        Kees Cook <>
Subject: Re: [PATCH] arm64: add support for rng-seed

Quoting Rasmus Villemoes (2019-05-09 23:14:00)
> So, why not just have the bootloader add whatever entropy it has via the
> commandline, which already gets mixed in? That requires no kernel
> changes, and works for all architectures.
> If anything, perhaps instead of just adding gobbledygook=abc123, make an
> official command line parameter (there was talk about this at some
> point), and have the kernel overwrite the value with xxx so it's not
> visible in /proc/cmdline.

Why is using the commandline desired? Just for ease of implementation
and cross-architecture support because we already mix in the

The kernel commandline is limited in size so we would waste around
64-bytes of the buffer to get a random chunk of data from the bootloader
into the kernel instead of allowing more parameters. Or if we wanted a
large chunk of random bytes then we would start running into the length
limit. Given that EFI based systems already have a way to inject more
randomness into the kernel's RNG very early by means of an RNG seed EFI
protocol it looks irrelevant to want to be cross-architecture in this
way because EFI platforms wouldn't use it. 

If DT based systems can all get support for this in the generic DT code
then we're able to make things work on both EFI and DT platforms with a
little extra __init code while keeping things away from the commandline.
That sounds like a win to me because the commandline is limited in size
and meant to pass things like parameters and flags to the kernel, not
raw data like seeds and binary gook.

Powered by blists - more mailing lists