All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ard Biesheuvel <ard.biesheuvel@linaro.org>
To: Matt Fleming <matt@codeblueprint.co.uk>
Cc: "linux-arm-kernel@lists.infradead.org" 
	<linux-arm-kernel@lists.infradead.org>,
	kernel-hardening@lists.openwall.com,
	Will Deacon <will.deacon@arm.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Mark Rutland <mark.rutland@arm.com>,
	Leif Lindholm <leif.lindholm@linaro.org>,
	Kees Cook <keescook@chromium.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Stuart Yoder <stuart.yoder@freescale.com>,
	Sharma Bhupesh <bhupesh.sharma@freescale.com>,
	Arnd Bergmann <arnd@arndb.de>,
	Marc Zyngier <marc.zyngier@arm.com>,
	Christoffer Dall <christoffer.dall@linaro.org>
Subject: Re: [PATCH v3 19/21] efi: stub: add implementation of efi_random_alloc()
Date: Thu, 21 Jan 2016 17:16:20 +0100	[thread overview]
Message-ID: <CAKv+Gu83G81SW5hd+9oD=C=n01ROCr5iu7Nya1fijYHuV+YJWQ@mail.gmail.com> (raw)
In-Reply-To: <20160121161006.GF2510@codeblueprint.co.uk>

On 21 January 2016 at 17:10, Matt Fleming <matt@codeblueprint.co.uk> wrote:
> On Mon, 11 Jan, at 02:19:13PM, Ard Biesheuvel wrote:
>> This implements efi_random_alloc(), which allocates a chunk of memory of
>> a certain size at a certain alignment, and uses the random_seed argument
>> it receives to randomize the offset of the allocation.
>
> s/offset/address/ ?
>
> I see what you're getting at with the word "offset" but ultimately,
> this is a memory allocation function, and it returns an address.
>
> "offset" implies to me that the implementation allocates a larger
> memory chunk than is required and returns an address that is >= the
> start of the bigger-than-required-allocation.
>

Well, offset is horribly overloaded in our world, so let's stick with 'address'

