On Mon, Jul 17, 2017 at 12:32 PM, Rob Herring <robh@xxxxxxxxxx> wrote: > On Fri, Jul 14, 2017 at 05:38:36PM -0700, Kees Cook wrote: >> Document then /chosen/kaslr-seed property (and its interaction with the > > s/then/the/ > >> EFI_RNG_PROTOCOL API). > > "dt-bindings: chosen: ..." for the subject. I'll send a v2 with these fixed and the Acks added. >> Signed-off-by: Kees Cook <keescook@xxxxxxxxxxxx> >> --- >> Documentation/devicetree/bindings/chosen.txt | 22 ++++++++++++++++++++-- >> 1 file changed, 20 insertions(+), 2 deletions(-) >> >> diff --git a/Documentation/devicetree/bindings/chosen.txt b/Documentation/devicetree/bindings/chosen.txt >> index dee3f5d9df26..0cdb43b268e5 100644 >> --- a/Documentation/devicetree/bindings/chosen.txt >> +++ b/Documentation/devicetree/bindings/chosen.txt >> @@ -5,9 +5,27 @@ The chosen node does not represent a real device, but serves as a place >> for passing data between firmware and the operating system, like boot >> arguments. Data in the chosen node does not represent the hardware. >> >> +The following properties are recognized: >> >> -stdout-path property >> --------------------- >> + >> +kaslr-seed >> +----------- > > Is there some reason we would not feed this to other things needing > entropy and therefore should have a more generic name? I'll let Ard answer this better than me, but IIRC, he wanted a narrow use. >> + >> +This property is used when booting with CONFIG_RANDOMIZE_BASE to seed >> +the entropy used to randomize the kernel image base address location. It >> +is parsed as a u64 value, e.g. > > Why limit the size to 64-bit and why does it matter how the data is > interpretted? IIRC, u64 is sufficient. (And note I'm just documenting what exists...) >> + >> +/ { >> + chosen { >> + kaslr-seed = <0xfeedbeef 0xc0def00d>; >> + }; >> +}; >> + >> +Note that when booting through EFI when EFI_RNG_PROTOCOL is supported, >> +this value will be overwritten by the EFI stub. > > Isn't this always true? The bootloader will overwrite. Just in the EFI > case, the EFI stub is part of the bootloader from a functional (and not > packaging) standpoint. I thought it best to call this out so that no one could get confused if they wanted to understand how to use kaslr-seed with an EFI system. (i.e. just implement EFI_RNG_PROTOCOL instead.) -Kees -- Kees Cook Pixel Security -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html