Re: [kernel-hardening] [PATCH v7 0/9] x86/mm: memory area address KASLR

[Ard Biesheuvel]

On 24 June 2016 at 03:11, Jason Cooper  wrote:
> Hi Ard,
>
> On Thu, Jun 23, 2016 at 10:05:53PM +0200, Ard Biesheuvel wrote:
>> On 23 June 2016 at 21:58, Kees Cook  wrote:
>> > On Thu, Jun 23, 2016 at 12:33 PM, Jason Cooper  
>> > wrote:
>> >> On Wed, Jun 22, 2016 at 10:05:51AM -0700, Kees Cook wrote:
>> >>> On Wed, Jun 22, 2016 at 8:59 AM, Thomas Garnier  
>> >>> wrote:
>> >>> > On Wed, Jun 22, 2016 at 5:47 AM, Jason Cooper  
>> >>> > wrote:
>> >>> >> Hey Kees,
>> >>> >>
>> >>> >> On Tue, Jun 21, 2016 at 05:46:57PM -0700, Kees Cook wrote:
>> >>> >>> Notable problems that needed solving:
>> >>> >> ...
>> >>> >>>  - Reasonable entropy is needed early at boot before 
>> >>> >>> get_random_bytes()
>> >>> >>>is available.
>> >>> >>
>> >>> >> This series is targetting x86, which typically has RDRAND/RDSEED
>> >>> >> instructions.  Are you referring to other arches?  Older x86?  Also,
>> >>> >> isn't this the same requirement for base address KASLR?
>> >>> >>
>> >>> >> Don't get me wrong, I want more diverse entropy sources available
>> >>> >> earlier in the boot process as well. :-)  I'm just wondering what's
>> >>> >> different about this series vs base address KASLR wrt early entropy
>> >>> >> sources.
>> >>> >>
>> >>> >
>> >>> > I think Kees was referring to the refactor I did to get the similar
>> >>> > entropy generation than KASLR module randomization. Our approach was
>> >>> > to provide best entropy possible even if you have an older processor
>> >>> > or under virtualization without support for these instructions.
>> >>> > Unfortunately common on companies with a large number of older
>> >>> > machines.
>> >>>
>> >>> Right, the memory offset KASLR uses the same routines as the kernel
>> >>> base KASLR. The issue is with older x86 systems, which continue to be
>> >>> very common.
>> >>
>> >> We have the same issue in embedded. :-(  Compounded by the fact that
>> >> there is no rand instruction (at least not on ARM).  So, even if there's
>> >> a HW-RNG, you can't access it until the driver is loaded.
>> >>
>> >> This is compounded by the fact that most systems deployed today have
>> >> bootloaders a) without hw-rng drivers, b) without dtb editing, and c)
>> >> without dtb support at all.
>> >>
>> >> My current thinking is to add a devicetree property
>> >> "userspace,random-seed" .  This way, existing, deployed
>> >> boards can append a dtb to a modern kernel with the property set.
>> >> The factory bootloader then only needs to amend its boot scripts to read
>> >> random-seed from the fs to the given address.
>> >
>> > The arm64 KASLR implementation has defined a way for boot loaders to
>> > pass in an seed similar to this. It might be nice to have a fall-back
>> > to a DT entry, though, then the bootloaders don't need to changed.
>> >
>> > Ard might have some thoughts on why DT wasn't used for KASLR (I assume
>> > the early parsing overhead, but I don't remember the discussion any
>> > more).
>> >
>>
>> On arm64, only DT is used for KASLR (even when booting via ACPI). My
>> first draft used register x1, but this turned out to be too much of a
>> hassle, since parsing the DT is also necessary to discover whether
>> there is a 'nokaslr' argument on the kernel command line. So the
>> current implementation only supports a single method, which is the
>> /chosen/kaslr-seed uint64 property.
>
> Ok, just to clarify (after a short offline chat), my goal is to set a
> userspace,random-seed  property in the device tree once.
> The bootloader scripts would also only need to be altered once.
>
> Then, at each boot, the bootloader reads the entirety of
> /var/lib/misc/random-seed (512 bytes) into the configured address.
> random-seed could be in /boot, or on a flash partition.
>
> The decompressor would consume a small portion of that seed for kaslr
> and such.  After that, the rest would be consumed by random.c to
> initialize the entropy pools.
>

I see. This indeed has little to do with the arm64 KASLR case, other
than that they both use a DT property.

In the arm64 KASLR case, I deliberately chose to leave it up to the
bootloader/firmware to roll the dice, for the same reason you pointed
out, i.e., that there is no architected way on ARM to obtain random
bits. So in that sense, what you are doing is complimentary to my
work, and a KASLR  aware arm64 bootloader would copy some of its
random bits taken from /var/lib/misc/random-seed into the
/chosen/kaslr-seed DT property. Note that, at the moment, this DT
property is only an internal contract between the kernel's UEFI stub
and the kernel proper, so we could still easily change that if
necessary.

Alternatively, if we go with your solution, the KASLR code should read
from the address in userspace,random-seed rather than the
/chosen/kaslr-seed property itself. (or use the former as a fallback
if the latter was not found)

-- 

Re: [kernel-hardening] [PATCH v7 0/9] x86/mm: memory area address KASLR

[Ard Biesheuvel]

