On 10 April 2017 at 10:41, Mark Rutland wrote:
> On Fri, Apr 07, 2017 at 04:51:16PM +0100, Ard Biesheuvel wrote:
>> On 7 April 2017 at 16:47, James Morse wrote:
>> > On 24/03/17 13:24, Ard Biesheuvel wrote:
>> >> Update the allocation logic for the
On Fri, Apr 07, 2017 at 04:51:16PM +0100, Ard Biesheuvel wrote:
> On 7 April 2017 at 16:47, James Morse wrote:
> > On 24/03/17 13:24, Ard Biesheuvel wrote:
> >> Update the allocation logic for the virtual mapping of the UEFI runtime
> >> services to start from a randomized
Hi Ard,
On 07/04/17 16:51, Ard Biesheuvel wrote:
> That is quite interesting, to be honest, because that patch should
> effectively be a NOP on systems that do not implement
> EFI_RNG_PROTOCOL.
>
> Could you run this from the UEFI shell please?
>
>
On 7 April 2017 at 16:47, James Morse wrote:
> Hi Ard,
>
> On 24/03/17 13:24, Ard Biesheuvel wrote:
>> Update the allocation logic for the virtual mapping of the UEFI runtime
>> services to start from a randomized base address if KASLR is in effect,
>> and if the UEFI
Hi Ard,
On 24/03/17 13:24, Ard Biesheuvel wrote:
> Update the allocation logic for the virtual mapping of the UEFI runtime
> services to start from a randomized base address if KASLR is in effect,
> and if the UEFI firmware exposes an implementation of EFI_RNG_PROTOCOL.
>
> This makes it more
Update the allocation logic for the virtual mapping of the UEFI runtime
services to start from a randomized base address if KASLR is in effect,
and if the UEFI firmware exposes an implementation of EFI_RNG_PROTOCOL.
This makes it more difficult to predict the location of exploitable
data