>> This is implemented by iterating over the UEFI memory map, counting the
>> number of suitable slots (aligned offsets) within each region, and picking
>> a random number between 0 and 'number of slots - 1' to select the slot,
>> This should guarantee that each possible offset is chosen equally likely.
>>
>> Suggested-by: Kees Cook <keescook@chromium.org>
>> Cc: Matt Fleming <matt@codeblueprint.co.uk>
>> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
>> ---
>>  drivers/firmware/efi/libstub/efistub.h |  4 +
>>  drivers/firmware/efi/libstub/random.c  | 85 ++++++++++++++++++++
>>  2 files changed, 89 insertions(+)
>>
>> diff --git a/drivers/firmware/efi/libstub/efistub.h b/drivers/firmware/efi/libstub/efistub.h
>> index 206b7252b9d1..7a38e29da53d 100644
>> --- a/drivers/firmware/efi/libstub/efistub.h
>> +++ b/drivers/firmware/efi/libstub/efistub.h
>> @@ -46,4 +46,8 @@ void efi_get_virtmap(efi_memory_desc_t *memory_map, unsigned long map_size,
>>  efi_status_t efi_get_random_bytes(efi_system_table_t *sys_table,
>>                                 unsigned long size, u8 *out);
>>
>> +efi_status_t efi_random_alloc(efi_system_table_t *sys_table_arg,
>> +                           unsigned long size, unsigned long align_bits,
>> +                           unsigned long *addr, unsigned long random_seed);
>> +
>>  #endif
>> diff --git a/drivers/firmware/efi/libstub/random.c b/drivers/firmware/efi/libstub/random.c
>> index f539b1e31459..d4829824508c 100644
>> --- a/drivers/firmware/efi/libstub/random.c
>> +++ b/drivers/firmware/efi/libstub/random.c
>> @@ -33,3 +33,88 @@ efi_status_t efi_get_random_bytes(efi_system_table_t *sys_table,
>>
>>       return rng->get_rng(rng, NULL, size, out);
>>  }
>> +
>> +/*
>> + * Return a weight for a memory entry depending on how many offsets it covers
>> + * that are suitably aligned and supply enough room for the allocation.
>> + */
>> +static unsigned long get_entry_weight(efi_memory_desc_t *md, unsigned long size,
>> +                                   unsigned long align_bits)
>> +{
>> +     u64 start, end;
>> +
>> +     if (md->type != EFI_CONVENTIONAL_MEMORY)
>> +             return 0;
>> +
>> +     if (!(md->attribute & EFI_MEMORY_WB))
>> +             return 0;
>
> This could do with a comment. When would EFI_CONVENTIONAL_MEMORY not
> have this attribute capability in the memory map?
>

Actually, I think I should drop it instead. The other alloc functions
only check for EFI_CONVENTIONAL_MEMORY, and this is intended to be
generic code. Also, I have never seen a system with
EFI_CONVENTIONAL_MEMORY with the WB bit cleared.

>> +
>> +     start = round_up(md->phys_addr, 1 << align_bits);
>> +     end = round_down(md->phys_addr + md->num_pages * EFI_PAGE_SIZE - size,
>> +                      1 << align_bits);
>> +
>> +     if (start >= end)
>> +             return 0;
>> +
>> +     return (end - start) >> align_bits;
>> +}
>> +
>> +/*
>> + * The UEFI memory descriptors have a virtual address field that is only used
>> + * when installing the virtual mapping using SetVirtualAddressMap(). Since it
>> + * is unused here, we can reuse it to keep track of each descriptor's weight.
>> + */
>> +#define MD_WEIGHT(md)        ((md)->virt_addr)
>> +
>> +efi_status_t efi_random_alloc(efi_system_table_t *sys_table_arg,
>> +                           unsigned long size, unsigned long align_bits,
>> +                           unsigned long *addr, unsigned long random_seed)
>> +{
>> +     unsigned long map_size, desc_size, max_weight = 0, target;
>> +     efi_memory_desc_t *memory_map;
>> +     efi_status_t status = EFI_NOT_FOUND;
>> +     int l;
>
> Could you pick a more descriptive variable name?
>

Sure :-)

>> +
>> +     status = efi_get_memory_map(sys_table_arg, &memory_map, &map_size,
>> +                                 &desc_size, NULL, NULL);
>> +     if (status != EFI_SUCCESS)
>> +             return status;
>> +
>> +     /* assign each entry in the memory map a weight */
>> +     for (l = 0; l < map_size; l += desc_size) {
>> +             efi_memory_desc_t *md = (void *)memory_map + l;
>> +             unsigned long weight;
>> +
>> +             weight = get_entry_weight(md, size, align_bits);
>> +             MD_WEIGHT(md) = weight;
>> +             max_weight += weight;
>> +     }
>> +
>> +     /* find a random number between 0 and max_weight */
>> +     target = (max_weight * (u16)random_seed) >> 16;
>> +
>> +     /* find the entry whose accumulated weight covers the target */
>> +     for (l = 0; l < map_size; l += desc_size) {
>> +             efi_memory_desc_t *md = (void *)memory_map + l;
>> +
>> +             if (target < MD_WEIGHT(md)) {
>> +                     unsigned long pages;
>> +
>> +                     *addr = round_up(md->phys_addr, 1 << align_bits) +
>> +                             (target << align_bits);
>> +                     pages = round_up(size, EFI_PAGE_SIZE) / EFI_PAGE_SIZE;
>> +
>> +                     status = efi_call_early(allocate_pages,
>> +                                             EFI_ALLOCATE_ADDRESS,
>> +                                             EFI_LOADER_DATA,
>> +                                             pages,
>> +                                             (efi_physical_addr_t *)addr);
>
> You're mixing data types here. efi_physical_addr_t is always 64-bits,
> but 'addr' is unsigned long, which is 32-bits on 32-bit platforms.
> This cast isn't safe.
>

OK, I will fix that.

>> +                     break;
>> +             }
>> +             target -= MD_WEIGHT(md);
>
> I think this needs a comment.

Sure. Note that in my local version, I already replaced max_weight
with total_weight since it wasn't entirely accurate. So I'll try to
pick a better name for target as well.

Thanks,
Ard.

WARNING: multiple messages have this Message-ID (diff)
From: ard.biesheuvel@linaro.org (Ard Biesheuvel)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v3 19/21] efi: stub: add implementation of efi_random_alloc()
Date: Thu, 21 Jan 2016 17:16:20 +0100	[thread overview]
Message-ID: <CAKv+Gu83G81SW5hd+9oD=C=n01ROCr5iu7Nya1fijYHuV+YJWQ@mail.gmail.com> (raw)
In-Reply-To: <20160121161006.GF2510@codeblueprint.co.uk>

On 21 January 2016 at 17:10, Matt Fleming <matt@codeblueprint.co.uk> wrote:
> On Mon, 11 Jan, at 02:19:13PM, Ard Biesheuvel wrote:
>> This implements efi_random_alloc(), which allocates a chunk of memory of
>> a certain size at a certain alignment, and uses the random_seed argument
>> it receives to randomize the offset of the allocation.
>
> s/offset/address/ ?
>
> I see what you're getting at with the word "offset" but ultimately,
> this is a memory allocation function, and it returns an address.
>
> "offset" implies to me that the implementation allocates a larger
> memory chunk than is required and returns an address that is >= the
> start of the bigger-than-required-allocation.
>

Well, offset is horribly overloaded in our world, so let's stick with 'address'

>> This is implemented by iterating over the UEFI memory map, counting the
>> number of suitable slots (aligned offsets) within each region, and picking
>> a random number between 0 and 'number of slots - 1' to select the slot,
>> This should guarantee that each possible offset is chosen equally likely.
>>
>> Suggested-by: Kees Cook <keescook@chromium.org>
>> Cc: Matt Fleming <matt@codeblueprint.co.uk>
>> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
>> ---
>>  drivers/firmware/efi/libstub/efistub.h |  4 +
>>  drivers/firmware/efi/libstub/random.c  | 85 ++++++++++++++++++++
>>  2 files changed, 89 insertions(+)
>>
>> diff --git a/drivers/firmware/efi/libstub/efistub.h b/drivers/firmware/efi/libstub/efistub.h
>> index 206b7252b9d1..7a38e29da53d 100644
>> --- a/drivers/firmware/efi/libstub/efistub.h
>> +++ b/drivers/firmware/efi/libstub/efistub.h
>> @@ -46,4 +46,8 @@ void efi_get_virtmap(efi_memory_desc_t *memory_map, unsigned long map_size,
>>  efi_status_t efi_get_random_bytes(efi_system_table_t *sys_table,
>>                                 unsigned long size, u8 *out);
>>
>> +efi_status_t efi_random_alloc(efi_system_table_t *sys_table_arg,
>> +                           unsigned long size, unsigned long align_bits,
>> +                           unsigned long *addr, unsigned long random_seed);
>> +
>>  #endif
>> diff --git a/drivers/firmware/efi/libstub/random.c b/drivers/firmware/efi/libstub/random.c
>> index f539b1e31459..d4829824508c 100644
>> --- a/drivers/firmware/efi/libstub/random.c
>> +++ b/drivers/firmware/efi/libstub/random.c
>> @@ -33,3 +33,88 @@ efi_status_t efi_get_random_bytes(efi_system_table_t *sys_table,
>>
>>       return rng->get_rng(rng, NULL, size, out);
>>  }
>> +
>> +/*
>> + * Return a weight for a memory entry depending on how many offsets it covers
>> + * that are suitably aligned and supply enough room for the allocation.
>> + */
>> +static unsigned long get_entry_weight(efi_memory_desc_t *md, unsigned long size,
>> +                                   unsigned long align_bits)
>> +{
>> +     u64 start, end;
>> +
>> +     if (md->type != EFI_CONVENTIONAL_MEMORY)
>> +             return 0;
>> +
>> +     if (!(md->attribute & EFI_MEMORY_WB))
>> +             return 0;
>
> This could do with a comment. When would EFI_CONVENTIONAL_MEMORY not
> have this attribute capability in the memory map?
>

Actually, I think I should drop it instead. The other alloc functions
only check for EFI_CONVENTIONAL_MEMORY, and this is intended to be
generic code. Also, I have never seen a system with
EFI_CONVENTIONAL_MEMORY with the WB bit cleared.

>> +
>> +     start = round_up(md->phys_addr, 1 << align_bits);
>> +     end = round_down(md->phys_addr + md->num_pages * EFI_PAGE_SIZE - size,
>> +                      1 << align_bits);
>> +
>> +     if (start >= end)
>> +             return 0;
>> +
>> +     return (end - start) >> align_bits;
>> +}
>> +
>> +/*
>> + * The UEFI memory descriptors have a virtual address field that is only used
>> + * when installing the virtual mapping using SetVirtualAddressMap(). Since it
>> + * is unused here, we can reuse it to keep track of each descriptor's weight.
>> + */
>> +#define MD_WEIGHT(md)        ((md)->virt_addr)
>> +
>> +efi_status_t efi_random_alloc(efi_system_table_t *sys_table_arg,
>> +                           unsigned long size, unsigned long align_bits,
>> +                           unsigned long *addr, unsigned long random_seed)
>> +{
>> +     unsigned long map_size, desc_size, max_weight = 0, target;
>> +     efi_memory_desc_t *memory_map;
>> +     efi_status_t status = EFI_NOT_FOUND;
>> +     int l;
>
> Could you pick a more descriptive variable name?
>

Sure :-)

>> +
>> +     status = efi_get_memory_map(sys_table_arg, &memory_map, &map_size,
>> +                                 &desc_size, NULL, NULL);
>> +     if (status != EFI_SUCCESS)
>> +             return status;
>> +
>> +     /* assign each entry in the memory map a weight */
>> +     for (l = 0; l < map_size; l += desc_size) {
>> +             efi_memory_desc_t *md = (void *)memory_map + l;
>> +             unsigned long weight;
>> +
>> +             weight = get_entry_weight(md, size, align_bits);
>> +             MD_WEIGHT(md) = weight;
>> +             max_weight += weight;
>> +     }
>> +
>> +     /* find a random number between 0 and max_weight */
>> +     target = (max_weight * (u16)random_seed) >> 16;
>> +
>> +     /* find the entry whose accumulated weight covers the target */
>> +     for (l = 0; l < map_size; l += desc_size) {
>> +             efi_memory_desc_t *md = (void *)memory_map + l;
>> +
>> +             if (target < MD_WEIGHT(md)) {
>> +                     unsigned long pages;
>> +
>> +                     *addr = round_up(md->phys_addr, 1 << align_bits) +
>> +                             (target << align_bits);
>> +                     pages = round_up(size, EFI_PAGE_SIZE) / EFI_PAGE_SIZE;
>> +
>> +                     status = efi_call_early(allocate_pages,
>> +                                             EFI_ALLOCATE_ADDRESS,
>> +                                             EFI_LOADER_DATA,
>> +                                             pages,
>> +                                             (efi_physical_addr_t *)addr);
>
> You're mixing data types here. efi_physical_addr_t is always 64-bits,
> but 'addr' is unsigned long, which is 32-bits on 32-bit platforms.
> This cast isn't safe.
>

OK, I will fix that.

>> +                     break;
>> +             }
>> +             target -= MD_WEIGHT(md);
>
> I think this needs a comment.

Sure. Note that in my local version, I already replaced max_weight
with total_weight since it wasn't entirely accurate. So I'll try to
pick a better name for target as well.

Thanks,
Ard.

WARNING: multiple messages have this Message-ID (diff)
From: Ard Biesheuvel <ard.biesheuvel@linaro.org>
To: Matt Fleming <matt@codeblueprint.co.uk>
Cc: "linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>,
	kernel-hardening@lists.openwall.com,
	Will Deacon <will.deacon@arm.com>,
	Catalin Marinas <catalin.marinas@arm.com>,
	Mark Rutland <mark.rutland@arm.com>,
	Leif Lindholm <leif.lindholm@linaro.org>,
	Kees Cook <keescook@chromium.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	Stuart Yoder <stuart.yoder@freescale.com>,
	Sharma Bhupesh <bhupesh.sharma@freescale.com>,
	Arnd Bergmann <arnd@arndb.de>,
	Marc Zyngier <marc.zyngier@arm.com>,
	Christoffer Dall <christoffer.dall@linaro.org>
Subject: [kernel-hardening] Re: [PATCH v3 19/21] efi: stub: add implementation of efi_random_alloc()
Date: Thu, 21 Jan 2016 17:16:20 +0100	[thread overview]
Message-ID: <CAKv+Gu83G81SW5hd+9oD=C=n01ROCr5iu7Nya1fijYHuV+YJWQ@mail.gmail.com> (raw)
In-Reply-To: <20160121161006.GF2510@codeblueprint.co.uk>

On 21 January 2016 at 17:10, Matt Fleming <matt@codeblueprint.co.uk> wrote:
> On Mon, 11 Jan, at 02:19:13PM, Ard Biesheuvel wrote:
>> This implements efi_random_alloc(), which allocates a chunk of memory of
>> a certain size at a certain alignment, and uses the random_seed argument
>> it receives to randomize the offset of the allocation.
>
> s/offset/address/ ?
>
> I see what you're getting at with the word "offset" but ultimately,
> this is a memory allocation function, and it returns an address.
>
> "offset" implies to me that the implementation allocates a larger
> memory chunk than is required and returns an address that is >= the
> start of the bigger-than-required-allocation.
>

Well, offset is horribly overloaded in our world, so let's stick with 'address'

>> This is implemented by iterating over the UEFI memory map, counting the
>> number of suitable slots (aligned offsets) within each region, and picking
>> a random number between 0 and 'number of slots - 1' to select the slot,
>> This should guarantee that each possible offset is chosen equally likely.
>>
>> Suggested-by: Kees Cook <keescook@chromium.org>
>> Cc: Matt Fleming <matt@codeblueprint.co.uk>
>> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
>> ---
>>  drivers/firmware/efi/libstub/efistub.h |  4 +
>>  drivers/firmware/efi/libstub/random.c  | 85 ++++++++++++++++++++
>>  2 files changed, 89 insertions(+)
>>
>> diff --git a/drivers/firmware/efi/libstub/efistub.h b/drivers/firmware/efi/libstub/efistub.h
>> index 206b7252b9d1..7a38e29da53d 100644
>> --- a/drivers/firmware/efi/libstub/efistub.h
>> +++ b/drivers/firmware/efi/libstub/efistub.h
>> @@ -46,4 +46,8 @@ void efi_get_virtmap(efi_memory_desc_t *memory_map, unsigned long map_size,
>>  efi_status_t efi_get_random_bytes(efi_system_table_t *sys_table,
>>                                 unsigned long size, u8 *out);
>>
>> +efi_status_t efi_random_alloc(efi_system_table_t *sys_table_arg,
>> +                           unsigned long size, unsigned long align_bits,
>> +                           unsigned long *addr, unsigned long random_seed);
>> +
>>  #endif
>> diff --git a/drivers/firmware/efi/libstub/random.c b/drivers/firmware/efi/libstub/random.c
>> index f539b1e31459..d4829824508c 100644
>> --- a/drivers/firmware/efi/libstub/random.c
>> +++ b/drivers/firmware/efi/libstub/random.c
>> @@ -33,3 +33,88 @@ efi_status_t efi_get_random_bytes(efi_system_table_t *sys_table,
>>
>>       return rng->get_rng(rng, NULL, size, out);
>>  }
>> +
>> +/*
>> + * Return a weight for a memory entry depending on how many offsets it covers
>> + * that are suitably aligned and supply enough room for the allocation.
>> + */
>> +static unsigned long get_entry_weight(efi_memory_desc_t *md, unsigned long size,
>> +                                   unsigned long align_bits)
>> +{
>> +     u64 start, end;
>> +
>> +     if (md->type != EFI_CONVENTIONAL_MEMORY)
>> +             return 0;
>> +
>> +     if (!(md->attribute & EFI_MEMORY_WB))
>> +             return 0;
>
> This could do with a comment. When would EFI_CONVENTIONAL_MEMORY not
> have this attribute capability in the memory map?
>

Actually, I think I should drop it instead. The other alloc functions
only check for EFI_CONVENTIONAL_MEMORY, and this is intended to be
generic code. Also, I have never seen a system with
EFI_CONVENTIONAL_MEMORY with the WB bit cleared.

>> +
>> +     start = round_up(md->phys_addr, 1 << align_bits);
>> +     end = round_down(md->phys_addr + md->num_pages * EFI_PAGE_SIZE - size,
>> +                      1 << align_bits);
>> +
>> +     if (start >= end)
>> +             return 0;
>> +
>> +     return (end - start) >> align_bits;
>> +}
>> +
>> +/*
>> + * The UEFI memory descriptors have a virtual address field that is only used
>> + * when installing the virtual mapping using SetVirtualAddressMap(). Since it
>> + * is unused here, we can reuse it to keep track of each descriptor's weight.
>> + */
>> +#define MD_WEIGHT(md)        ((md)->virt_addr)
>> +
>> +efi_status_t efi_random_alloc(efi_system_table_t *sys_table_arg,
>> +                           unsigned long size, unsigned long align_bits,
>> +                           unsigned long *addr, unsigned long random_seed)
>> +{
>> +     unsigned long map_size, desc_size, max_weight = 0, target;
>> +     efi_memory_desc_t *memory_map;
>> +     efi_status_t status = EFI_NOT_FOUND;
>> +     int l;
>
> Could you pick a more descriptive variable name?
>

Sure :-)

>> +
>> +     status = efi_get_memory_map(sys_table_arg, &memory_map, &map_size,
>> +                                 &desc_size, NULL, NULL);
>> +     if (status != EFI_SUCCESS)
>> +             return status;
>> +
>> +     /* assign each entry in the memory map a weight */
>> +     for (l = 0; l < map_size; l += desc_size) {
>> +             efi_memory_desc_t *md = (void *)memory_map + l;
>> +             unsigned long weight;
>> +
>> +             weight = get_entry_weight(md, size, align_bits);
>> +             MD_WEIGHT(md) = weight;
>> +             max_weight += weight;
>> +     }
>> +
>> +     /* find a random number between 0 and max_weight */
>> +     target = (max_weight * (u16)random_seed) >> 16;
>> +
>> +     /* find the entry whose accumulated weight covers the target */
>> +     for (l = 0; l < map_size; l += desc_size) {
>> +             efi_memory_desc_t *md = (void *)memory_map + l;
>> +
>> +             if (target < MD_WEIGHT(md)) {
>> +                     unsigned long pages;
>> +
>> +                     *addr = round_up(md->phys_addr, 1 << align_bits) +
>> +                             (target << align_bits);
>> +                     pages = round_up(size, EFI_PAGE_SIZE) / EFI_PAGE_SIZE;
>> +
>> +                     status = efi_call_early(allocate_pages,
>> +                                             EFI_ALLOCATE_ADDRESS,
>> +                                             EFI_LOADER_DATA,
>> +                                             pages,
>> +                                             (efi_physical_addr_t *)addr);
>
> You're mixing data types here. efi_physical_addr_t is always 64-bits,
> but 'addr' is unsigned long, which is 32-bits on 32-bit platforms.
> This cast isn't safe.
>

OK, I will fix that.

>> +                     break;
>> +             }
>> +             target -= MD_WEIGHT(md);
>
> I think this needs a comment.

Sure. Note that in my local version, I already replaced max_weight
with total_weight since it wasn't entirely accurate. So I'll try to
pick a better name for target as well.

Thanks,
Ard.

  reply	other threads:[~2016-01-21 16:16 UTC|newest]

Thread overview: 207+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-01-11 13:18 [PATCH v3 00/21] arm64: implement support for KASLR Ard Biesheuvel
2016-01-11 13:18 ` [kernel-hardening] " Ard Biesheuvel
2016-01-11 13:18 ` Ard Biesheuvel
2016-01-11 13:18 ` [PATCH v3 01/21] of/fdt: make memblock minimum physical address arch configurable Ard Biesheuvel
2016-01-11 13:18   ` [kernel-hardening] " Ard Biesheuvel
2016-01-11 13:18   ` Ard Biesheuvel
2016-01-11 13:18 ` [PATCH v3 02/21] arm64: introduce KIMAGE_VADDR as the virtual base of the kernel region Ard Biesheuvel
2016-01-11 13:18   ` [kernel-hardening] " Ard Biesheuvel
2016-01-11 13:18   ` Ard Biesheuvel
2016-01-11 16:31   ` Mark Rutland
2016-01-11 16:31     ` [kernel-hardening] " Mark Rutland
2016-01-11 16:31     ` Mark Rutland
2016-01-11 13:18 ` [PATCH v3 03/21] arm64: pgtable: add dummy pud_index() and pmd_index() definitions Ard Biesheuvel
2016-01-11 13:18   ` [kernel-hardening] " Ard Biesheuvel
2016-01-11 13:18   ` Ard Biesheuvel
2016-01-11 17:40   ` Mark Rutland
2016-01-11 17:40     ` [kernel-hardening] " Mark Rutland
2016-01-11 17:40     ` Mark Rutland
2016-01-12 17:25     ` Ard Biesheuvel
2016-01-12 17:25       ` [kernel-hardening] " Ard Biesheuvel
2016-01-12 17:25       ` Ard Biesheuvel
2016-01-11 13:18 ` [PATCH v3 04/21] arm64: decouple early fixmap init from linear mapping Ard Biesheuvel
2016-01-11 13:18   ` [kernel-hardening] " Ard Biesheuvel
2016-01-11 13:18   ` Ard Biesheuvel
2016-01-11 16:09   ` Mark Rutland
2016-01-11 16:09     ` [kernel-hardening] " Mark Rutland
2016-01-11 16:09     ` Mark Rutland
2016-01-11 16:15     ` Ard Biesheuvel
2016-01-11 16:15       ` [kernel-hardening] " Ard Biesheuvel
2016-01-11 16:15       ` Ard Biesheuvel
2016-01-11 16:27       ` Mark Rutland
2016-01-11 16:27         ` [kernel-hardening] " Mark Rutland
2016-01-11 16:27         ` Mark Rutland
2016-01-11 16:51         ` Mark Rutland
2016-01-11 16:51           ` [kernel-hardening] " Mark Rutland
2016-01-11 16:51           ` Mark Rutland
2016-01-11 17:08           ` Ard Biesheuvel
2016-01-11 17:08             ` [kernel-hardening] " Ard Biesheuvel
2016-01-11 17:08             ` Ard Biesheuvel
2016-01-11 17:15             ` Ard Biesheuvel
2016-01-11 17:15               ` [kernel-hardening] " Ard Biesheuvel
2016-01-11 17:15               ` Ard Biesheuvel
2016-01-11 17:21               ` Mark Rutland
2016-01-11 17:21                 ` [kernel-hardening] " Mark Rutland
2016-01-11 17:21                 ` Mark Rutland
2016-01-11 13:18 ` [PATCH v3 05/21] arm64: kvm: deal with kernel symbols outside of " Ard Biesheuvel
2016-01-11 13:18   ` [kernel-hardening] " Ard Biesheuvel
2016-01-11 13:18   ` Ard Biesheuvel
2016-01-12 12:36   ` Mark Rutland
2016-01-12 12:36     ` [kernel-hardening] " Mark Rutland
2016-01-12 12:36     ` Mark Rutland
2016-01-12 13:23     ` Ard Biesheuvel
2016-01-12 13:23       ` [kernel-hardening] " Ard Biesheuvel
2016-01-12 13:23       ` Ard Biesheuvel
2016-01-11 13:18 ` [PATCH v3 06/21] arm64: pgtable: implement static [pte|pmd|pud]_offset variants Ard Biesheuvel
2016-01-11 13:18   ` [kernel-hardening] " Ard Biesheuvel
2016-01-11 13:18   ` Ard Biesheuvel
2016-01-11 16:24   ` Mark Rutland
2016-01-11 16:24     ` [kernel-hardening] " Mark Rutland
2016-01-11 16:24     ` Mark Rutland
2016-01-11 17:28     ` Ard Biesheuvel
2016-01-11 17:28       ` [kernel-hardening] " Ard Biesheuvel
2016-01-11 17:28       ` Ard Biesheuvel
2016-01-11 17:31       ` Mark Rutland
2016-01-11 17:31         ` [kernel-hardening] " Mark Rutland
2016-01-11 17:31         ` Mark Rutland
2016-01-11 13:19 ` [PATCH v3 07/21] arm64: move kernel image to base of vmalloc area Ard Biesheuvel
2016-01-11 13:19   ` [kernel-hardening] " Ard Biesheuvel
2016-01-11 13:19   ` Ard Biesheuvel
2016-01-12 18:14   ` Mark Rutland
2016-01-12 18:14     ` [kernel-hardening] " Mark Rutland
2016-01-12 18:14     ` Mark Rutland
2016-01-13  8:39     ` Ard Biesheuvel
2016-01-13  8:39       ` [kernel-hardening] " Ard Biesheuvel
2016-01-13  8:39       ` Ard Biesheuvel
2016-01-13  9:58       ` Ard Biesheuvel
2016-01-13  9:58         ` [kernel-hardening] " Ard Biesheuvel
2016-01-13  9:58         ` Ard Biesheuvel
2016-01-13 11:11         ` Mark Rutland
2016-01-13 11:11           ` [kernel-hardening] " Mark Rutland
2016-01-13 11:11           ` Mark Rutland
2016-01-13 11:14           ` Ard Biesheuvel
2016-01-13 11:14             ` [kernel-hardening] " Ard Biesheuvel
2016-01-13 11:14             ` Ard Biesheuvel
2016-01-13 13:51       ` Mark Rutland
2016-01-13 13:51         ` [kernel-hardening] " Mark Rutland
2016-01-13 13:51         ` Mark Rutland
2016-01-13 15:50         ` Ard Biesheuvel
2016-01-13 15:50           ` [kernel-hardening] " Ard Biesheuvel
2016-01-13 15:50           ` Ard Biesheuvel
2016-01-13 16:26           ` Mark Rutland
2016-01-13 16:26             ` [kernel-hardening] " Mark Rutland
2016-01-13 16:26             ` Mark Rutland
2016-01-14 18:57         ` Mark Rutland
2016-01-14 18:57           ` [kernel-hardening] " Mark Rutland
2016-01-14 18:57           ` Mark Rutland
2016-01-15  9:54           ` Ard Biesheuvel
2016-01-15  9:54             ` [kernel-hardening] " Ard Biesheuvel
2016-01-15  9:54             ` Ard Biesheuvel
2016-01-15 11:23             ` Mark Rutland
2016-01-15 11:23               ` [kernel-hardening] " Mark Rutland
2016-01-15 11:23               ` Mark Rutland
2016-01-27 14:31               ` Ard Biesheuvel
2016-01-27 14:31                 ` [kernel-hardening] " Ard Biesheuvel
2016-01-27 14:31                 ` Ard Biesheuvel
2016-01-11 13:19 ` [PATCH v3 08/21] arm64: add support for module PLTs Ard Biesheuvel
2016-01-11 13:19   ` [kernel-hardening] " Ard Biesheuvel
2016-01-11 13:19   ` Ard Biesheuvel
2016-01-22 16:55   ` Mark Rutland
2016-01-22 16:55     ` [kernel-hardening] " Mark Rutland
2016-01-22 16:55     ` Mark Rutland
2016-01-22 17:06     ` Ard Biesheuvel
2016-01-22 17:06       ` [kernel-hardening] " Ard Biesheuvel
2016-01-22 17:06       ` Ard Biesheuvel
2016-01-22 17:19       ` Mark Rutland
2016-01-22 17:19         ` [kernel-hardening] " Mark Rutland
2016-01-22 17:19         ` Mark Rutland
2016-01-11 13:19 ` [PATCH v3 09/21] extable: add support for relative extables to search and sort routines Ard Biesheuvel
2016-01-11 13:19   ` [kernel-hardening] " Ard Biesheuvel
2016-01-11 13:19   ` Ard Biesheuvel
2016-01-11 13:19 ` [PATCH v3 10/21] arm64: switch to relative exception tables Ard Biesheuvel
2016-01-11 13:19   ` [kernel-hardening] " Ard Biesheuvel
2016-01-11 13:19   ` Ard Biesheuvel
2016-01-11 13:19 ` [PATCH v3 11/21] arm64: avoid R_AARCH64_ABS64 relocations for Image header fields Ard Biesheuvel
2016-01-11 13:19   ` [kernel-hardening] " Ard Biesheuvel
2016-01-11 13:19   ` Ard Biesheuvel
2016-01-13 18:12   ` Mark Rutland
2016-01-13 18:12     ` [kernel-hardening] " Mark Rutland
2016-01-13 18:12     ` Mark Rutland
2016-01-13 18:48     ` Ard Biesheuvel
2016-01-13 18:48       ` [kernel-hardening] " Ard Biesheuvel
2016-01-13 18:48       ` Ard Biesheuvel
2016-01-14  8:51       ` Ard Biesheuvel
2016-01-14  8:51         ` [kernel-hardening] " Ard Biesheuvel
2016-01-14  8:51         ` Ard Biesheuvel
2016-01-14  9:05         ` Ard Biesheuvel
2016-01-14  9:05           ` [kernel-hardening] " Ard Biesheuvel
2016-01-14  9:05           ` Ard Biesheuvel
2016-01-14 10:46           ` Mark Rutland
2016-01-14 10:46             ` [kernel-hardening] " Mark Rutland
2016-01-14 10:46             ` Mark Rutland
2016-01-14 11:22             ` Ard Biesheuvel
2016-01-14 11:22               ` [kernel-hardening] " Ard Biesheuvel
2016-01-14 11:22               ` Ard Biesheuvel
2016-01-11 13:19 ` [PATCH v3 12/21] arm64: avoid dynamic relocations in early boot code Ard Biesheuvel
2016-01-11 13:19   ` [kernel-hardening] " Ard Biesheuvel
2016-01-11 13:19   ` Ard Biesheuvel
2016-01-14 17:09   ` Mark Rutland
2016-01-14 17:09     ` [kernel-hardening] " Mark Rutland
2016-01-14 17:09     ` Mark Rutland
2016-01-11 13:19 ` [PATCH v3 13/21] arm64: allow kernel Image to be loaded anywhere in physical memory Ard Biesheuvel
2016-01-11 13:19   ` [kernel-hardening] " Ard Biesheuvel
2016-01-11 13:19   ` Ard Biesheuvel
2016-01-11 13:19 ` [PATCH v3 14/21] arm64: redefine SWAPPER_TABLE_SHIFT for use in asm code Ard Biesheuvel
2016-01-11 13:19   ` [kernel-hardening] " Ard Biesheuvel
2016-01-11 13:19   ` Ard Biesheuvel
2016-01-11 13:19 ` [PATCH v3 14/21] arm64: [re]define SWAPPER_TABLE_[SHIFT|SIZE] " Ard Biesheuvel
2016-01-11 13:19   ` [kernel-hardening] " Ard Biesheuvel
2016-01-11 13:19   ` Ard Biesheuvel
2016-01-11 13:26   ` Ard Biesheuvel
2016-01-11 13:26     ` [kernel-hardening] " Ard Biesheuvel
2016-01-11 13:26     ` Ard Biesheuvel
2016-01-11 13:19 ` [PATCH v3 15/21] arm64: split elf relocs into a separate header Ard Biesheuvel
2016-01-11 13:19   ` [kernel-hardening] " Ard Biesheuvel
2016-01-11 13:19   ` Ard Biesheuvel
2016-01-11 13:19 ` [PATCH v3 16/21] scripts/sortextable: add support for ET_DYN binaries Ard Biesheuvel
2016-01-11 13:19   ` [kernel-hardening] " Ard Biesheuvel
2016-01-11 13:19   ` Ard Biesheuvel
2016-01-11 13:19 ` [PATCH v3 17/21] arm64: add support for a relocatable kernel and KASLR Ard Biesheuvel
2016-01-11 13:19   ` [kernel-hardening] " Ard Biesheuvel
2016-01-11 13:19   ` Ard Biesheuvel
2016-01-11 13:19 ` [PATCH v3 18/21] efi: stub: implement efi_get_random_bytes() based on EFI_RNG_PROTOCOL Ard Biesheuvel
2016-01-11 13:19   ` [kernel-hardening] " Ard Biesheuvel
2016-01-11 13:19   ` Ard Biesheuvel
2016-01-21 15:42   ` Matt Fleming
2016-01-21 15:42     ` [kernel-hardening] " Matt Fleming
2016-01-21 15:42     ` Matt Fleming
2016-01-21 16:12     ` Ard Biesheuvel
2016-01-21 16:12       ` [kernel-hardening] " Ard Biesheuvel
2016-01-21 16:12       ` Ard Biesheuvel
2016-01-11 13:19 ` [PATCH v3 19/21] efi: stub: add implementation of efi_random_alloc() Ard Biesheuvel
2016-01-11 13:19   ` [kernel-hardening] " Ard Biesheuvel
2016-01-11 13:19   ` Ard Biesheuvel
2016-01-21 16:10   ` Matt Fleming
2016-01-21 16:10     ` [kernel-hardening] " Matt Fleming
2016-01-21 16:10     ` Matt Fleming
2016-01-21 16:16     ` Ard Biesheuvel [this message]
2016-01-21 16:16       ` [kernel-hardening] " Ard Biesheuvel
2016-01-21 16:16       ` Ard Biesheuvel
2016-01-11 13:19 ` [PATCH v3 20/21] efi: stub: use high allocation for converted command line Ard Biesheuvel
2016-01-11 13:19   ` [kernel-hardening] " Ard Biesheuvel
2016-01-11 13:19   ` Ard Biesheuvel
2016-01-21 16:20   ` Matt Fleming
2016-01-21 16:20     ` [kernel-hardening] " Matt Fleming
2016-01-21 16:20     ` Matt Fleming
2016-01-11 13:19 ` [PATCH v3 21/21] arm64: efi: invoke EFI_RNG_PROTOCOL to supply KASLR randomness Ard Biesheuvel
2016-01-11 13:19   ` [kernel-hardening] " Ard Biesheuvel
2016-01-11 13:19   ` Ard Biesheuvel
2016-01-21 16:31   ` Matt Fleming
2016-01-21 16:31     ` [kernel-hardening] " Matt Fleming
2016-01-21 16:31     ` Matt Fleming
2016-01-11 22:07 ` [PATCH v3 00/21] arm64: implement support for KASLR Kees Cook
2016-01-11 22:07   ` [kernel-hardening] " Kees Cook
2016-01-11 22:07   ` Kees Cook
2016-01-12  7:17   ` Ard Biesheuvel
2016-01-12  7:17     ` [kernel-hardening] " Ard Biesheuvel
2016-01-12  7:17     ` Ard Biesheuvel

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAKv+Gu83G81SW5hd+9oD=C=n01ROCr5iu7Nya1fijYHuV+YJWQ@mail.gmail.com' \
    --to=ard.biesheuvel@linaro.org \
    --cc=arnd@arndb.de \
    --cc=bhupesh.sharma@freescale.com \
    --cc=catalin.marinas@arm.com \
    --cc=christoffer.dall@linaro.org \
    --cc=keescook@chromium.org \
    --cc=kernel-hardening@lists.openwall.com \
    --cc=leif.lindholm@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=marc.zyngier@arm.com \
    --cc=mark.rutland@arm.com \
    --cc=matt@codeblueprint.co.uk \
    --cc=stuart.yoder@freescale.com \
    --cc=will.deacon@arm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.