On 24 June 2016 at 03:11, Jason Cooper  wrote:
> Hi Ard,
>
> On Thu, Jun 23, 2016 at 10:05:53PM +0200, Ard Biesheuvel wrote:
>> On 23 June 2016 at 21:58, Kees Cook  wrote:
>> > On Thu, Jun 23, 2016 at 12:33 PM, Jason Cooper  
>> > wrote:
>> >> On Wed, Jun 22, 2016 at 10:05:51AM -0700, Kees Cook wrote:
>> >>> On Wed, Jun 22, 2016 at 8:59 AM, Thomas Garnier  
>> >>> wrote:
>> >>> > On Wed, Jun 22, 2016 at 5:47 AM, Jason Cooper  
>> >>> > wrote:
>> >>> >> Hey Kees,
>> >>> >>
>> >>> >> On Tue, Jun 21, 2016 at 05:46:57PM -0700, Kees Cook wrote:
>> >>> >>> Notable problems that needed solving:
>> >>> >> ...
>> >>> >>>  - Reasonable entropy is needed early at boot before 
>> >>> >>> get_random_bytes()
>> >>> >>>is available.
>> >>> >>
>> >>> >> This series is targetting x86, which typically has RDRAND/RDSEED
>> >>> >> instructions.  Are you referring to other arches?  Older x86?  Also,
>> >>> >> isn't this the same requirement for base address KASLR?
>> >>> >>
>> >>> >> Don't get me wrong, I want more diverse entropy sources available
>> >>> >> earlier in the boot process as well. :-)  I'm just wondering what's
>> >>> >> different about this series vs base address KASLR wrt early entropy
>> >>> >> sources.
>> >>> >>
>> >>> >
>> >>> > I think Kees was referring to the refactor I did to get the similar
>> >>> > entropy generation than KASLR module randomization. Our approach was
>> >>> > to provide best entropy possible even if you have an older processor
>> >>> > or under virtualization without support for these instructions.
>> >>> > Unfortunately common on companies with a large number of older
>> >>> > machines.
>> >>>
>> >>> Right, the memory offset KASLR uses the same routines as the kernel
>> >>> base KASLR. The issue is with older x86 systems, which continue to be
>> >>> very common.
>> >>
>> >> We have the same issue in embedded. :-(  Compounded by the fact that
>> >> there is no rand instruction (at least not on ARM).  So, even if there's
>> >> a HW-RNG, you can't access it until the driver is loaded.
>> >>
>> >> This is compounded by the fact that most systems deployed today have
>> >> bootloaders a) without hw-rng drivers, b) without dtb editing, and c)
>> >> without dtb support at all.
>> >>
>> >> My current thinking is to add a devicetree property
>> >> "userspace,random-seed" .  This way, existing, deployed
>> >> boards can append a dtb to a modern kernel with the property set.
>> >> The factory bootloader then only needs to amend its boot scripts to read
>> >> random-seed from the fs to the given address.
>> >
>> > The arm64 KASLR implementation has defined a way for boot loaders to
>> > pass in an seed similar to this. It might be nice to have a fall-back
>> > to a DT entry, though, then the bootloaders don't need to changed.
>> >
>> > Ard might have some thoughts on why DT wasn't used for KASLR (I assume
>> > the early parsing overhead, but I don't remember the discussion any
>> > more).
>> >
>>
>> On arm64, only DT is used for KASLR (even when booting via ACPI). My
>> first draft used register x1, but this turned out to be too much of a
>> hassle, since parsing the DT is also necessary to discover whether
>> there is a 'nokaslr' argument on the kernel command line. So the
>> current implementation only supports a single method, which is the
>> /chosen/kaslr-seed uint64 property.
>
> Ok, just to clarify (after a short offline chat), my goal is to set a
> userspace,random-seed  property in the device tree once.
> The bootloader scripts would also only need to be altered once.
>
> Then, at each boot, the bootloader reads the entirety of
> /var/lib/misc/random-seed (512 bytes) into the configured address.
> random-seed could be in /boot, or on a flash partition.
>
> The decompressor would consume a small portion of that seed for kaslr
> and such.  After that, the rest would be consumed by random.c to
> initialize the entropy pools.
>

I see. This indeed has little to do with the arm64 KASLR case, other
than that they both use a DT property.

In the arm64 KASLR case, I deliberately chose to leave it up to the
bootloader/firmware to roll the dice, for the same reason you pointed
out, i.e., that there is no architected way on ARM to obtain random
bits. So in that sense, what you are doing is complimentary to my
work, and a KASLR  aware arm64 bootloader would copy some of its
random bits taken from /var/lib/misc/random-seed into the
/chosen/kaslr-seed DT property. Note that, at the moment, this DT
property is only an internal contract between the kernel's UEFI stub
and the kernel proper, so we could still easily change that if
necessary.

Alternatively, if we go with your solution, the KASLR code should read
from the address in userspace,random-seed rather than the
/chosen/kaslr-seed property itself. (or use the former as a fallback
if the latter was not found)

-- 
Ard.

Re: [kernel-hardening] [PATCH v7 0/9] x86/mm: memory area address KASLR

[Jason Cooper]

Hi Ard,

On Thu, Jun 23, 2016 at 10:05:53PM +0200, Ard Biesheuvel wrote:
> On 23 June 2016 at 21:58, Kees Cook  wrote:
> > On Thu, Jun 23, 2016 at 12:33 PM, Jason Cooper  wrote:
> >> On Wed, Jun 22, 2016 at 10:05:51AM -0700, Kees Cook wrote:
> >>> On Wed, Jun 22, 2016 at 8:59 AM, Thomas Garnier  
> >>> wrote:
> >>> > On Wed, Jun 22, 2016 at 5:47 AM, Jason Cooper  
> >>> > wrote:
> >>> >> Hey Kees,
> >>> >>
> >>> >> On Tue, Jun 21, 2016 at 05:46:57PM -0700, Kees Cook wrote:
> >>> >>> Notable problems that needed solving:
> >>> >> ...
> >>> >>>  - Reasonable entropy is needed early at boot before 
> >>> >>> get_random_bytes()
> >>> >>>is available.
> >>> >>
> >>> >> This series is targetting x86, which typically has RDRAND/RDSEED
> >>> >> instructions.  Are you referring to other arches?  Older x86?  Also,
> >>> >> isn't this the same requirement for base address KASLR?
> >>> >>
> >>> >> Don't get me wrong, I want more diverse entropy sources available
> >>> >> earlier in the boot process as well. :-)  I'm just wondering what's
> >>> >> different about this series vs base address KASLR wrt early entropy
> >>> >> sources.
> >>> >>
> >>> >
> >>> > I think Kees was referring to the refactor I did to get the similar
> >>> > entropy generation than KASLR module randomization. Our approach was
> >>> > to provide best entropy possible even if you have an older processor
> >>> > or under virtualization without support for these instructions.
> >>> > Unfortunately common on companies with a large number of older
> >>> > machines.
> >>>
> >>> Right, the memory offset KASLR uses the same routines as the kernel
> >>> base KASLR. The issue is with older x86 systems, which continue to be
> >>> very common.
> >>
> >> We have the same issue in embedded. :-(  Compounded by the fact that
> >> there is no rand instruction (at least not on ARM).  So, even if there's
> >> a HW-RNG, you can't access it until the driver is loaded.
> >>
> >> This is compounded by the fact that most systems deployed today have
> >> bootloaders a) without hw-rng drivers, b) without dtb editing, and c)
> >> without dtb support at all.
> >>
> >> My current thinking is to add a devicetree property
> >> "userspace,random-seed" .  This way, existing, deployed
> >> boards can append a dtb to a modern kernel with the property set.
> >> The factory bootloader then only needs to amend its boot scripts to read
> >> random-seed from the fs to the given address.
> >
> > The arm64 KASLR implementation has defined a way for boot loaders to
> > pass in an seed similar to this. It might be nice to have a fall-back
> > to a DT entry, though, then the bootloaders don't need to changed.
> >
> > Ard might have some thoughts on why DT wasn't used for KASLR (I assume
> > the early parsing overhead, but I don't remember the discussion any
> > more).
> >
> 
> On arm64, only DT is used for KASLR (even when booting via ACPI). My
> first draft used register x1, but this turned out to be too much of a
> hassle, since parsing the DT is also necessary to discover whether
> there is a 'nokaslr' argument on the kernel command line. So the
> current implementation only supports a single method, which is the
> /chosen/kaslr-seed uint64 property.

