From: Baoquan He <bhe@redhat.com>
To: Kees Cook <keescook@chromium.org>
Cc: Ingo Molnar <mingo@kernel.org>, Ingo Molnar <mingo@redhat.com>,
Yinghai Lu <yinghai@kernel.org>, "H. Peter Anvin" <hpa@zytor.com>,
Borislav Petkov <bp@alien8.de>, Vivek Goyal <vgoyal@redhat.com>,
Andy Lutomirski <luto@kernel.org>,
Lasse Collin <lasse.collin@tukaani.org>,
Andrew Morton <akpm@linux-foundation.org>,
Dave Young <dyoung@redhat.com>,
"kernel-hardening@lists.openwall.com"
<kernel-hardening@lists.openwall.com>,
LKML <linux-kernel@vger.kernel.org>
Subject: [kernel-hardening] Re: [PATCH v6 10/11] x86/KASLR: Add physical address randomization >4G
Date: Sun, 8 May 2016 17:17:30 +0800 [thread overview]
Message-ID: <20160508091730.GA2355@x1> (raw)
In-Reply-To: <CAGXu5jLA38thQAa6Uj0YCFvwGgus2a21GaFsD8PcD1ZvhS+Wkg@mail.gmail.com>
On 05/06/16 at 08:31am, Kees Cook wrote:
> On Fri, May 6, 2016 at 1:27 AM, Baoquan He <bhe@redhat.com> wrote:
> > Hi Kees,
> >
> > On 05/05/16 at 03:13pm, Kees Cook wrote:
> >> From: Baoquan He <bhe@redhat.com>
> >>
> >> This patch exchanges the prior slots[] array for the new slot_areas[]
> >> array, and lifts the limitation of KERNEL_IMAGE_SIZE on the physical
> >> address offset for 64-bit. As before, process_e820_entry() walks
> >
> > Sorry, I didn't get what you said about lifting the limitation for
> > 64-bit. Do you mean 32-bit?
>
> Prior to this patch, physical address randomization was limited to
> KERNEL_IMAGE_SIZE on x86_64. After this patch, that limit is lifted
> for x86_64 but 32-bit remains limited to KERNEL_IMAGE_SIZE being the
> upper physical memory position.
Ah, yes. This is lifting the limitation of physical addr from
KERNEL_IMAGE_SIZE to max available physical addr. I must have been
dizzy, please forgive my noise.
>
> >
> > Thanks
> > Baoquan
> >
> >
> >> memory and populates slot_areas[], splitting on any detected mem_avoid
> >> collisions.
> >>
> >> Finally, since the slots[] array and its associated functions are not
> >> needed any more, so they are removed.
> >>
> >> Signed-off-by: Baoquan He <bhe@redhat.com>
> >> [kees: rewrote changelog, refactored goto into while]
> >> [kees: limit 32-bit to KERNEL_IMAGE_SIZE]
> >> [kees: squash dead-code removal into this patch]
> >> [kees: refactored to use new mem_overlap code, renamed variables]
> >> [kees: updated Kconfig to reflect updated implementation]
> >> Signed-off-by: Kees Cook <keescook@chromium.org>
> >> ---
> >> arch/x86/Kconfig | 27 +++++----
> >> arch/x86/boot/compressed/kaslr.c | 115 +++++++++++++++++++++++----------------
> >> 2 files changed, 85 insertions(+), 57 deletions(-)
> >>
> >> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> >> index 5892d549596d..39be0f7b49ef 100644
> >> --- a/arch/x86/Kconfig
> >> +++ b/arch/x86/Kconfig
> >> @@ -1943,21 +1943,26 @@ config RANDOMIZE_BASE
> >> attempts relying on knowledge of the location of kernel
> >> code internals.
> >>
> >> - The kernel physical and virtual address can be randomized
> >> - from 16MB up to 1GB on 64-bit and 512MB on 32-bit. (Note that
> >> - using RANDOMIZE_BASE reduces the memory space available to
> >> - kernel modules from 1.5GB to 1GB.)
> >> + On 64-bit, the kernel physical and virtual addresses are
> >> + randomized separately. The physical address will be anywhere
> >> + between 16MB and the top of physical memory (up to 64TB). The
> >> + virtual address will be randomized from 16MB up to 1GB (9 bits
> >> + of entropy). Note that this also reduces the memory space
> >> + available to kernel modules from 1.5GB to 1GB.
> >> +
> >> + On 32-bit, the kernel physical and virtual addresses are
> >> + randomized together. They will be randomized from 16MB up to
> >> + 512MB (8 bits of entropy).
> >>
> >> Entropy is generated using the RDRAND instruction if it is
> >> supported. If RDTSC is supported, its value is mixed into
> >> the entropy pool as well. If neither RDRAND nor RDTSC are
> >> - supported, then entropy is read from the i8254 timer.
> >> -
> >> - Since the kernel is built using 2GB addressing, and
> >> - PHYSICAL_ALIGN must be at a minimum of 2MB, only 10 bits of
> >> - entropy is theoretically possible. Currently, with the
> >> - default value for PHYSICAL_ALIGN and due to page table
> >> - layouts, 64-bit uses 9 bits of entropy and 32-bit uses 8 bits.
> >> + supported, then entropy is read from the i8254 timer. The
> >> + usable entropy is limited by the kernel being built using
> >> + 2GB addressing, and that PHYSICAL_ALIGN must be at a
> >> + minimum of 2MB. As a result, only 10 bits of entropy is
> >> + theoretically possible, but the implementations are further
> >> + limited due to memory layouts.
> >>
> >> If CONFIG_HIBERNATE is also enabled, KASLR is disabled at boot
> >> time. To enable it, boot with "kaslr" on the kernel command
> >> diff --git a/arch/x86/boot/compressed/kaslr.c b/arch/x86/boot/compressed/kaslr.c
> >> index 58d0871be037..8cf705826bdc 100644
> >> --- a/arch/x86/boot/compressed/kaslr.c
> >> +++ b/arch/x86/boot/compressed/kaslr.c
> >> @@ -125,17 +125,6 @@ struct mem_vector {
> >> #define MEM_AVOID_MAX 4
> >> static struct mem_vector mem_avoid[MEM_AVOID_MAX];
> >>
> >> -static bool mem_contains(struct mem_vector *region, struct mem_vector *item)
> >> -{
> >> - /* Item at least partially before region. */
> >> - if (item->start < region->start)
> >> - return false;
> >> - /* Item at least partially after region. */
> >> - if (item->start + item->size > region->start + region->size)
> >> - return false;
> >> - return true;
> >> -}
> >> -
> >> static bool mem_overlaps(struct mem_vector *one, struct mem_vector *two)
> >> {
> >> /* Item one is entirely before item two. */
> >> @@ -286,8 +275,6 @@ static bool mem_avoid_overlap(struct mem_vector *img,
> >> return is_overlapping;
> >> }
> >>
> >> -static unsigned long slots[KERNEL_IMAGE_SIZE / CONFIG_PHYSICAL_ALIGN];
> >> -
> >> struct slot_area {
> >> unsigned long addr;
> >> int num;
> >> @@ -318,36 +305,44 @@ static void store_slot_info(struct mem_vector *region, unsigned long image_size)
> >> }
> >> }
> >>
> >> -static void slots_append(unsigned long addr)
> >> -{
> >> - /* Overflowing the slots list should be impossible. */
> >> - if (slot_max >= KERNEL_IMAGE_SIZE / CONFIG_PHYSICAL_ALIGN)
> >> - return;
> >> -
> >> - slots[slot_max++] = addr;
> >> -}
> >> -
> >> static unsigned long slots_fetch_random(void)
> >> {
> >> + unsigned long slot;
> >> + int i;
> >> +
> >> /* Handle case of no slots stored. */
> >> if (slot_max == 0)
> >> return 0;
> >>
> >> - return slots[get_random_long("Physical") % slot_max];
> >> + slot = get_random_long("Physical") % slot_max;
> >> +
> >> + for (i = 0; i < slot_area_index; i++) {
> >> + if (slot >= slot_areas[i].num) {
> >> + slot -= slot_areas[i].num;
> >> + continue;
> >> + }
> >> + return slot_areas[i].addr + slot * CONFIG_PHYSICAL_ALIGN;
> >> + }
> >> +
> >> + if (i == slot_area_index)
> >> + debug_putstr("slots_fetch_random() failed!?\n");
> >> + return 0;
> >> }
> >>
> >> static void process_e820_entry(struct e820entry *entry,
> >> unsigned long minimum,
> >> unsigned long image_size)
> >> {
> >> - struct mem_vector region, img, overlap;
> >> + struct mem_vector region, overlap;
> >> + struct slot_area slot_area;
> >> + unsigned long start_orig;
> >>
> >> /* Skip non-RAM entries. */
> >> if (entry->type != E820_RAM)
> >> return;
> >>
> >> - /* Ignore entries entirely above our maximum. */
> >> - if (entry->addr >= KERNEL_IMAGE_SIZE)
> >> + /* On 32-bit, ignore entries entirely above our maximum. */
> >> + if (IS_ENABLED(CONFIG_X86_32) && entry->addr >= KERNEL_IMAGE_SIZE)
> >> return;
>
> Since physical and virtual are not separated on 32-bit, it means the
> 32-bit physical address selection becomes the virtual address
> selection, and as such, it cannot be above KERNEL_IMAGE_SIZE on
> 32-bit.
>
> -Kees
>
> >>
> >> /* Ignore entries entirely below our minimum. */
> >> @@ -357,31 +352,55 @@ static void process_e820_entry(struct e820entry *entry,
> >> region.start = entry->addr;
> >> region.size = entry->size;
> >>
> >> - /* Potentially raise address to minimum location. */
> >> - if (region.start < minimum)
> >> - region.start = minimum;
> >> + /* Give up if slot area array is full. */
> >> + while (slot_area_index < MAX_SLOT_AREA) {
> >> + start_orig = region.start;
> >>
> >> - /* Potentially raise address to meet alignment requirements. */
> >> - region.start = ALIGN(region.start, CONFIG_PHYSICAL_ALIGN);
> >> + /* Potentially raise address to minimum location. */
> >> + if (region.start < minimum)
> >> + region.start = minimum;
> >>
> >> - /* Did we raise the address above the bounds of this e820 region? */
> >> - if (region.start > entry->addr + entry->size)
> >> - return;
> >> + /* Potentially raise address to meet alignment needs. */
> >> + region.start = ALIGN(region.start, CONFIG_PHYSICAL_ALIGN);
> >>
> >> - /* Reduce size by any delta from the original address. */
> >> - region.size -= region.start - entry->addr;
> >> + /* Did we raise the address above this e820 region? */
> >> + if (region.start > entry->addr + entry->size)
> >> + return;
> >>
> >> - /* Reduce maximum size to fit end of image within maximum limit. */
> >> - if (region.start + region.size > KERNEL_IMAGE_SIZE)
> >> - region.size = KERNEL_IMAGE_SIZE - region.start;
> >> + /* Reduce size by any delta from the original address. */
> >> + region.size -= region.start - start_orig;
> >>
> >> - /* Walk each aligned slot and check for avoided areas. */
> >> - for (img.start = region.start, img.size = image_size ;
> >> - mem_contains(®ion, &img) ;
> >> - img.start += CONFIG_PHYSICAL_ALIGN) {
> >> - if (mem_avoid_overlap(&img, &overlap))
> >> - continue;
> >> - slots_append(img.start);
> >> + /* On 32-bit, reduce region size to fit within max size. */
> >> + if (IS_ENABLED(CONFIG_X86_32) &&
> >> + region.start + region.size > KERNEL_IMAGE_SIZE)
> >> + region.size = KERNEL_IMAGE_SIZE - region.start;
> >> +
> >> + /* Return if region can't contain decompressed kernel */
> >> + if (region.size < image_size)
> >> + return;
> >> +
> >> + /* If nothing overlaps, store the region and return. */
> >> + if (!mem_avoid_overlap(®ion, &overlap)) {
> >> + store_slot_info(®ion, image_size);
> >> + return;
> >> + }
> >> +
> >> + /* Store beginning of region if holds at least image_size. */
> >> + if (overlap.start > region.start + image_size) {
> >> + struct mem_vector beginning;
> >> +
> >> + beginning.start = region.start;
> >> + beginning.size = overlap.start - region.start;
> >> + store_slot_info(&beginning, image_size);
> >> + }
> >> +
> >> + /* Return if overlap extends to or past end of region. */
> >> + if (overlap.start + overlap.size >= region.start + region.size)
> >> + return;
> >> +
> >> + /* Clip off the overlapping region and start over. */
> >> + region.size -= overlap.start - region.start + overlap.size;
> >> + region.start = overlap.start + overlap.size;
> >> }
> >> }
> >>
> >> @@ -398,6 +417,10 @@ static unsigned long find_random_phys_addr(unsigned long minimum,
> >> for (i = 0; i < boot_params->e820_entries; i++) {
> >> process_e820_entry(&boot_params->e820_map[i], minimum,
> >> image_size);
> >> + if (slot_area_index == MAX_SLOT_AREA) {
> >> + debug_putstr("Aborted e820 scan (slot_areas full)!\n");
> >> + break;
> >> + }
> >> }
> >>
> >> return slots_fetch_random();
> >> --
> >> 2.6.3
> >>
>
>
>
> --
> Kees Cook
> Chrome OS & Brillo Security
WARNING: multiple messages have this Message-ID (diff)
From: Baoquan He <bhe@redhat.com>
To: Kees Cook <keescook@chromium.org>
Cc: Ingo Molnar <mingo@kernel.org>, Ingo Molnar <mingo@redhat.com>,
Yinghai Lu <yinghai@kernel.org>, "H. Peter Anvin" <hpa@zytor.com>,
Borislav Petkov <bp@alien8.de>, Vivek Goyal <vgoyal@redhat.com>,
Andy Lutomirski <luto@kernel.org>,
Lasse Collin <lasse.collin@tukaani.org>,
Andrew Morton <akpm@linux-foundation.org>,
Dave Young <dyoung@redhat.com>,
"kernel-hardening@lists.openwall.com"
<kernel-hardening@lists.openwall.com>,
LKML <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH v6 10/11] x86/KASLR: Add physical address randomization >4G
Date: Sun, 8 May 2016 17:17:30 +0800 [thread overview]
Message-ID: <20160508091730.GA2355@x1> (raw)
In-Reply-To: <CAGXu5jLA38thQAa6Uj0YCFvwGgus2a21GaFsD8PcD1ZvhS+Wkg@mail.gmail.com>
On 05/06/16 at 08:31am, Kees Cook wrote:
> On Fri, May 6, 2016 at 1:27 AM, Baoquan He <bhe@redhat.com> wrote:
> > Hi Kees,
> >
> > On 05/05/16 at 03:13pm, Kees Cook wrote:
> >> From: Baoquan He <bhe@redhat.com>
> >>
> >> This patch exchanges the prior slots[] array for the new slot_areas[]
> >> array, and lifts the limitation of KERNEL_IMAGE_SIZE on the physical
> >> address offset for 64-bit. As before, process_e820_entry() walks
> >
> > Sorry, I didn't get what you said about lifting the limitation for
> > 64-bit. Do you mean 32-bit?
>
> Prior to this patch, physical address randomization was limited to
> KERNEL_IMAGE_SIZE on x86_64. After this patch, that limit is lifted
> for x86_64 but 32-bit remains limited to KERNEL_IMAGE_SIZE being the
> upper physical memory position.
Ah, yes. This is lifting the limitation of physical addr from
KERNEL_IMAGE_SIZE to max available physical addr. I must have been
dizzy, please forgive my noise.
>
> >
> > Thanks
> > Baoquan
> >
> >
> >> memory and populates slot_areas[], splitting on any detected mem_avoid
> >> collisions.
> >>
> >> Finally, since the slots[] array and its associated functions are not
> >> needed any more, so they are removed.
> >>
> >> Signed-off-by: Baoquan He <bhe@redhat.com>
> >> [kees: rewrote changelog, refactored goto into while]
> >> [kees: limit 32-bit to KERNEL_IMAGE_SIZE]
> >> [kees: squash dead-code removal into this patch]
> >> [kees: refactored to use new mem_overlap code, renamed variables]
> >> [kees: updated Kconfig to reflect updated implementation]
> >> Signed-off-by: Kees Cook <keescook@chromium.org>
> >> ---
> >> arch/x86/Kconfig | 27 +++++----
> >> arch/x86/boot/compressed/kaslr.c | 115 +++++++++++++++++++++++----------------
> >> 2 files changed, 85 insertions(+), 57 deletions(-)
> >>
> >> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> >> index 5892d549596d..39be0f7b49ef 100644
> >> --- a/arch/x86/Kconfig
> >> +++ b/arch/x86/Kconfig
> >> @@ -1943,21 +1943,26 @@ config RANDOMIZE_BASE
> >> attempts relying on knowledge of the location of kernel
> >> code internals.
> >>
> >> - The kernel physical and virtual address can be randomized
> >> - from 16MB up to 1GB on 64-bit and 512MB on 32-bit. (Note that
> >> - using RANDOMIZE_BASE reduces the memory space available to
> >> - kernel modules from 1.5GB to 1GB.)
> >> + On 64-bit, the kernel physical and virtual addresses are
> >> + randomized separately. The physical address will be anywhere
> >> + between 16MB and the top of physical memory (up to 64TB). The
> >> + virtual address will be randomized from 16MB up to 1GB (9 bits
> >> + of entropy). Note that this also reduces the memory space
> >> + available to kernel modules from 1.5GB to 1GB.
> >> +
> >> + On 32-bit, the kernel physical and virtual addresses are
> >> + randomized together. They will be randomized from 16MB up to
> >> + 512MB (8 bits of entropy).
> >>
> >> Entropy is generated using the RDRAND instruction if it is
> >> supported. If RDTSC is supported, its value is mixed into
> >> the entropy pool as well. If neither RDRAND nor RDTSC are
> >> - supported, then entropy is read from the i8254 timer.
> >> -
> >> - Since the kernel is built using 2GB addressing, and
> >> - PHYSICAL_ALIGN must be at a minimum of 2MB, only 10 bits of
> >> - entropy is theoretically possible. Currently, with the
> >> - default value for PHYSICAL_ALIGN and due to page table
> >> - layouts, 64-bit uses 9 bits of entropy and 32-bit uses 8 bits.
> >> + supported, then entropy is read from the i8254 timer. The
> >> + usable entropy is limited by the kernel being built using
> >> + 2GB addressing, and that PHYSICAL_ALIGN must be at a
> >> + minimum of 2MB. As a result, only 10 bits of entropy is
> >> + theoretically possible, but the implementations are further
> >> + limited due to memory layouts.
> >>
> >> If CONFIG_HIBERNATE is also enabled, KASLR is disabled at boot
> >> time. To enable it, boot with "kaslr" on the kernel command
> >> diff --git a/arch/x86/boot/compressed/kaslr.c b/arch/x86/boot/compressed/kaslr.c
> >> index 58d0871be037..8cf705826bdc 100644
> >> --- a/arch/x86/boot/compressed/kaslr.c
> >> +++ b/arch/x86/boot/compressed/kaslr.c
> >> @@ -125,17 +125,6 @@ struct mem_vector {
> >> #define MEM_AVOID_MAX 4
> >> static struct mem_vector mem_avoid[MEM_AVOID_MAX];
> >>
> >> -static bool mem_contains(struct mem_vector *region, struct mem_vector *item)
> >> -{
> >> - /* Item at least partially before region. */
> >> - if (item->start < region->start)
> >> - return false;
> >> - /* Item at least partially after region. */
> >> - if (item->start + item->size > region->start + region->size)
> >> - return false;
> >> - return true;
> >> -}
> >> -
> >> static bool mem_overlaps(struct mem_vector *one, struct mem_vector *two)
> >> {
> >> /* Item one is entirely before item two. */
> >> @@ -286,8 +275,6 @@ static bool mem_avoid_overlap(struct mem_vector *img,
> >> return is_overlapping;
> >> }
> >>
> >> -static unsigned long slots[KERNEL_IMAGE_SIZE / CONFIG_PHYSICAL_ALIGN];
> >> -
> >> struct slot_area {
> >> unsigned long addr;
> >> int num;
> >> @@ -318,36 +305,44 @@ static void store_slot_info(struct mem_vector *region, unsigned long image_size)
> >> }
> >> }
> >>
> >> -static void slots_append(unsigned long addr)
> >> -{
> >> - /* Overflowing the slots list should be impossible. */
> >> - if (slot_max >= KERNEL_IMAGE_SIZE / CONFIG_PHYSICAL_ALIGN)
> >> - return;
> >> -
> >> - slots[slot_max++] = addr;
> >> -}
> >> -
> >> static unsigned long slots_fetch_random(void)
> >> {
> >> + unsigned long slot;
> >> + int i;
> >> +
> >> /* Handle case of no slots stored. */
> >> if (slot_max == 0)
> >> return 0;
> >>
> >> - return slots[get_random_long("Physical") % slot_max];
> >> + slot = get_random_long("Physical") % slot_max;
> >> +
> >> + for (i = 0; i < slot_area_index; i++) {
> >> + if (slot >= slot_areas[i].num) {
> >> + slot -= slot_areas[i].num;
> >> + continue;
> >> + }
> >> + return slot_areas[i].addr + slot * CONFIG_PHYSICAL_ALIGN;
> >> + }
> >> +
> >> + if (i == slot_area_index)
> >> + debug_putstr("slots_fetch_random() failed!?\n");
> >> + return 0;
> >> }
> >>
> >> static void process_e820_entry(struct e820entry *entry,
> >> unsigned long minimum,
> >> unsigned long image_size)
> >> {
> >> - struct mem_vector region, img, overlap;
> >> + struct mem_vector region, overlap;
> >> + struct slot_area slot_area;
> >> + unsigned long start_orig;
> >>
> >> /* Skip non-RAM entries. */
> >> if (entry->type != E820_RAM)
> >> return;
> >>
> >> - /* Ignore entries entirely above our maximum. */
> >> - if (entry->addr >= KERNEL_IMAGE_SIZE)
> >> + /* On 32-bit, ignore entries entirely above our maximum. */
> >> + if (IS_ENABLED(CONFIG_X86_32) && entry->addr >= KERNEL_IMAGE_SIZE)
> >> return;
>
> Since physical and virtual are not separated on 32-bit, it means the
> 32-bit physical address selection becomes the virtual address
> selection, and as such, it cannot be above KERNEL_IMAGE_SIZE on
> 32-bit.
>
> -Kees
>
> >>
> >> /* Ignore entries entirely below our minimum. */
> >> @@ -357,31 +352,55 @@ static void process_e820_entry(struct e820entry *entry,
> >> region.start = entry->addr;
> >> region.size = entry->size;
> >>
> >> - /* Potentially raise address to minimum location. */
> >> - if (region.start < minimum)
> >> - region.start = minimum;
> >> + /* Give up if slot area array is full. */
> >> + while (slot_area_index < MAX_SLOT_AREA) {
> >> + start_orig = region.start;
> >>
> >> - /* Potentially raise address to meet alignment requirements. */
> >> - region.start = ALIGN(region.start, CONFIG_PHYSICAL_ALIGN);
> >> + /* Potentially raise address to minimum location. */
> >> + if (region.start < minimum)
> >> + region.start = minimum;
> >>
> >> - /* Did we raise the address above the bounds of this e820 region? */
> >> - if (region.start > entry->addr + entry->size)
> >> - return;
> >> + /* Potentially raise address to meet alignment needs. */
> >> + region.start = ALIGN(region.start, CONFIG_PHYSICAL_ALIGN);
> >>
> >> - /* Reduce size by any delta from the original address. */
> >> - region.size -= region.start - entry->addr;
> >> + /* Did we raise the address above this e820 region? */
> >> + if (region.start > entry->addr + entry->size)
> >> + return;
> >>
> >> - /* Reduce maximum size to fit end of image within maximum limit. */
> >> - if (region.start + region.size > KERNEL_IMAGE_SIZE)
> >> - region.size = KERNEL_IMAGE_SIZE - region.start;
> >> + /* Reduce size by any delta from the original address. */
> >> + region.size -= region.start - start_orig;
> >>
> >> - /* Walk each aligned slot and check for avoided areas. */
> >> - for (img.start = region.start, img.size = image_size ;
> >> - mem_contains(®ion, &img) ;
> >> - img.start += CONFIG_PHYSICAL_ALIGN) {
> >> - if (mem_avoid_overlap(&img, &overlap))
> >> - continue;
> >> - slots_append(img.start);
> >> + /* On 32-bit, reduce region size to fit within max size. */
> >> + if (IS_ENABLED(CONFIG_X86_32) &&
> >> + region.start + region.size > KERNEL_IMAGE_SIZE)
> >> + region.size = KERNEL_IMAGE_SIZE - region.start;
> >> +
> >> + /* Return if region can't contain decompressed kernel */
> >> + if (region.size < image_size)
> >> + return;
> >> +
> >> + /* If nothing overlaps, store the region and return. */
> >> + if (!mem_avoid_overlap(®ion, &overlap)) {
> >> + store_slot_info(®ion, image_size);
> >> + return;
> >> + }
> >> +
> >> + /* Store beginning of region if holds at least image_size. */
> >> + if (overlap.start > region.start + image_size) {
> >> + struct mem_vector beginning;
> >> +
> >> + beginning.start = region.start;
> >> + beginning.size = overlap.start - region.start;
> >> + store_slot_info(&beginning, image_size);
> >> + }
> >> +
> >> + /* Return if overlap extends to or past end of region. */
> >> + if (overlap.start + overlap.size >= region.start + region.size)
> >> + return;
> >> +
> >> + /* Clip off the overlapping region and start over. */
> >> + region.size -= overlap.start - region.start + overlap.size;
> >> + region.start = overlap.start + overlap.size;
> >> }
> >> }
> >>
> >> @@ -398,6 +417,10 @@ static unsigned long find_random_phys_addr(unsigned long minimum,
> >> for (i = 0; i < boot_params->e820_entries; i++) {
> >> process_e820_entry(&boot_params->e820_map[i], minimum,
> >> image_size);
> >> + if (slot_area_index == MAX_SLOT_AREA) {
> >> + debug_putstr("Aborted e820 scan (slot_areas full)!\n");
> >> + break;
> >> + }
> >> }
> >>
> >> return slots_fetch_random();
> >> --
> >> 2.6.3
> >>
>
>
>
> --
> Kees Cook
> Chrome OS & Brillo Security
next prev parent reply other threads:[~2016-05-08 9:17 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-05 22:13 [kernel-hardening] [PATCH v6 0/11] x86/KASLR: Randomize virtual address separately Kees Cook
2016-05-05 22:13 ` Kees Cook
2016-05-05 22:13 ` [kernel-hardening] [PATCH v6 01/11] x86/boot: Clean up pointer casting Kees Cook
2016-05-05 22:13 ` Kees Cook
2016-05-06 7:45 ` [tip:x86/boot] " tip-bot for Kees Cook
2016-05-06 8:53 ` Borislav Petkov
2016-05-06 10:10 ` Ingo Molnar
2016-05-06 15:21 ` Kees Cook
2016-05-06 10:36 ` Ingo Molnar
2016-05-06 10:44 ` Borislav Petkov
2016-05-06 11:50 ` [PATCH -v1.1] x86/boot: Simplify pointer casting in choose_random_location() Borislav Petkov
2016-05-07 6:35 ` [tip:x86/boot] " tip-bot for Borislav Petkov
2016-05-05 22:13 ` [kernel-hardening] [PATCH v6 02/11] x86/KASLR: Consolidate mem_avoid entries Kees Cook
2016-05-05 22:13 ` Kees Cook
2016-05-06 7:46 ` [tip:x86/boot] x86/KASLR: Consolidate mem_avoid[] entries tip-bot for Yinghai Lu
2016-05-06 16:08 ` Borislav Petkov
2016-05-06 18:16 ` Kees Cook
2016-05-06 19:29 ` Borislav Petkov
2016-05-05 22:13 ` [kernel-hardening] [PATCH v6 03/11] x86/boot: Split out kernel_ident_mapping_init Kees Cook
2016-05-05 22:13 ` Kees Cook
2016-05-05 22:13 ` [kernel-hardening] [PATCH v6 04/11] x86/KASLR: Build identity mappings on demand Kees Cook
2016-05-05 22:13 ` Kees Cook
2016-05-06 7:00 ` [kernel-hardening] " Ingo Molnar
2016-05-06 7:00 ` Ingo Molnar
2016-05-06 17:44 ` [kernel-hardening] " Kees Cook
2016-05-06 17:44 ` Kees Cook
2016-05-05 22:13 ` [kernel-hardening] [PATCH v6 05/11] x86/KASLR: Add slot_area to manage random_addr slots Kees Cook
2016-05-05 22:13 ` Kees Cook
2016-05-05 22:13 ` [kernel-hardening] [PATCH v6 06/11] x86/KASLR: Return earliest overlap when avoiding regions Kees Cook
2016-05-05 22:13 ` Kees Cook
2016-05-05 22:13 ` [kernel-hardening] [PATCH v6 07/11] x86/KASLR: Add virtual address choosing function Kees Cook
2016-05-05 22:13 ` Kees Cook
2016-05-05 22:13 ` [kernel-hardening] [PATCH v6 08/11] x86/KASLR: Clarify purpose of each get_random_long Kees Cook
2016-05-05 22:13 ` Kees Cook
2016-05-05 22:13 ` [kernel-hardening] [PATCH v6 09/11] x86/KASLR: Randomize virtual address separately Kees Cook
2016-05-05 22:13 ` Kees Cook
2016-05-05 22:13 ` [kernel-hardening] [PATCH v6 10/11] x86/KASLR: Add physical address randomization >4G Kees Cook
2016-05-05 22:13 ` Kees Cook
2016-05-06 8:27 ` [kernel-hardening] " Baoquan He
2016-05-06 8:27 ` Baoquan He
2016-05-06 15:31 ` [kernel-hardening] " Kees Cook
2016-05-06 15:31 ` Kees Cook
2016-05-08 9:17 ` Baoquan He [this message]
2016-05-08 9:17 ` Baoquan He
2016-05-05 22:13 ` [kernel-hardening] [PATCH v6 11/11] x86/KASLR: Allow randomization below load address Kees Cook
2016-05-05 22:13 ` Kees Cook
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=20160508091730.GA2355@x1 \
--to=bhe@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=bp@alien8.de \
--cc=dyoung@redhat.com \
--cc=hpa@zytor.com \
--cc=keescook@chromium.org \
--cc=kernel-hardening@lists.openwall.com \
--cc=lasse.collin@tukaani.org \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@kernel.org \
--cc=mingo@kernel.org \
--cc=mingo@redhat.com \
--cc=vgoyal@redhat.com \
--cc=yinghai@kernel.org \
/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.