Documentation: dt: chosen property for kaslr-seed
PATCH 1/1 Documentation: dt: chosen property for kaslr-seed
Document then /chosen/kaslr-seed property (and its interaction with the EFI_RNG_PROTOCOL API).
--- Documentation/devicetree/bindings/chosen.txt | 22 ++++++++++++++++++++-- 1 file changed, 20 insertions(+), 2 deletions(-)
Documentation/devicetree/bindings/chosen.txt +20 -2
@@ -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 +----------- + +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. + +/ { + 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. + +stdout-path +----------- Device trees may specify the device to be used for boot console output with a stdout-path property under /chosen, as described in the Devicetree
Signature · 10 lines
2.7.4 -- Kees Cook Pixel Security -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
(+ Mark, Will, Catalin)
Quoted 8 lines · Kees Cook
Document then /chosen/kaslr-seed property (and its interaction with the
EFI_RNG_PROTOCOLAPI).Signed-off-by Kees Cook <[email protected]>--- Documentation/devicetree/bindings/chosen.txt | 22 ++++++++++++++++++++-- 1 file changed, 20 insertions(+), 2 deletions(-)
For the textual changes:
*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.
Quoted 38 lines
Documentation/devicetree/bindings/chosen.txt +20
-3@@ -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 +----------- + +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. + +/ { + 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. + +stdout-path +----------- Device trees may specify the device to be used for boot console output with a stdout-path property under /chosen, as described in the Devicetree --2.7.4
Quoted 3 lines
--
Kees Cook
Pixel Security
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 12 lines · Ard Biesheuvel
(+ Mark, Will, Catalin)
Quoted 8 lines · Kees Cook
Document then /chosen/kaslr-seed property (and its interaction with the
EFI_RNG_PROTOCOLAPI).Signed-off-by Kees Cook <[email protected]>--- Documentation/devicetree/bindings/chosen.txt | 22 ++++++++++++++++++++-- 1 file changed, 20 insertions(+), 2 deletions(-)
Quoted 9 lines
For the textual changes:
Acked-by Ard Biesheuvel <[email protected]>*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.
-Kees
Signature · 2 lines
Kees Cook Pixel Security
Quoted 18 lines · Kees Cook
Quoted 16 lines · Ard Biesheuvel
(+ Mark, Will, Catalin)
Quoted 8 lines · Kees Cook
Document then /chosen/kaslr-seed property (and its interaction with the
EFI_RNG_PROTOCOLAPI).Signed-off-by Kees Cook <[email protected]>--- Documentation/devicetree/bindings/chosen.txt | 22 ++++++++++++++++++++-- 1 file changed, 20 insertions(+), 2 deletions(-)For the textual changes:
Acked-by Ard Biesheuvel <[email protected]>
Quoted 9 lines
Quoted 5 lines
*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.
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Mark Rutland
Acked-byQuoted 32 lines · Ard Biesheuvel
Quoted 17 lines · Kees Cook
Quoted 15 lines · Ard Biesheuvel
(+ Mark, Will, Catalin)
Quoted 7 lines · Kees Cook
Document then /chosen/kaslr-seed property (and its interaction with the
EFI_RNG_PROTOCOLAPI).Signed-off-by Kees Cook <[email protected]>--- Documentation/devicetree/bindings/chosen.txt | 22 ++++++++++++++++++++-- 1 file changed, 20 insertions(+), 2 deletions(-)For the textual changes:
Acked-by Ard Biesheuvel <[email protected]>Quoted 7 lines
Quoted 4 lines
*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/randomseed is not possible for this)
Quoted 3 lines
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.
I was under the impression that we'd already assumed other bootloaders could set this, so I don't have a problem promoting this to a defined public interface.
I guess we just need Will and Catalin to agree.
FWIW:
As an aside, we might want to make a split between /chosen properties which are Linux-specific (e.g. this), and those which are somewhat generic (e.g. stdout-path), since other OSs may/should respect those generic ones.
Mark.
Will Deacon
Acked-byQuoted 37 lines · Mark Rutland
Quoted 32 lines · Ard Biesheuvel
Quoted 17 lines · Kees Cook
Quoted 15 lines · Ard Biesheuvel
(+ Mark, Will, Catalin)
Quoted 7 lines · Kees Cook
Document then /chosen/kaslr-seed property (and its interaction with the
EFI_RNG_PROTOCOLAPI).Signed-off-by Kees Cook <[email protected]>--- Documentation/devicetree/bindings/chosen.txt | 22 ++++++++++++++++++++-- 1 file changed, 20 insertions(+), 2 deletions(-)For the textual changes:
Acked-by Ard Biesheuvel <[email protected]>Quoted 7 lines
Quoted 4 lines
*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/randomseed is not possible for this)Quoted 3 lines
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.
Quoted 5 lines
I was under the impression that we'd already assumed other bootloaders could set this, so I don't have a problem promoting this to a defined public interface.
I guess we just need Will and Catalin to agree.
If we expose an undocumented property, then I think it's ABI the moment somebody starts using it, irrespective of whether or not we document it later. For example, if somebody outside of the stub was using this and we changed the ABI in a way that broke things for them, I'd have a hard time defending that.
So Documentation is good, but I don't think it really changes anything wrt ABI guarantees.
(I'm assuming this goes via some DT tree).
Will
Rob Herring
maintainerQuoted 1 line · Kees Cook
Document then /chosen/kaslr-seed property (and its interaction with the
s/then/the/
Quoted 1 line
EFI_RNG_PROTOCOLAPI).
"dt-bindings: chosen: ..." for the subject.
Quoted 11 lines
Signed-off-by Kees Cook <[email protected]>--- Documentation/devicetree/bindings/chosen.txt | 22 ++++++++++++++++++++-- 1 file changed, 20 insertions(+), 2 deletions(-)Documentation/devicetree/bindings/chosen.txt +0
-0
Documentation/devicetree/bindings/chosen.txt The chosen node does not represent a real device, but serves as a place · line 12
Quoted 10 lines
Documentation/devicetree/bindings/chosen.txt +4
-2@@ -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?
Documentation/devicetree/bindings/chosen.txt The chosen node does not represent a real device, but serves as a place · line 16
Quoted 4 lines
Documentation/devicetree/bindings/chosen.txt +4
-0+ +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?
Documentation/devicetree/bindings/chosen.txt The chosen node does not represent a real device, but serves as a place · line 25
Quoted 9 lines
Documentation/devicetree/bindings/chosen.txt +9
-0+ +/ { + 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.
Rob
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 8 lines · Rob Herring
Quoted 1 line · Kees Cook
Document then /chosen/kaslr-seed property (and its interaction with the
s/then/the/
Quoted 1 line
EFI_RNG_PROTOCOLAPI)."dt-bindings: chosen: ..." for the subject.
I'll send a v2 with these fixed and the Acks added.
Quoted 15 lines
Quoted 15 lines
Signed-off-by Kees Cook <[email protected]>--- Documentation/devicetree/bindings/chosen.txt | 22 ++++++++++++++++++++-- 1 file changed, 20 insertions(+), 2 deletions(-)Documentation/devicetree/bindings/chosen.txt +1
-0@@ -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:
Quoted 8 lines
Documentation/devicetree/bindings/chosen.txt The chosen node does not represent a real device, but serves as a place · line 12
Quoted 5 lines
Documentation/devicetree/bindings/chosen.txt +3
-2-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.
Quoted 7 lines
Documentation/devicetree/bindings/chosen.txt The chosen node does not represent a real device, but serves as a place · line 16
Quoted 4 lines
Documentation/devicetree/bindings/chosen.txt +4
-0+ +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...)
Quoted 5 lines
Quoted 5 lines
Documentation/devicetree/bindings/chosen.txt +5
-0+ +/ { + chosen { + kaslr-seed = <0xfeedbeef 0xc0def00d>; + };
Quoted 8 lines
Documentation/devicetree/bindings/chosen.txt The chosen node does not represent a real device, but serves as a place · line 25
Quoted 4 lines
Documentation/devicetree/bindings/chosen.txt +4
-0+}; + +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
Signature · 6 lines
Kees Cook Pixel Security -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 36 lines · Kees Cook
Quoted 8 lines · Rob Herring
Quoted 1 line · Kees Cook
Document then /chosen/kaslr-seed property (and its interaction with the
s/then/the/
Quoted 1 line
EFI_RNG_PROTOCOLAPI)."dt-bindings: chosen: ..." for the subject.
I'll send a v2 with these fixed and the Acks added.
Quoted 15 lines
Quoted 15 lines
Signed-off-by Kees Cook <[email protected]>--- Documentation/devicetree/bindings/chosen.txt | 22 ++++++++++++++++++++-- 1 file changed, 20 insertions(+), 2 deletions(-)Documentation/devicetree/bindings/chosen.txt +1
-0@@ -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:Quoted 8 lines
Documentation/devicetree/bindings/chosen.txt The chosen node does not represent a real device, but serves as a place · line 12
Quoted 5 lines
Documentation/devicetree/bindings/chosen.txt +3
-2-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?
Quoted 2 lines
I'll let Ard answer this better than me, but IIRC, he wanted a narrow use.
The reason is that the seed is not used to feed a DRBG (because it is way to early for that when we lay out the VA space), but different slices of the u64 are used for randomizing different parts of the address space, i.e., the top 16 bits are used to randomize the linear region, bits 48 - 21 for the kernel itself, and the bits below that for the module region. (The virtual kernel offset is randomized further by the physical placement modulo 2 MB, but this is done by the stub, which calls EFI_RNG_PROTOCOL itself so it does not use /chosen/kaslr-seed)
This means any use of this seed beyond its intended purpose may leak information.
For UEFI systems, we do pass a random seed via a UEFI configuration table, but this is deliberately kept separate (and uses a UEFI specific interface, which seemed more appropriate)
Quoted 10 lines
Quoted 7 lines
Documentation/devicetree/bindings/chosen.txt The chosen node does not represent a real device, but serves as a place · line 16
Quoted 4 lines
Documentation/devicetree/bindings/chosen.txt +4
-0+ +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...)
See above. Seeding a DRBG typically requires more than that, but for KASLR it is sufficient.
Quoted 14 lines
Quoted 5 lines
Quoted 5 lines
Documentation/devicetree/bindings/chosen.txt +5
-0+ +/ { + chosen { + kaslr-seed = <0xfeedbeef 0xc0def00d>; + };Quoted 8 lines
Documentation/devicetree/bindings/chosen.txt The chosen node does not represent a real device, but serves as a place · line 25
Quoted 4 lines
Documentation/devicetree/bindings/chosen.txt +4
-0+}; + +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.
Quoted 4 lines
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_PROTOCOLinstead.)
Well, I guess the point being made is that setting this property from UEFI (or u-boot in EFI mode) is pointless is EFI_RNG_PROTOCOL is implemented as well.
Rob Herring
maintainerQuoted 50 lines · Ard Biesheuvel
Quoted 36 lines · Kees Cook
Quoted 8 lines · Rob Herring
Quoted 1 line · Kees Cook
Document then /chosen/kaslr-seed property (and its interaction with the
s/then/the/
Quoted 1 line
EFI_RNG_PROTOCOLAPI)."dt-bindings: chosen: ..." for the subject.
I'll send a v2 with these fixed and the Acks added.
Quoted 15 lines
Quoted 15 lines
Signed-off-by Kees Cook <[email protected]>--- Documentation/devicetree/bindings/chosen.txt | 22 ++++++++++++++++++++-- 1 file changed, 20 insertions(+), 2 deletions(-)Documentation/devicetree/bindings/chosen.txt +1
-0@@ -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:Quoted 8 lines
Documentation/devicetree/bindings/chosen.txt The chosen node does not represent a real device, but serves as a place · line 12
Quoted 5 lines
Documentation/devicetree/bindings/chosen.txt +3
-2-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?
Quoted 2 lines
I'll let Ard answer this better than me, but IIRC, he wanted a narrow use.
The reason is that the seed is not used to feed a DRBG (because it is way to early for that when we lay out the VA space), but different slices of the u64 are used for randomizing different parts of the address space, i.e., the top 16 bits are used to randomize the linear region, bits 48 - 21 for the kernel itself, and the bits below that for the module region. (The virtual kernel offset is randomized further by the physical placement modulo 2 MB, but this is done by the stub, which calls
EFI_RNG_PROTOCOLitself so it does not use /chosen/kaslr-seed)
Quoted 2 lines
This means any use of this seed beyond its intended purpose may leak information.
Is having this value in /proc/device-tree/chosen/kaslr-seed a leak? Should the kernel remove it?
Quoted 3 lines
For UEFI systems, we do pass a random seed via a UEFI configuration table, but this is deliberately kept separate (and uses a UEFI specific interface, which seemed more appropriate)
So if we wanted a seed for non-UEFI systems, we should define a separate property?
Quoted 27 lines
Quoted 9 lines
Quoted 6 lines
Documentation/devicetree/bindings/chosen.txt The chosen node does not represent a real device, but serves as a place · line 16
Quoted 3 lines
Documentation/devicetree/bindings/chosen.txt +3
-0+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...)
See above. Seeding a DRBG typically requires more than that, but for KASLR it is sufficient.
Quoted 14 lines
Quoted 13 lines
Documentation/devicetree/bindings/chosen.txt The chosen node does not represent a real device, but serves as a place · line 25
Quoted 9 lines
Documentation/devicetree/bindings/chosen.txt +9
-0+ +/ { + 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.
Quoted 8 lines
Quoted 4 lines
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_PROTOCOLinstead.)Well, I guess the point being made is that setting this property from UEFI (or u-boot in EFI mode) is pointless is
EFI_RNG_PROTOCOLis implemented as well.
Okay.
Rob
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 51 lines · Rob Herring
Quoted 50 lines · Ard Biesheuvel
Quoted 36 lines · Kees Cook
Quoted 8 lines · Rob Herring
Quoted 1 line · Kees Cook
Document then /chosen/kaslr-seed property (and its interaction with the
s/then/the/
Quoted 1 line
EFI_RNG_PROTOCOLAPI)."dt-bindings: chosen: ..." for the subject.
I'll send a v2 with these fixed and the Acks added.
Quoted 15 lines
Quoted 15 lines
Signed-off-by Kees Cook <[email protected]>--- Documentation/devicetree/bindings/chosen.txt | 22 ++++++++++++++++++++-- 1 file changed, 20 insertions(+), 2 deletions(-)Documentation/devicetree/bindings/chosen.txt +1
-0@@ -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:Quoted 8 lines
Documentation/devicetree/bindings/chosen.txt The chosen node does not represent a real device, but serves as a place · line 12
Quoted 5 lines
Documentation/devicetree/bindings/chosen.txt +3
-2-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?
Quoted 2 lines
I'll let Ard answer this better than me, but IIRC, he wanted a narrow use.
The reason is that the seed is not used to feed a DRBG (because it is way to early for that when we lay out the VA space), but different slices of the u64 are used for randomizing different parts of the address space, i.e., the top 16 bits are used to randomize the linear region, bits 48 - 21 for the kernel itself, and the bits below that for the module region. (The virtual kernel offset is randomized further by the physical placement modulo 2 MB, but this is done by the stub, which calls
EFI_RNG_PROTOCOLitself so it does not use /chosen/kaslr-seed)
Quoted 4 lines
Quoted 2 lines
This means any use of this seed beyond its intended purpose may leak information.
Is having this value in
/proc/device-tree/chosen/kaslr-seeda leak?
Yes
Quoted 2 lines
Should the kernel remove it?
It already does.
Quoted 7 lines
Quoted 3 lines
For UEFI systems, we do pass a random seed via a UEFI configuration table, but this is deliberately kept separate (and uses a UEFI specific interface, which seemed more appropriate)
So if we wanted a seed for non-UEFI systems, we should define a separate property?
Yes. This was being discussed a while ago, though, and IIRC the preferred method was to pass a physical memory address containing the seed instead, since it would be compatible with bootloaders that are not capable of manipulating the DT
Some of the discussion here:
https://patchwork.kernel.org/patch/9197865/
Quoted 39 lines
Quoted 27 lines
Quoted 9 lines
Quoted 6 lines
Documentation/devicetree/bindings/chosen.txt The chosen node does not represent a real device, but serves as a place · line 16
Quoted 3 lines
Documentation/devicetree/bindings/chosen.txt +3
-0+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...)
See above. Seeding a DRBG typically requires more than that, but for KASLR it is sufficient.
Quoted 14 lines
Quoted 13 lines
Documentation/devicetree/bindings/chosen.txt The chosen node does not represent a real device, but serves as a place · line 25
Quoted 9 lines
Documentation/devicetree/bindings/chosen.txt +9
-0+ +/ { + 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.
Quoted 8 lines
Quoted 4 lines
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_PROTOCOLinstead.)Well, I guess the point being made is that setting this property from UEFI (or u-boot in EFI mode) is pointless is
EFI_RNG_PROTOCOLis implemented as well.Okay.
Rob