Ok, just to clarify (after a short offline chat), my goal is to set a
userspace,random-seed  property in the device tree once.
The bootloader scripts would also only need to be altered once.

Then, at each boot, the bootloader reads the entirety of
/var/lib/misc/random-seed (512 bytes) into the configured address.
random-seed could be in /boot, or on a flash partition.

The decompressor would consume a small portion of that seed for kaslr
and such.  After that, the rest would be consumed by random.c to
initialize the entropy pools.

thx,

Jason.

Re: [kernel-hardening] [PATCH v7 0/9] x86/mm: memory area address KASLR

[Jason Cooper]

Hi Ard,

On Thu, Jun 23, 2016 at 10:05:53PM +0200, Ard Biesheuvel wrote:
> On 23 June 2016 at 21:58, Kees Cook  wrote:
> > On Thu, Jun 23, 2016 at 12:33 PM, Jason Cooper  wrote:
> >> On Wed, Jun 22, 2016 at 10:05:51AM -0700, Kees Cook wrote:
> >>> On Wed, Jun 22, 2016 at 8:59 AM, Thomas Garnier  
> >>> wrote:
> >>> > On Wed, Jun 22, 2016 at 5:47 AM, Jason Cooper  
> >>> > wrote:
> >>> >> Hey Kees,
> >>> >>
> >>> >> On Tue, Jun 21, 2016 at 05:46:57PM -0700, Kees Cook wrote:
> >>> >>> Notable problems that needed solving:
> >>> >> ...
> >>> >>>  - Reasonable entropy is needed early at boot before 
> >>> >>> get_random_bytes()
> >>> >>>is available.
> >>> >>
> >>> >> This series is targetting x86, which typically has RDRAND/RDSEED
> >>> >> instructions.  Are you referring to other arches?  Older x86?  Also,
> >>> >> isn't this the same requirement for base address KASLR?
> >>> >>
> >>> >> Don't get me wrong, I want more diverse entropy sources available
> >>> >> earlier in the boot process as well. :-)  I'm just wondering what's
> >>> >> different about this series vs base address KASLR wrt early entropy
> >>> >> sources.
> >>> >>
> >>> >
> >>> > I think Kees was referring to the refactor I did to get the similar
> >>> > entropy generation than KASLR module randomization. Our approach was
> >>> > to provide best entropy possible even if you have an older processor
> >>> > or under virtualization without support for these instructions.
> >>> > Unfortunately common on companies with a large number of older
> >>> > machines.
> >>>
> >>> Right, the memory offset KASLR uses the same routines as the kernel
> >>> base KASLR. The issue is with older x86 systems, which continue to be
> >>> very common.
> >>
> >> We have the same issue in embedded. :-(  Compounded by the fact that
> >> there is no rand instruction (at least not on ARM).  So, even if there's
> >> a HW-RNG, you can't access it until the driver is loaded.
> >>
> >> This is compounded by the fact that most systems deployed today have
> >> bootloaders a) without hw-rng drivers, b) without dtb editing, and c)
> >> without dtb support at all.
> >>
> >> My current thinking is to add a devicetree property
> >> "userspace,random-seed" .  This way, existing, deployed
> >> boards can append a dtb to a modern kernel with the property set.
> >> The factory bootloader then only needs to amend its boot scripts to read
> >> random-seed from the fs to the given address.
> >
> > The arm64 KASLR implementation has defined a way for boot loaders to
> > pass in an seed similar to this. It might be nice to have a fall-back
> > to a DT entry, though, then the bootloaders don't need to changed.
> >
> > Ard might have some thoughts on why DT wasn't used for KASLR (I assume
> > the early parsing overhead, but I don't remember the discussion any
> > more).
> >
> 
> On arm64, only DT is used for KASLR (even when booting via ACPI). My
> first draft used register x1, but this turned out to be too much of a
> hassle, since parsing the DT is also necessary to discover whether
> there is a 'nokaslr' argument on the kernel command line. So the
> current implementation only supports a single method, which is the
> /chosen/kaslr-seed uint64 property.

Ok, just to clarify (after a short offline chat), my goal is to set a
userspace,random-seed  property in the device tree once.
The bootloader scripts would also only need to be altered once.

Then, at each boot, the bootloader reads the entirety of
/var/lib/misc/random-seed (512 bytes) into the configured address.
random-seed could be in /boot, or on a flash partition.

The decompressor would consume a small portion of that seed for kaslr
and such.  After that, the rest would be consumed by random.c to
initialize the entropy pools.

thx,

Jason.

Re: [kernel-hardening] [PATCH v7 0/9] x86/mm: memory area address KASLR

[Jason Cooper]

On Thu, Jun 23, 2016 at 12:59:07PM -0700, Kees Cook wrote:
> On Thu, Jun 23, 2016 at 12:45 PM, Sandy Harris  wrote:
> > Jason Cooper  wrote:
> >
> >> Modern systems that receive a seed from the bootloader via the
> >> random-seed property (typically from the hw-rng) can mix both sources
> >> for increased resilience.
> >>
> >> Unfortunately, I'm not very familiar with the internals of x86
> >> bootstrapping.  Could GRUB be scripted to do a similar task?  How would
> >> the address and size of the seed be passed to the kernel?  command line?
> >
> > One suggestion is at:
> > http://www.av8n.com/computer/htm/secure-random.htm#sec-boot-image
> 
> Interesting! This might pose a problem for signed images, though.
> (Actually, for signed arm kernels is the DT signed too? If so, it
> would be a similar problem.)

That's the reason for userspace,random-seed = .  Once
set, the dtb never has to change.  The bootloader loads the file to the
same address at each boot.  Userspace is responsible, as it is already,
for updating the random-seed file while up.

thx,

Jason.

Re: [kernel-hardening] [PATCH v7 0/9] x86/mm: memory area address KASLR

[Jason Cooper]

On Thu, Jun 23, 2016 at 12:59:07PM -0700, Kees Cook wrote:
> On Thu, Jun 23, 2016 at 12:45 PM, Sandy Harris  wrote:
> > Jason Cooper  wrote:
> >
> >> Modern systems that receive a seed from the bootloader via the
> >> random-seed property (typically from the hw-rng) can mix both sources
> >> for increased resilience.
> >>
> >> Unfortunately, I'm not very familiar with the internals of x86
> >> bootstrapping.  Could GRUB be scripted to do a similar task?  How would
> >> the address and size of the seed be passed to the kernel?  command line?
> >
> > One suggestion is at:
> > http://www.av8n.com/computer/htm/secure-random.htm#sec-boot-image
> 
> Interesting! This might pose a problem for signed images, though.
> (Actually, for signed arm kernels is the DT signed too? If so, it
> would be a similar problem.)

