| Message ID | 56D030A4.5050205@nxp.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
On 26 February 2016 at 12:01, Laurentiu Tudor <laurentiu.tudor@nxp.com> wrote: > In case the bootloader doesn't provide randomness > (through device tree or by uefi protocol) generate > a pseudo-random seed based on the timer counter. > People might find this "week rng" approach convenient > as it gets rid of the bootloader dependency. > > The patch tries to mimic the x86's rdtsc > based implementation authored by Kees Cook. > > Signed-off-by: Laurentiu Tudor <laurentiu.tudor@nxp.com> > Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> > Cc: Kees Cook <keescook@chromium.org> Hi Laurentiu, I appreciate the interest in this work, but to be honest, I don't like this at all. I went out of my way to ensure that a) the kernel itself does not take part in generating the random bits, and b) the random bits are used in such a way that there is no correlation between the randomization of the core kernel, the module region and the linear region if there is no correlation between the random bits. The limited entropy of the cycle counter at early boot defeats that, and even worse, it will not encourage platform vendors to implement this properly in their boot code, given that it will appear to work, and the only thing more dangerous than no security is a false sense of security imo. What I would ack, for development purposes, is something similar to what Mark Rutland implemented for randomizing TEXT_OFFSET, so that developers get to exercise this code even if their boot environment does not provide any entropy. Anything beyond that is a nack as far as I am concerned. One other remark below
On Fri, Feb 26, 2016 at 12:51:25PM +0100, Ard Biesheuvel wrote: > On 26 February 2016 at 12:01, Laurentiu Tudor <laurentiu.tudor@nxp.com> wrote: > > In case the bootloader doesn't provide randomness > > (through device tree or by uefi protocol) generate > > a pseudo-random seed based on the timer counter. > > People might find this "week rng" approach convenient > > as it gets rid of the bootloader dependency. > > > > The patch tries to mimic the x86's rdtsc > > based implementation authored by Kees Cook. > > > > Signed-off-by: Laurentiu Tudor <laurentiu.tudor@nxp.com> > > Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> > > Cc: Kees Cook <keescook@chromium.org> > > Hi Laurentiu, > > I appreciate the interest in this work, but to be honest, I don't like > this at all. I went out of my way to ensure that > a) the kernel itself does not take part in generating the random bits, and > b) the random bits are used in such a way that there is no correlation > between the randomization of the core kernel, the module region and > the linear region if there is no correlation between the random bits. > > The limited entropy of the cycle counter at early boot defeats that, > and even worse, it will not encourage platform vendors to implement > this properly in their boot code, given that it will appear to work, > and the only thing more dangerous than no security is a false sense of > security imo. I agree that a false sense of security is a worry here. Either way, I think we need numbers. It's non-obvious how much entropy we can acquire through counters or other means at early boot time. Has anyone done an analysis of environmental entropy available (through any means) at early boot, VM vs native? It's also not obvious that vendors will correctly implement the EFI RNG protocol; depending on the above we may want to mix in additional entropy regardless. > What I would ack, for development purposes, is something similar to > what Mark Rutland implemented for randomizing TEXT_OFFSET, so that > developers get to exercise this code even if their boot environment > does not provide any entropy. Anything beyond that is a nack as far as > I am concerned. FWIW, I would not like to see that approach. I can easily see a build-time constant KASLR seed being abused to give a false sense of security. Having a bootloader or hypervisor provide different random seeds to the same Image gives you a much better turnaround time for testing regardless (vs rebuilding, copying, etc). The TEXT_OFFSET fuzzing was for fuzzing the bootloader, which is a bit different to fuzzing the kernel itself. Mark.
On 26 February 2016 at 13:18, Mark Rutland <mark.rutland@arm.com> wrote: > On Fri, Feb 26, 2016 at 12:51:25PM +0100, Ard Biesheuvel wrote: >> On 26 February 2016 at 12:01, Laurentiu Tudor <laurentiu.tudor@nxp.com> wrote: >> > In case the bootloader doesn't provide randomness >> > (through device tree or by uefi protocol) generate >> > a pseudo-random seed based on the timer counter. >> > People might find this "week rng" approach convenient >> > as it gets rid of the bootloader dependency. >> > >> > The patch tries to mimic the x86's rdtsc >> > based implementation authored by Kees Cook. >> > >> > Signed-off-by: Laurentiu Tudor <laurentiu.tudor@nxp.com> >> > Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> >> > Cc: Kees Cook <keescook@chromium.org> >> >> Hi Laurentiu, >> >> I appreciate the interest in this work, but to be honest, I don't like >> this at all. I went out of my way to ensure that >> a) the kernel itself does not take part in generating the random bits, and >> b) the random bits are used in such a way that there is no correlation >> between the randomization of the core kernel, the module region and >> the linear region if there is no correlation between the random bits. >> >> The limited entropy of the cycle counter at early boot defeats that, >> and even worse, it will not encourage platform vendors to implement >> this properly in their boot code, given that it will appear to work, >> and the only thing more dangerous than no security is a false sense of >> security imo. > > I agree that a false sense of security is a worry here. > > Either way, I think we need numbers. It's non-obvious how much entropy > we can acquire through counters or other means at early boot time. > > Has anyone done an analysis of environmental entropy available (through > any means) at early boot, VM vs native? > Define 'environmental'. The only architected thing you can rely on is the timer, which really does not hold a lot of entropy on modern solid state platforms. I don't have the numbers, but I do have the experience to back this up, unfortunately (at my former employer). You could argue that KASLR does not require strong entropy like key generation, but I would prefer to simply steer clear of that entire debate. The bootloader simply needs to do the best job it can, either based on some peripheral that the kernel has no awareness of this early in the boot, or perhaps by other means if it doesn't (which could include storing a random seed in the file system, or even in a EFI variable). Punting it to the kernel is really the last resort. > It's also not obvious that vendors will correctly implement the EFI RNG > protocol; depending on the above we may want to mix in additional entropy > regardless. > True, but that is not the point. The main risk I see is that vendors will not bother at all once the digits start to look random to the human eye. >> What I would ack, for development purposes, is something similar to >> what Mark Rutland implemented for randomizing TEXT_OFFSET, so that >> developers get to exercise this code even if their boot environment >> does not provide any entropy. Anything beyond that is a nack as far as >> I am concerned. > > FWIW, I would not like to see that approach. I can easily see a build-time > constant KASLR seed being abused to give a false sense of security. Having a > bootloader or hypervisor provide different random seeds to the same Image gives > you a much better turnaround time for testing regardless (vs rebuilding, > copying, etc). > If it would be *instead* of the ordinary handling, with a big fat blurb saying that KASLR is disabled, I would not mind. > The TEXT_OFFSET fuzzing was for fuzzing the bootloader, which is a bit > different to fuzzing the kernel itself. > > Mark.
On Fri, Feb 26, 2016 at 4:37 AM, Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote: > On 26 February 2016 at 13:18, Mark Rutland <mark.rutland@arm.com> wrote: >> On Fri, Feb 26, 2016 at 12:51:25PM +0100, Ard Biesheuvel wrote: >>> On 26 February 2016 at 12:01, Laurentiu Tudor <laurentiu.tudor@nxp.com> wrote: >>> > In case the bootloader doesn't provide randomness >>> > (through device tree or by uefi protocol) generate >>> > a pseudo-random seed based on the timer counter. >>> > People might find this "week rng" approach convenient >>> > as it gets rid of the bootloader dependency. >>> > >>> > The patch tries to mimic the x86's rdtsc >>> > based implementation authored by Kees Cook. >>> > >>> > Signed-off-by: Laurentiu Tudor <laurentiu.tudor@nxp.com> >>> > Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> >>> > Cc: Kees Cook <keescook@chromium.org> >>> >>> Hi Laurentiu, >>> >>> I appreciate the interest in this work, but to be honest, I don't like >>> this at all. I went out of my way to ensure that >>> a) the kernel itself does not take part in generating the random bits, and >>> b) the random bits are used in such a way that there is no correlation >>> between the randomization of the core kernel, the module region and >>> the linear region if there is no correlation between the random bits. >>> >>> The limited entropy of the cycle counter at early boot defeats that, >>> and even worse, it will not encourage platform vendors to implement >>> this properly in their boot code, given that it will appear to work, >>> and the only thing more dangerous than no security is a false sense of >>> security imo. >> >> I agree that a false sense of security is a worry here. >> >> Either way, I think we need numbers. It's non-obvious how much entropy >> we can acquire through counters or other means at early boot time. >> >> Has anyone done an analysis of environmental entropy available (through >> any means) at early boot, VM vs native? >> > > Define 'environmental'. The only architected thing you can rely on is > the timer, which really does not hold a lot of entropy on modern solid > state platforms. I don't have the numbers, but I do have the > experience to back this up, unfortunately (at my former employer). > > You could argue that KASLR does not require strong entropy like key > generation, but I would prefer to simply steer clear of that entire > debate. The bootloader simply needs to do the best job it can, either > based on some peripheral that the kernel has no awareness of this > early in the boot, or perhaps by other means if it doesn't (which > could include storing a random seed in the file system, or even in a > EFI variable). Punting it to the kernel is really the last resort. > >> It's also not obvious that vendors will correctly implement the EFI RNG >> protocol; depending on the above we may want to mix in additional entropy >> regardless. >> > > True, but that is not the point. The main risk I see is that vendors > will not bother at all once the digits start to look random to the > human eye. Surely there may be RNG sources that will come along in time that the kernel can add to the entropy? I worry about boot loaders doing a terrible job of finding a good RNG... -Kees > >>> What I would ack, for development purposes, is something similar to >>> what Mark Rutland implemented for randomizing TEXT_OFFSET, so that >>> developers get to exercise this code even if their boot environment >>> does not provide any entropy. Anything beyond that is a nack as far as >>> I am concerned. >> >> FWIW, I would not like to see that approach. I can easily see a build-time >> constant KASLR seed being abused to give a false sense of security. Having a >> bootloader or hypervisor provide different random seeds to the same Image gives >> you a much better turnaround time for testing regardless (vs rebuilding, >> copying, etc). >> > > If it would be *instead* of the ordinary handling, with a big fat > blurb saying that KASLR is disabled, I would not mind. > >> The TEXT_OFFSET fuzzing was for fuzzing the bootloader, which is a bit >> different to fuzzing the kernel itself. >> >> Mark.
On 26 February 2016 at 19:56, Kees Cook <keescook@chromium.org> wrote: > On Fri, Feb 26, 2016 at 4:37 AM, Ard Biesheuvel > <ard.biesheuvel@linaro.org> wrote: >> On 26 February 2016 at 13:18, Mark Rutland <mark.rutland@arm.com> wrote: >>> On Fri, Feb 26, 2016 at 12:51:25PM +0100, Ard Biesheuvel wrote: >>>> On 26 February 2016 at 12:01, Laurentiu Tudor <laurentiu.tudor@nxp.com> wrote: >>>> > In case the bootloader doesn't provide randomness >>>> > (through device tree or by uefi protocol) generate >>>> > a pseudo-random seed based on the timer counter. >>>> > People might find this "week rng" approach convenient >>>> > as it gets rid of the bootloader dependency. >>>> > >>>> > The patch tries to mimic the x86's rdtsc >>>> > based implementation authored by Kees Cook. >>>> > >>>> > Signed-off-by: Laurentiu Tudor <laurentiu.tudor@nxp.com> >>>> > Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> >>>> > Cc: Kees Cook <keescook@chromium.org> >>>> >>>> Hi Laurentiu, >>>> >>>> I appreciate the interest in this work, but to be honest, I don't like >>>> this at all. I went out of my way to ensure that >>>> a) the kernel itself does not take part in generating the random bits, and >>>> b) the random bits are used in such a way that there is no correlation >>>> between the randomization of the core kernel, the module region and >>>> the linear region if there is no correlation between the random bits. >>>> >>>> The limited entropy of the cycle counter at early boot defeats that, >>>> and even worse, it will not encourage platform vendors to implement >>>> this properly in their boot code, given that it will appear to work, >>>> and the only thing more dangerous than no security is a false sense of >>>> security imo. >>> >>> I agree that a false sense of security is a worry here. >>> >>> Either way, I think we need numbers. It's non-obvious how much entropy >>> we can acquire through counters or other means at early boot time. >>> >>> Has anyone done an analysis of environmental entropy available (through >>> any means) at early boot, VM vs native? >>> >> >> Define 'environmental'. The only architected thing you can rely on is >> the timer, which really does not hold a lot of entropy on modern solid >> state platforms. I don't have the numbers, but I do have the >> experience to back this up, unfortunately (at my former employer). >> >> You could argue that KASLR does not require strong entropy like key >> generation, but I would prefer to simply steer clear of that entire >> debate. The bootloader simply needs to do the best job it can, either >> based on some peripheral that the kernel has no awareness of this >> early in the boot, or perhaps by other means if it doesn't (which >> could include storing a random seed in the file system, or even in a >> EFI variable). Punting it to the kernel is really the last resort. >> >>> It's also not obvious that vendors will correctly implement the EFI RNG >>> protocol; depending on the above we may want to mix in additional entropy >>> regardless. >>> >> >> True, but that is not the point. The main risk I see is that vendors >> will not bother at all once the digits start to look random to the >> human eye. > > Surely there may be RNG sources that will come along in time that the > kernel can add to the entropy? Nope, not for kaslr on arm64. There are two things to keep in mind here: - arm64 does not have a decompressor, so there is no runtime environment with MMU caches etc enabled where you can reasonably execute arbitrary C code, and I am already pushing the envelope in kaslr_early_init by mapping the kernel at its default address, enable the MMU and caches, jump into C code to parse the /chosen node and set up the randomized mapping, and then tear down the default mapping, reapply all relocations and reinitialize bss etc etc. - arm64 is an architecture, not a platform like x86/pc, and so the only thing we can rely on before we have a clue what kind of system we are running on, dispatch drivers etc, is what the architecture gives us, and that does not include anything like a RDRAND instruction. IOW, the highly restricted C environment that we have before KASLR is set up does not support arbitrary platforms to slot in the code that wires up their entropy source, and so we must leave it to the bootloader. > I worry about boot loaders doing a > terrible job of finding a good RNG... > The bootloader is more tightly coupled to the hardware than the kernel is, so it is in a better position to find entropy. Case in point is UEFI, which can implement its EFI_RNG_PROTOCOL in various ways,
On 02/26/2016 02:37 PM, Ard Biesheuvel wrote: > On 26 February 2016 at 13:18, Mark Rutland <mark.rutland@arm.com> wrote: >> On Fri, Feb 26, 2016 at 12:51:25PM +0100, Ard Biesheuvel wrote: >>> On 26 February 2016 at 12:01, Laurentiu Tudor <laurentiu.tudor@nxp.com> wrote: >>>> In case the bootloader doesn't provide randomness >>>> (through device tree or by uefi protocol) generate >>>> a pseudo-random seed based on the timer counter. >>>> People might find this "week rng" approach convenient >>>> as it gets rid of the bootloader dependency. >>>> >>>> The patch tries to mimic the x86's rdtsc >>>> based implementation authored by Kees Cook. >>>> >>>> Signed-off-by: Laurentiu Tudor <laurentiu.tudor@nxp.com> >>>> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> >>>> Cc: Kees Cook <keescook@chromium.org> >>> >>> Hi Laurentiu, >>> >>> I appreciate the interest in this work, but to be honest, I don't like >>> this at all. I went out of my way to ensure that >>> a) the kernel itself does not take part in generating the random bits, and >>> b) the random bits are used in such a way that there is no correlation >>> between the randomization of the core kernel, the module region and >>> the linear region if there is no correlation between the random bits. >>> >>> The limited entropy of the cycle counter at early boot defeats that, >>> and even worse, it will not encourage platform vendors to implement >>> this properly in their boot code, given that it will appear to work, >>> and the only thing more dangerous than no security is a false sense of >>> security imo. >> >> I agree that a false sense of security is a worry here. >> >> Either way, I think we need numbers. It's non-obvious how much entropy >> we can acquire through counters or other means at early boot time. >> >> Has anyone done an analysis of environmental entropy available (through >> any means) at early boot, VM vs native? >> > > Define 'environmental'. The only architected thing you can rely on is > the timer, which really does not hold a lot of entropy on modern solid > state platforms. I don't have the numbers, but I do have the > experience to back this up, unfortunately (at my former employer). > > You could argue that KASLR does not require strong entropy like key > generation, but I would prefer to simply steer clear of that entire > debate. The bootloader simply needs to do the best job it can, either > based on some peripheral that the kernel has no awareness of this > early in the boot, or perhaps by other means if it doesn't (which > could include storing a random seed in the file system, or even in a > EFI variable). Punting it to the kernel is really the last resort. > >> It's also not obvious that vendors will correctly implement the EFI RNG >> protocol; depending on the above we may want to mix in additional entropy >> regardless. >> > > True, but that is not the point. The main risk I see is that vendors > will not bother at all once the digits start to look random to the > human eye. > >>> What I would ack, for development purposes, is something similar to >>> what Mark Rutland implemented for randomizing TEXT_OFFSET, so that >>> developers get to exercise this code even if their boot environment >>> does not provide any entropy. Anything beyond that is a nack as far as >>> I am concerned. >> >> FWIW, I would not like to see that approach. I can easily see a build-time >> constant KASLR seed being abused to give a false sense of security. Having a >> bootloader or hypervisor provide different random seeds to the same Image gives >> you a much better turnaround time for testing regardless (vs rebuilding, >> copying, etc). >> Hi guys, And thanks for all the great comments. In conclusion, seems that this patch is not the right direction, at least not in its current form. > If it would be *instead* of the ordinary handling, with a big fat > blurb saying that KASLR is disabled, I would not mind. Ard, Let me see if i understood your thoughts correctly. Have something like a KConfig option (suggestions for name, please? CONFIG_DEBUG_RANDOMIZE_BASE?) that disables the normal RNG seed handling and replaces it with this counter based weak rng, plus the big fat warning. --- Best Regards, Laurentiu
On 29 February 2016 at 13:47, Laurentiu Tudor <laurentiu.tudor@nxp.com> wrote: > On 02/26/2016 02:37 PM, Ard Biesheuvel wrote: >> On 26 February 2016 at 13:18, Mark Rutland <mark.rutland@arm.com> wrote: >>> On Fri, Feb 26, 2016 at 12:51:25PM +0100, Ard Biesheuvel wrote: >>>> On 26 February 2016 at 12:01, Laurentiu Tudor <laurentiu.tudor@nxp.com> wrote: >>>>> In case the bootloader doesn't provide randomness >>>>> (through device tree or by uefi protocol) generate >>>>> a pseudo-random seed based on the timer counter. >>>>> People might find this "week rng" approach convenient >>>>> as it gets rid of the bootloader dependency. >>>>> >>>>> The patch tries to mimic the x86's rdtsc >>>>> based implementation authored by Kees Cook. >>>>> >>>>> Signed-off-by: Laurentiu Tudor <laurentiu.tudor@nxp.com> >>>>> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> >>>>> Cc: Kees Cook <keescook@chromium.org> >>>> >>>> Hi Laurentiu, >>>> >>>> I appreciate the interest in this work, but to be honest, I don't like >>>> this at all. I went out of my way to ensure that >>>> a) the kernel itself does not take part in generating the random bits, and >>>> b) the random bits are used in such a way that there is no correlation >>>> between the randomization of the core kernel, the module region and >>>> the linear region if there is no correlation between the random bits. >>>> >>>> The limited entropy of the cycle counter at early boot defeats that, >>>> and even worse, it will not encourage platform vendors to implement >>>> this properly in their boot code, given that it will appear to work, >>>> and the only thing more dangerous than no security is a false sense of >>>> security imo. >>> >>> I agree that a false sense of security is a worry here. >>> >>> Either way, I think we need numbers. It's non-obvious how much entropy >>> we can acquire through counters or other means at early boot time. >>> >>> Has anyone done an analysis of environmental entropy available (through >>> any means) at early boot, VM vs native? >>> >> >> Define 'environmental'. The only architected thing you can rely on is >> the timer, which really does not hold a lot of entropy on modern solid >> state platforms. I don't have the numbers, but I do have the >> experience to back this up, unfortunately (at my former employer). >> >> You could argue that KASLR does not require strong entropy like key >> generation, but I would prefer to simply steer clear of that entire >> debate. The bootloader simply needs to do the best job it can, either >> based on some peripheral that the kernel has no awareness of this >> early in the boot, or perhaps by other means if it doesn't (which >> could include storing a random seed in the file system, or even in a >> EFI variable). Punting it to the kernel is really the last resort. >> >>> It's also not obvious that vendors will correctly implement the EFI RNG >>> protocol; depending on the above we may want to mix in additional entropy >>> regardless. >>> >> >> True, but that is not the point. The main risk I see is that vendors >> will not bother at all once the digits start to look random to the >> human eye. >> >>>> What I would ack, for development purposes, is something similar to >>>> what Mark Rutland implemented for randomizing TEXT_OFFSET, so that >>>> developers get to exercise this code even if their boot environment >>>> does not provide any entropy. Anything beyond that is a nack as far as >>>> I am concerned. >>> >>> FWIW, I would not like to see that approach. I can easily see a build-time >>> constant KASLR seed being abused to give a false sense of security. Having a >>> bootloader or hypervisor provide different random seeds to the same Image gives >>> you a much better turnaround time for testing regardless (vs rebuilding, >>> copying, etc). >>> > > Hi guys, > > And thanks for all the great comments. In conclusion, seems that this > patch is not the right direction, at least not in its current form. > >> If it would be *instead* of the ordinary handling, with a big fat >> blurb saying that KASLR is disabled, I would not mind. > > Ard, > > Let me see if i understood your thoughts correctly. > Have something like a KConfig option (suggestions for name, please? > CONFIG_DEBUG_RANDOMIZE_BASE?) that disables the normal RNG seed > handling and replaces it with this counter based weak rng, > plus the big fat warning. > No, that is not what I meant. What i meant was, that, in order for the KASLR plumbing to be exercised by developers whose bootloader does not supply a random seed, I could imagine a Kconfig option that rolls the dice at build time, and hardcodes that value into kaslr_early_init rather than retrieve it from the DT. This means your kernel will execute from the same 'random' address each time, even if you rebuild it, and only a Kconfig change may trigger a new value to be generated. Since this is not KASLR but a build time hack to get testing coverage for the code, it should announce that in some way. However, while I said I was not opposed to the idea, I am not crazy about it either, and it is not up to me to ultimately decide what gets merged anyway. So before you sit down and spend the time, you may want to get the maintainer's opinion first.
diff --git a/arch/arm64/kernel/kaslr.c b/arch/arm64/kernel/kaslr.c index 5829839..41e9cbd 100644 --- a/arch/arm64/kernel/kaslr.c +++ b/arch/arm64/kernel/kaslr.c @@ -13,6 +13,7 @@ #include <linux/sched.h> #include <linux/types.h> +#include <asm/arch_timer.h> #include <asm/fixmap.h> #include <asm/kernel-pgtable.h> #include <asm/memory.h> @@ -20,9 +21,30 @@ #include <asm/pgtable.h> #include <asm/sections.h> +#include <generated/compile.h> +#include <generated/utsrelease.h> + +/* Simplified build-specific string for starting entropy. */ +static const char build_str[] = UTS_RELEASE " (" LINUX_COMPILE_BY "@" + LINUX_COMPILE_HOST ") (" LINUX_COMPILER ") " UTS_VERSION; + u64 __read_mostly module_alloc_base; u16 __initdata memstart_offset_seed; +static u64 rotate_xor(u64 hash, const void *area, size_t size) +{ + size_t i; + unsigned long *ptr = (unsigned long *)area; + + for (i = 0; i < size / sizeof(hash); i++) { + /* Rotate by odd number of bits and XOR. */ + hash = (hash << ((sizeof(hash) * 8) - 7)) | (hash >> 7); + hash ^= ptr[i]; + } + + return hash; +} + static __init u64 get_kaslr_seed(void *fdt) { int node, len; @@ -101,8 +123,26 @@ u64 __init kaslr_early_init(u64 dt_phys) * Retrieve (and wipe) the seed from the FDT */ seed = get_kaslr_seed(fdt); - if (!seed) - return 0; + if (!seed) { + u64 raw; + const u64 mix_const = 0x5d6008cbf3848dd3UL; + + /* + * Attempt to create a simple but unpredictable starting + * entropy. + */ + seed = rotate_xor(seed, build_str, sizeof(build_str)); + seed = rotate_xor(seed, fdt, size); + + raw = arch_counter_get_cntvct(); + seed ^= raw; + + /* Circular multiply for better bit diffusion */ + asm("mul %1, %2, %3; umulh %0, %2, %3" + : "=&r" (raw), "=&r" (seed) + : "r" (seed), "r" (mix_const)); + seed += raw; + } /* * Check if 'nokaslr' appears on the command line, and
In case the bootloader doesn't provide randomness (through device tree or by uefi protocol) generate a pseudo-random seed based on the timer counter. People might find this "week rng" approach convenient as it gets rid of the bootloader dependency. The patch tries to mimic the x86's rdtsc based implementation authored by Kees Cook. Signed-off-by: Laurentiu Tudor <laurentiu.tudor@nxp.com> Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Kees Cook <keescook@chromium.org> --- based on http://git.linaro.org/people/ard.biesheuvel/linux-arm.git, branch arm64-kaslr-v6 arch/arm64/kernel/kaslr.c | 44 ++++++++++++++++++++++++++++++++++++++++++-- 1 file changed, 42 insertions(+), 2 deletions(-)