Messages in this thread | | | From | Ard Biesheuvel <> | Date | Sun, 16 Jul 2017 17:42:25 +0100 | Subject | Re: [PATCH] Documentation: dt: chosen property for kaslr-seed |
| |
On 16 July 2017 at 03:13, Kees Cook <keescook@chromium.org> wrote: > On Sat, Jul 15, 2017 at 5:42 AM, Ard Biesheuvel > <ard.biesheuvel@linaro.org> wrote: >> (+ Mark, Will, Catalin) >> >> On 15 July 2017 at 01:38, Kees Cook <keescook@chromium.org> wrote: >>> Document then /chosen/kaslr-seed property (and its interaction with the >>> EFI_RNG_PROTOCOL API). >>> >>> Signed-off-by: Kees Cook <keescook@chromium.org> >>> --- >>> Documentation/devicetree/bindings/chosen.txt | 22 ++++++++++++++++++++-- >>> 1 file changed, 20 insertions(+), 2 deletions(-) >>> >> >> For the textual changes: >> >> Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org> >> >> *However*, documenting the /chosen/kaslr-seed property promotes it >> from a stub<->kernel private interface to an external ABI between the >> kernel and the bootloader, and we need to reach agreement on whether >> doing so is desirable first IMHO. >> > > Oh! I thought that was the point (having a bootloader provide kaslr > entropy). And that in the EFI case, it was the stub doing it. >
It was the opposite, actually, The /chosen node is the most appropriate way for the EFI stub to communicate a seed value to the kernel proper, given how it is needed extremely early in the boot. (Using UEFI config tables like we do for the /dev/random seed is not possible for this)
So as a side effect, other bootloaders can use the same mechanism. I'm fine with that, but it needs to be an explicit decision by the maintainers imo.
| |