That's the reason for userspace,random-seed = .  Once
set, the dtb never has to change.  The bootloader loads the file to the
same address at each boot.  Userspace is responsible, as it is already,
for updating the random-seed file while up.

thx,

Jason.

Re: [kernel-hardening] [PATCH v7 0/9] x86/mm: memory area address KASLR

[Jason Cooper]

Hey Sandy,

On Thu, Jun 23, 2016 at 03:45:54PM -0400, Sandy Harris wrote:
> Jason Cooper  wrote:
> 
> > Modern systems that receive a seed from the bootloader via the
> > random-seed property (typically from the hw-rng) can mix both sources
> > for increased resilience.
> >
> > Unfortunately, I'm not very familiar with the internals of x86
> > bootstrapping.  Could GRUB be scripted to do a similar task?  How would
> > the address and size of the seed be passed to the kernel?  command line?
> 
> One suggestion is at:
> http://www.av8n.com/computer/htm/secure-random.htm#sec-boot-image

Yes, this is very similar to the latent_entropy series that I think Kees
just merged.  Well, at a high level, it is.  'store a seed in the
kernel, use it at reboot'.

These approaches are good in that they provide yet another source of
entropy to the kernel.  However, both suffer from the kernel binary
being very static in time and across distro installs.  Particularly with
embedded systems.  It almost becomes a long term secret.  Which, the
longer it lives, the less chance there is of it being secret.

I'm not really comfortable with what John suggests, here:

"""
Next step: It should be straightforward to write a tool that efficiently
updates the stored seed within the boot image. Updating MUST occur
during provisioning, before the device gets booted for the first time
... and also from time to time thereafter. Updating the boot image isn’t
be quite as simple as dd of=/var/lib/urandom/random-seed but neither is
it rocket surgery. The cost is utterly negligible compared to the cost
of a security breach, which is the relevant comparison.
"""

Editing the installed kernel binary to add the seed is exposing the
system to unnecessary risk of bricking the system (e.g. powerfail
 halfway through) [0].  Yes, this can be mitigated by following a similar
process to kernel updates, but why?  The bootloader already knows how to
read a file into RAM.  We just need to put it in the right place and
tell it to do so.  And userspace already writes a new random-seed during
system init and clean shutdown.

We just need to connect the dots so deployed systems can use the seed
earlier without having to hack the kernel or update the bootloader.
Which, while possible, a lot of folks are skittish to do.

thx,

Jason.

[0] I imagine it also borks code-signing...

Re: [kernel-hardening] [PATCH v7 0/9] x86/mm: memory area address KASLR

[Jason Cooper]

Hey Sandy,

On Thu, Jun 23, 2016 at 03:45:54PM -0400, Sandy Harris wrote:
> Jason Cooper  wrote:
> 
> > Modern systems that receive a seed from the bootloader via the
> > random-seed property (typically from the hw-rng) can mix both sources
> > for increased resilience.
> >
> > Unfortunately, I'm not very familiar with the internals of x86
> > bootstrapping.  Could GRUB be scripted to do a similar task?  How would
> > the address and size of the seed be passed to the kernel?  command line?
> 
> One suggestion is at:
> http://www.av8n.com/computer/htm/secure-random.htm#sec-boot-image

Yes, this is very similar to the latent_entropy series that I think Kees
just merged.  Well, at a high level, it is.  'store a seed in the
kernel, use it at reboot'.

These approaches are good in that they provide yet another source of
entropy to the kernel.  However, both suffer from the kernel binary
being very static in time and across distro installs.  Particularly with
embedded systems.  It almost becomes a long term secret.  Which, the
longer it lives, the less chance there is of it being secret.

I'm not really comfortable with what John suggests, here:

"""
Next step: It should be straightforward to write a tool that efficiently
updates the stored seed within the boot image. Updating MUST occur
during provisioning, before the device gets booted for the first time
... and also from time to time thereafter. Updating the boot image isn’t
be quite as simple as dd of=/var/lib/urandom/random-seed but neither is
it rocket surgery. The cost is utterly negligible compared to the cost
of a security breach, which is the relevant comparison.
"""

Editing the installed kernel binary to add the seed is exposing the
system to unnecessary risk of bricking the system (e.g. powerfail
 halfway through) [0].  Yes, this can be mitigated by following a similar
process to kernel updates, but why?  The bootloader already knows how to
read a file into RAM.  We just need to put it in the right place and
tell it to do so.  And userspace already writes a new random-seed during
system init and clean shutdown.

We just need to connect the dots so deployed systems can use the seed
earlier without having to hack the kernel or update the bootloader.
Which, while possible, a lot of folks are skittish to do.

thx,

Jason.

[0] I imagine it also borks code-signing...

Re: [kernel-hardening] [PATCH v7 0/9] x86/mm: memory area address KASLR

[Ard Biesheuvel]

On 23 June 2016 at 21:58, Kees Cook  wrote:
> On Thu, Jun 23, 2016 at 12:33 PM, Jason Cooper  wrote:
>> Hey Kees, Thomas,
>>
>> On Wed, Jun 22, 2016 at 10:05:51AM -0700, Kees Cook wrote:
>>> On Wed, Jun 22, 2016 at 8:59 AM, Thomas Garnier  wrote:
>>> > On Wed, Jun 22, 2016 at 5:47 AM, Jason Cooper  
>>> > wrote:
>>> >> Hey Kees,
>>> >>
>>> >> On Tue, Jun 21, 2016 at 05:46:57PM -0700, Kees Cook wrote:
>>> >>> Notable problems that needed solving:
>>> >> ...
>>> >>>  - Reasonable entropy is needed early at boot before get_random_bytes()
>>> >>>is available.
>>> >>
>>> >> This series is targetting x86, which typically has RDRAND/RDSEED
>>> >> instructions.  Are you referring to other arches?  Older x86?  Also,
>>> >> isn't this the same requirement for base address KASLR?
>>> >>
>>> >> Don't get me wrong, I want more diverse entropy sources available
>>> >> earlier in the boot process as well. :-)  I'm just wondering what's
>>> >> different about this series vs base address KASLR wrt early entropy
>>> >> sources.
>>> >>
>>> >
>>> > I think Kees was referring to the refactor I did to get the similar
>>> > entropy generation than KASLR module randomization. Our approach was
>>> > to provide best entropy possible even if you have an older processor
>>> > or under virtualization without support for these instructions.
>>> > Unfortunately common on companies with a large number of older
>>> > machines.
>>>
>>> Right, the memory offset KASLR uses the same routines as the kernel
>>> base KASLR. The issue is with older x86 systems, which continue to be
>>> very common.
>>
>> We have the same issue in embedded. :-(  Compounded by the fact that
>> there is no rand instruction (at least not on ARM).  So, even if there's
>> a HW-RNG, you can't access it until the driver is loaded.
>>
>> This is compounded by the fact that most systems deployed today have
>> bootloaders a) without hw-rng drivers, b) without dtb editing, and c)
>> without dtb support at all.
>>
>> My current thinking is to add a devicetree property
>> "userspace,random-seed" .  This way, existing, deployed
>> boards can append a dtb to a modern kernel with the property set.
>> The factory bootloader then only needs to amend its boot scripts to read
>> random-seed from the fs to the given address.
>
> The arm64 KASLR implementation has defined a way for boot loaders to
> pass in an seed similar to this. It might be nice to have a fall-back
> to a DT entry, though, then the bootloaders don't need to changed.
>
> Ard might have some thoughts on why DT wasn't used for KASLR (I assume
> the early parsing overhead, but I don't remember the discussion any
> more).
>

On arm64, only DT is used for KASLR (even when booting via ACPI). My
first draft used register x1, but this turned out to be too much of a
hassle, since parsing the DT is also necessary to discover whether
there is a 'nokaslr' argument on the kernel command line. So the
current implementation only supports a single method, which is the
/chosen/kaslr-seed uint64 property.

>> Modern systems that receive a seed from the bootloader via the
>> random-seed property (typically from the hw-rng) can mix both sources
>> for increased resilience.
>
> Yeah, that could work.
>
>> Unfortunately, I'm not very familiar with the internals of x86
>> bootstrapping.  Could GRUB be scripted to do a similar task?  How would
>> the address and size of the seed be passed to the kernel?  command line?
>
> Command line could work (though it would need scrubbing to avoid it
> leaking into /proc/cmdine), but there's also the "zero-page" used by
> bootloaders to pass details to the kernel (see
> Documentation/x86/boot.txt). Right now, x86 has sufficient entropy
> (though rdrand is best).
>
> -Kees
>
> --
> Kees Cook
> Chrome OS & Brillo Security

Re: [kernel-hardening] [PATCH v7 0/9] x86/mm: memory area address KASLR

[Ard Biesheuvel]

On 23 June 2016 at 21:58, Kees Cook  wrote:
> On Thu, Jun 23, 2016 at 12:33 PM, Jason Cooper  wrote:
>> Hey Kees, Thomas,
>>
>> On Wed, Jun 22, 2016 at 10:05:51AM -0700, Kees Cook wrote:
>>> On Wed, Jun 22, 2016 at 8:59 AM, Thomas Garnier  wrote:
>>> > On Wed, Jun 22, 2016 at 5:47 AM, Jason Cooper  
>>> > wrote:
>>> >> Hey Kees,
>>> >>
>>> >> On Tue, Jun 21, 2016 at 05:46:57PM -0700, Kees Cook wrote:
>>> >>> Notable problems that needed solving:
>>> >> ...
>>> >>>  - Reasonable entropy is needed early at boot before get_random_bytes()
>>> >>>is available.
>>> >>
>>> >> This series is targetting x86, which typically has RDRAND/RDSEED
>>> >> instructions.  Are you referring to other arches?  Older x86?  Also,
>>> >> isn't this the same requirement for base address KASLR?
>>> >>
>>> >> Don't get me wrong, I want more diverse entropy sources available
>>> >> earlier in the boot process as well. :-)  I'm just wondering what's
>>> >> different about this series vs base address KASLR wrt early entropy
>>> >> sources.
>>> >>
>>> >
>>> > I think Kees was referring to the refactor I did to get the similar
>>> > entropy generation than KASLR module randomization. Our approach was
>>> > to provide best entropy possible even if you have an older processor
>>> > or under virtualization without support for these instructions.
>>> > Unfortunately common on companies with a large number of older
>>> > machines.
>>>
>>> Right, the memory offset KASLR uses the same routines as the kernel
>>> base KASLR. The issue is with older x86 systems, which continue to be
>>> very common.
>>
>> We have the same issue in embedded. :-(  Compounded by the fact that
>> there is no rand instruction (at least not on ARM).  So, even if there's
>> a HW-RNG, you can't access it until the driver is loaded.
>>
>> This is compounded by the fact that most systems deployed today have
>> bootloaders a) without hw-rng drivers, b) without dtb editing, and c)
>> without dtb support at all.
>>
>> My current thinking is to add a devicetree property
>> "userspace,random-seed" .  This way, existing, deployed
>> boards can append a dtb to a modern kernel with the property set.
>> The factory bootloader then only needs to amend its boot scripts to read
>> random-seed from the fs to the given address.
>
> The arm64 KASLR implementation has defined a way for boot loaders to
> pass in an seed similar to this. It might be nice to have a fall-back
> to a DT entry, though, then the bootloaders don't need to changed.
>
> Ard might have some thoughts on why DT wasn't used for KASLR (I assume
> the early parsing overhead, but I don't remember the discussion any
> more).
>

On arm64, only DT is used for KASLR (even when booting via ACPI). My
first draft used register x1, but this turned out to be too much of a
hassle, since parsing the DT is also necessary to discover whether
there is a 'nokaslr' argument on the kernel command line. So the
current implementation only supports a single method, which is the
/chosen/kaslr-seed uint64 property.

>> Modern systems that receive a seed from the bootloader via the
>> random-seed property (typically from the hw-rng) can mix both sources
>> for increased resilience.
>
> Yeah, that could work.
>
>> Unfortunately, I'm not very familiar with the internals of x86
>> bootstrapping.  Could GRUB be scripted to do a similar task?  How would
>> the address and size of the seed be passed to the kernel?  command line?
>
> Command line could work (though it would need scrubbing to avoid it
> leaking into /proc/cmdine), but there's also the "zero-page" used by
> bootloaders to pass details to the kernel (see
> Documentation/x86/boot.txt). Right now, x86 has sufficient entropy
> (though rdrand is best).
>
> -Kees
>
> --
> Kees Cook
> Chrome OS & Brillo Security

Re: [kernel-hardening] [PATCH v7 0/9] x86/mm: memory area address KASLR

[Kees Cook]

On Thu, Jun 23, 2016 at 12:45 PM, Sandy Harris  wrote:
> Jason Cooper  wrote:
>
>> Modern systems that receive a seed from the bootloader via the
>> random-seed property (typically from the hw-rng) can mix both sources
>> for increased resilience.
>>
>> Unfortunately, I'm not very familiar with the internals of x86
>> bootstrapping.  Could GRUB be scripted to do a similar task?  How would
>> the address and size of the seed be passed to the kernel?  command line?
>
> One suggestion is at:
> http://www.av8n.com/computer/htm/secure-random.htm#sec-boot-image

Interesting! This might pose a problem for signed images, though.
(Actually, for signed arm kernels is the DT signed too? If so, it
would be a similar problem.)

-Kees

-- 
Kees Cook
Chrome OS & Brillo Security

Re: [kernel-hardening] [PATCH v7 0/9] x86/mm: memory area address KASLR

[Kees Cook]

On Thu, Jun 23, 2016 at 12:45 PM, Sandy Harris  wrote:
> Jason Cooper  wrote:
>
>> Modern systems that receive a seed from the bootloader via the
>> random-seed property (typically from the hw-rng) can mix both sources
>> for increased resilience.
>>
>> Unfortunately, I'm not very familiar with the internals of x86
>> bootstrapping.  Could GRUB be scripted to do a similar task?  How would
>> the address and size of the seed be passed to the kernel?  command line?
>
> One suggestion is at:
> http://www.av8n.com/computer/htm/secure-random.htm#sec-boot-image

Interesting! This might pose a problem for signed images, though.
(Actually, for signed arm kernels is the DT signed too? If so, it
would be a similar problem.)

-Kees

-- 
Kees Cook
Chrome OS & Brillo Security

Re: [kernel-hardening] [PATCH v7 0/9] x86/mm: memory area address KASLR

[Kees Cook]

On Thu, Jun 23, 2016 at 12:33 PM, Jason Cooper  wrote:
> Hey Kees, Thomas,
>
> On Wed, Jun 22, 2016 at 10:05:51AM -0700, Kees Cook wrote:
>> On Wed, Jun 22, 2016 at 8:59 AM, Thomas Garnier  wrote:
>> > On Wed, Jun 22, 2016 at 5:47 AM, Jason Cooper  wrote:
>> >> Hey Kees,
>> >>
>> >> On Tue, Jun 21, 2016 at 05:46:57PM -0700, Kees Cook wrote:
>> >>> Notable problems that needed solving:
>> >> ...
>> >>>  - Reasonable entropy is needed early at boot before get_random_bytes()
>> >>>is available.
>> >>
>> >> This series is targetting x86, which typically has RDRAND/RDSEED
>> >> instructions.  Are you referring to other arches?  Older x86?  Also,
>> >> isn't this the same requirement for base address KASLR?
>> >>
>> >> Don't get me wrong, I want more diverse entropy sources available
>> >> earlier in the boot process as well. :-)  I'm just wondering what's
>> >> different about this series vs base address KASLR wrt early entropy
>> >> sources.
>> >>
>> >
>> > I think Kees was referring to the refactor I did to get the similar
>> > entropy generation than KASLR module randomization. Our approach was
>> > to provide best entropy possible even if you have an older processor
>> > or under virtualization without support for these instructions.
>> > Unfortunately common on companies with a large number of older
>> > machines.
>>
>> Right, the memory offset KASLR uses the same routines as the kernel
>> base KASLR. The issue is with older x86 systems, which continue to be
>> very common.
>
> We have the same issue in embedded. :-(  Compounded by the fact that
> there is no rand instruction (at least not on ARM).  So, even if there's
> a HW-RNG, you can't access it until the driver is loaded.
>
> This is compounded by the fact that most systems deployed today have
> bootloaders a) without hw-rng drivers, b) without dtb editing, and c)
> without dtb support at all.
>
> My current thinking is to add a devicetree property
> "userspace,random-seed" .  This way, existing, deployed
> boards can append a dtb to a modern kernel with the property set.
> The factory bootloader then only needs to amend its boot scripts to read
> random-seed from the fs to the given address.

The arm64 KASLR implementation has defined a way for boot loaders to
pass in an seed similar to this. It might be nice to have a fall-back
to a DT entry, though, then the bootloaders don't need to changed.

Ard might have some thoughts on why DT wasn't used for KASLR (I assume
the early parsing overhead, but I don't remember the discussion any
more).

> Modern systems that receive a seed from the bootloader via the
> random-seed property (typically from the hw-rng) can mix both sources
> for increased resilience.

Yeah, that could work.

> Unfortunately, I'm not very familiar with the internals of x86
> bootstrapping.  Could GRUB be scripted to do a similar task?  How would
> the address and size of the seed be passed to the kernel?  command line?

Command line could work (though it would need scrubbing to avoid it
leaking into /proc/cmdine), but there's also the "zero-page" used by
bootloaders to pass details to the kernel (see
Documentation/x86/boot.txt). Right now, x86 has sufficient entropy
(though rdrand is best).

-Kees

-- 
Kees Cook
Chrome OS & Brillo Security

Re: [kernel-hardening] [PATCH v7 0/9] x86/mm: memory area address KASLR

[Kees Cook]

On Thu, Jun 23, 2016 at 12:33 PM, Jason Cooper  wrote:
> Hey Kees, Thomas,
>
> On Wed, Jun 22, 2016 at 10:05:51AM -0700, Kees Cook wrote:
>> On Wed, Jun 22, 2016 at 8:59 AM, Thomas Garnier  wrote:
>> > On Wed, Jun 22, 2016 at 5:47 AM, Jason Cooper  wrote:
>> >> Hey Kees,
>> >>
>> >> On Tue, Jun 21, 2016 at 05:46:57PM -0700, Kees Cook wrote:
>> >>> Notable problems that needed solving:
>> >> ...
>> >>>  - Reasonable entropy is needed early at boot before get_random_bytes()
>> >>>is available.
>> >>
>> >> This series is targetting x86, which typically has RDRAND/RDSEED
>> >> instructions.  Are you referring to other arches?  Older x86?  Also,
>> >> isn't this the same requirement for base address KASLR?
>> >>
>> >> Don't get me wrong, I want more diverse entropy sources available
>> >> earlier in the boot process as well. :-)  I'm just wondering what's
>> >> different about this series vs base address KASLR wrt early entropy
>> >> sources.
>> >>
>> >
>> > I think Kees was referring to the refactor I did to get the similar
>> > entropy generation than KASLR module randomization. Our approach was
>> > to provide best entropy possible even if you have an older processor
>> > or under virtualization without support for these instructions.
>> > Unfortunately common on companies with a large number of older
>> > machines.
>>
>> Right, the memory offset KASLR uses the same routines as the kernel
>> base KASLR. The issue is with older x86 systems, which continue to be
>> very common.
>
> We have the same issue in embedded. :-(  Compounded by the fact that
> there is no rand instruction (at least not on ARM).  So, even if there's
> a HW-RNG, you can't access it until the driver is loaded.
>
> This is compounded by the fact that most systems deployed today have
> bootloaders a) without hw-rng drivers, b) without dtb editing, and c)
> without dtb support at all.
>
> My current thinking is to add a devicetree property
> "userspace,random-seed" .  This way, existing, deployed
> boards can append a dtb to a modern kernel with the property set.
> The factory bootloader then only needs to amend its boot scripts to read
> random-seed from the fs to the given address.

The arm64 KASLR implementation has defined a way for boot loaders to
pass in an seed similar to this. It might be nice to have a fall-back
to a DT entry, though, then the bootloaders don't need to changed.

Ard might have some thoughts on why DT wasn't used for KASLR (I assume
the early parsing overhead, but I don't remember the discussion any
more).

> Modern systems that receive a seed from the bootloader via the
> random-seed property (typically from the hw-rng) can mix both sources
> for increased resilience.

Yeah, that could work.

> Unfortunately, I'm not very familiar with the internals of x86
> bootstrapping.  Could GRUB be scripted to do a similar task?  How would
> the address and size of the seed be passed to the kernel?  command line?

Command line could work (though it would need scrubbing to avoid it
leaking into /proc/cmdine), but there's also the "zero-page" used by
bootloaders to pass details to the kernel (see
Documentation/x86/boot.txt). Right now, x86 has sufficient entropy
(though rdrand is best).

-Kees

-- 
Kees Cook
Chrome OS & Brillo Security

Re: [kernel-hardening] [PATCH v7 0/9] x86/mm: memory area address KASLR

[Sandy Harris]

Jason Cooper  wrote:

> Modern systems that receive a seed from the bootloader via the
> random-seed property (typically from the hw-rng) can mix both sources
> for increased resilience.
>
> Unfortunately, I'm not very familiar with the internals of x86
> bootstrapping.  Could GRUB be scripted to do a similar task?  How would
> the address and size of the seed be passed to the kernel?  command line?

One suggestion is at:
http://www.av8n.com/computer/htm/secure-random.htm#sec-boot-image

Re: [kernel-hardening] [PATCH v7 0/9] x86/mm: memory area address KASLR

[Sandy Harris]

Jason Cooper  wrote:

> Modern systems that receive a seed from the bootloader via the
> random-seed property (typically from the hw-rng) can mix both sources
> for increased resilience.
>
> Unfortunately, I'm not very familiar with the internals of x86
> bootstrapping.  Could GRUB be scripted to do a similar task?  How would
> the address and size of the seed be passed to the kernel?  command line?

One suggestion is at:
http://www.av8n.com/computer/htm/secure-random.htm#sec-boot-image

Re: [kernel-hardening] [PATCH v7 0/9] x86/mm: memory area address KASLR

[Jason Cooper]

Hey Kees, Thomas,

On Wed, Jun 22, 2016 at 10:05:51AM -0700, Kees Cook wrote:
> On Wed, Jun 22, 2016 at 8:59 AM, Thomas Garnier  wrote:
> > On Wed, Jun 22, 2016 at 5:47 AM, Jason Cooper  wrote:
> >> Hey Kees,
> >>
> >> On Tue, Jun 21, 2016 at 05:46:57PM -0700, Kees Cook wrote:
> >>> Notable problems that needed solving:
> >> ...
> >>>  - Reasonable entropy is needed early at boot before get_random_bytes()
> >>>is available.
> >>
> >> This series is targetting x86, which typically has RDRAND/RDSEED
> >> instructions.  Are you referring to other arches?  Older x86?  Also,
> >> isn't this the same requirement for base address KASLR?
> >>
> >> Don't get me wrong, I want more diverse entropy sources available
> >> earlier in the boot process as well. :-)  I'm just wondering what's
> >> different about this series vs base address KASLR wrt early entropy
> >> sources.
> >>
> >
> > I think Kees was referring to the refactor I did to get the similar
> > entropy generation than KASLR module randomization. Our approach was
> > to provide best entropy possible even if you have an older processor
> > or under virtualization without support for these instructions.
> > Unfortunately common on companies with a large number of older
> > machines.
> 
> Right, the memory offset KASLR uses the same routines as the kernel
> base KASLR. The issue is with older x86 systems, which continue to be
> very common.

We have the same issue in embedded. :-(  Compounded by the fact that
there is no rand instruction (at least not on ARM).  So, even if there's
a HW-RNG, you can't access it until the driver is loaded.

This is compounded by the fact that most systems deployed today have
bootloaders a) without hw-rng drivers, b) without dtb editing, and c)
without dtb support at all.

My current thinking is to add a devicetree property
"userspace,random-seed" .  This way, existing, deployed
boards can append a dtb to a modern kernel with the property set.
The factory bootloader then only needs to amend its boot scripts to read
random-seed from the fs to the given address.

Modern systems that receive a seed from the bootloader via the
random-seed property (typically from the hw-rng) can mix both sources
for increased resilience.

Unfortunately, I'm not very familiar with the internals of x86
bootstrapping.  Could GRUB be scripted to do a similar task?  How would
the address and size of the seed be passed to the kernel?  command line?

thx,

Jason.

Re: [kernel-hardening] [PATCH v7 0/9] x86/mm: memory area address KASLR

[Jason Cooper]

Hey Kees, Thomas,

On Wed, Jun 22, 2016 at 10:05:51AM -0700, Kees Cook wrote:
> On Wed, Jun 22, 2016 at 8:59 AM, Thomas Garnier  wrote:
> > On Wed, Jun 22, 2016 at 5:47 AM, Jason Cooper  wrote:
> >> Hey Kees,
> >>
> >> On Tue, Jun 21, 2016 at 05:46:57PM -0700, Kees Cook wrote:
> >>> Notable problems that needed solving:
> >> ...
> >>>  - Reasonable entropy is needed early at boot before get_random_bytes()
> >>>is available.
> >>
> >> This series is targetting x86, which typically has RDRAND/RDSEED
> >> instructions.  Are you referring to other arches?  Older x86?  Also,
> >> isn't this the same requirement for base address KASLR?
> >>
> >> Don't get me wrong, I want more diverse entropy sources available
> >> earlier in the boot process as well. :-)  I'm just wondering what's
> >> different about this series vs base address KASLR wrt early entropy
> >> sources.
> >>
> >
> > I think Kees was referring to the refactor I did to get the similar
> > entropy generation than KASLR module randomization. Our approach was
> > to provide best entropy possible even if you have an older processor
> > or under virtualization without support for these instructions.
> > Unfortunately common on companies with a large number of older
> > machines.
> 
> Right, the memory offset KASLR uses the same routines as the kernel
> base KASLR. The issue is with older x86 systems, which continue to be
> very common.

We have the same issue in embedded. :-(  Compounded by the fact that
there is no rand instruction (at least not on ARM).  So, even if there's
a HW-RNG, you can't access it until the driver is loaded.

This is compounded by the fact that most systems deployed today have
bootloaders a) without hw-rng drivers, b) without dtb editing, and c)
without dtb support at all.

My current thinking is to add a devicetree property
"userspace,random-seed" .  This way, existing, deployed
boards can append a dtb to a modern kernel with the property set.
The factory bootloader then only needs to amend its boot scripts to read
random-seed from the fs to the given address.

Modern systems that receive a seed from the bootloader via the
random-seed property (typically from the hw-rng) can mix both sources
for increased resilience.

Unfortunately, I'm not very familiar with the internals of x86
bootstrapping.  Could GRUB be scripted to do a similar task?  How would
the address and size of the seed be passed to the kernel?  command line?

thx,

Jason.

Re: [kernel-hardening] [PATCH v7 0/9] x86/mm: memory area address KASLR

[Kees Cook]

On Wed, Jun 22, 2016 at 8:59 AM, Thomas Garnier  wrote:
> On Wed, Jun 22, 2016 at 5:47 AM, Jason Cooper  wrote:
>> Hey Kees,
>>
>> On Tue, Jun 21, 2016 at 05:46:57PM -0700, Kees Cook wrote:
>>> Notable problems that needed solving:
>> ...
>>>  - Reasonable entropy is needed early at boot before get_random_bytes()
>>>is available.
>>
>> This series is targetting x86, which typically has RDRAND/RDSEED
>> instructions.  Are you referring to other arches?  Older x86?  Also,
>> isn't this the same requirement for base address KASLR?
>>
>> Don't get me wrong, I want more diverse entropy sources available
>> earlier in the boot process as well. :-)  I'm just wondering what's
>> different about this series vs base address KASLR wrt early entropy
>> sources.
>>
>
> I think Kees was referring to the refactor I did to get the similar
> entropy generation than KASLR module randomization. Our approach was
> to provide best entropy possible even if you have an older processor
> or under virtualization without support for these instructions.
> Unfortunately common on companies with a large number of older
> machines.

Right, the memory offset KASLR uses the same routines as the kernel
base KASLR. The issue is with older x86 systems, which continue to be
very common.

-Kees

-- 
Kees Cook
Chrome OS & Brillo Security

Re: [kernel-hardening] [PATCH v7 0/9] x86/mm: memory area address KASLR

[Kees Cook]

On Wed, Jun 22, 2016 at 8:59 AM, Thomas Garnier  wrote:
> On Wed, Jun 22, 2016 at 5:47 AM, Jason Cooper  wrote:
>> Hey Kees,
>>
>> On Tue, Jun 21, 2016 at 05:46:57PM -0700, Kees Cook wrote:
>>> Notable problems that needed solving:
>> ...
>>>  - Reasonable entropy is needed early at boot before get_random_bytes()
>>>is available.
>>
>> This series is targetting x86, which typically has RDRAND/RDSEED
>> instructions.  Are you referring to other arches?  Older x86?  Also,
>> isn't this the same requirement for base address KASLR?
>>
>> Don't get me wrong, I want more diverse entropy sources available
>> earlier in the boot process as well. :-)  I'm just wondering what's
>> different about this series vs base address KASLR wrt early entropy
>> sources.
>>
>
> I think Kees was referring to the refactor I did to get the similar
> entropy generation than KASLR module randomization. Our approach was
> to provide best entropy possible even if you have an older processor
> or under virtualization without support for these instructions.
> Unfortunately common on companies with a large number of older
> machines.

Right, the memory offset KASLR uses the same routines as the kernel
base KASLR. The issue is with older x86 systems, which continue to be
very common.

-Kees

-- 
Kees Cook
Chrome OS & Brillo Security

Re: [kernel-hardening] [PATCH v7 0/9] x86/mm: memory area address KASLR

[Thomas Garnier]

On Wed, Jun 22, 2016 at 5:47 AM, Jason Cooper  wrote:
> Hey Kees,
>
> On Tue, Jun 21, 2016 at 05:46:57PM -0700, Kees Cook wrote:
>> Notable problems that needed solving:
> ...
>>  - Reasonable entropy is needed early at boot before get_random_bytes()
>>is available.
>
> This series is targetting x86, which typically has RDRAND/RDSEED
> instructions.  Are you referring to other arches?  Older x86?  Also,
> isn't this the same requirement for base address KASLR?
>
> Don't get me wrong, I want more diverse entropy sources available
> earlier in the boot process as well. :-)  I'm just wondering what's
> different about this series vs base address KASLR wrt early entropy
> sources.
>

I think Kees was referring to the refactor I did to get the similar
entropy generation than KASLR module randomization. Our approach was
to provide best entropy possible even if you have an older processor
or under virtualization without support for these instructions.
Unfortunately common on companies with a large number of older
machines.

> thx,
>
> Jason.

Thanks,
Thomas

Re: [kernel-hardening] [PATCH v7 0/9] x86/mm: memory area address KASLR

[Thomas Garnier]

On Wed, Jun 22, 2016 at 5:47 AM, Jason Cooper  wrote:
> Hey Kees,
>
> On Tue, Jun 21, 2016 at 05:46:57PM -0700, Kees Cook wrote:
>> Notable problems that needed solving:
> ...
>>  - Reasonable entropy is needed early at boot before get_random_bytes()
>>is available.
>
> This series is targetting x86, which typically has RDRAND/RDSEED
> instructions.  Are you referring to other arches?  Older x86?  Also,
> isn't this the same requirement for base address KASLR?
>
> Don't get me wrong, I want more diverse entropy sources available
> earlier in the boot process as well. :-)  I'm just wondering what's
> different about this series vs base address KASLR wrt early entropy
> sources.
>

I think Kees was referring to the refactor I did to get the similar
entropy generation than KASLR module randomization. Our approach was
to provide best entropy possible even if you have an older processor
or under virtualization without support for these instructions.
Unfortunately common on companies with a large number of older
machines.

> thx,
>
> Jason.

Thanks,
Thomas

Re: [kernel-hardening] [PATCH v7 0/9] x86/mm: memory area address KASLR

[Jason Cooper]

Hey Kees,

On Tue, Jun 21, 2016 at 05:46:57PM -0700, Kees Cook wrote:
> Notable problems that needed solving:
...
>  - Reasonable entropy is needed early at boot before get_random_bytes()
>is available.

This series is targetting x86, which typically has RDRAND/RDSEED
instructions.  Are you referring to other arches?  Older x86?  Also,
isn't this the same requirement for base address KASLR?

Don't get me wrong, I want more diverse entropy sources available
earlier in the boot process as well. :-)  I'm just wondering what's
different about this series vs base address KASLR wrt early entropy
sources.

thx,

Jason.

Re: [kernel-hardening] [PATCH v7 0/9] x86/mm: memory area address KASLR

[Jason Cooper]

Hey Kees,

On Tue, Jun 21, 2016 at 05:46:57PM -0700, Kees Cook wrote:
> Notable problems that needed solving:
...
>  - Reasonable entropy is needed early at boot before get_random_bytes()
>is available.

This series is targetting x86, which typically has RDRAND/RDSEED
instructions.  Are you referring to other arches?  Older x86?  Also,
isn't this the same requirement for base address KASLR?

Don't get me wrong, I want more diverse entropy sources available
earlier in the boot process as well. :-)  I'm just wondering what's
different about this series vs base address KASLR wrt early entropy
sources.

thx,

Jason.