Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

[PATCH] x86, mm: get ASLR work for hugetlb mappings

3 views
Skip to first unread message

Kirill A. Shutemov

unread,
Oct 22, 2013, 10:00:02 AM10/22/13
to
Matthew noticed that hugetlb doesn't participate in ASLR on x86-64.
The reason is genereic hugetlb_get_unmapped_area() which is used on
x86-64. It doesn't support randomization and use bottom-up unmapped area
lookup, instead of usual top-down on x86-64.

x86 has arch-specific hugetlb_get_unmapped_area(), but it's used only on
x86-32.

Let's use arch-specific hugetlb_get_unmapped_area() on x86-64 too.
It fixes the issue and make hugetlb use top-down unmapped area lookup.

Signed-off-by: Kirill A. Shutemov <kirill....@linux.intel.com>
Cc: Matthew Wilcox <wi...@linux.intel.com>
---
arch/x86/include/asm/page.h | 1 +
arch/x86/include/asm/page_32.h | 4 ----
arch/x86/mm/hugetlbpage.c | 9 +++------
3 files changed, 4 insertions(+), 10 deletions(-)

diff --git a/arch/x86/include/asm/page.h b/arch/x86/include/asm/page.h
index c87892442e..775873d3be 100644
--- a/arch/x86/include/asm/page.h
+++ b/arch/x86/include/asm/page.h
@@ -71,6 +71,7 @@ extern bool __virt_addr_valid(unsigned long kaddr);
#include <asm-generic/getorder.h>

#define __HAVE_ARCH_GATE_AREA 1
+#define HAVE_ARCH_HUGETLB_UNMAPPED_AREA

#endif /* __KERNEL__ */
#endif /* _ASM_X86_PAGE_H */
diff --git a/arch/x86/include/asm/page_32.h b/arch/x86/include/asm/page_32.h
index 4d550d04b6..904f528cc8 100644
--- a/arch/x86/include/asm/page_32.h
+++ b/arch/x86/include/asm/page_32.h
@@ -5,10 +5,6 @@

#ifndef __ASSEMBLY__

-#ifdef CONFIG_HUGETLB_PAGE
-#define HAVE_ARCH_HUGETLB_UNMAPPED_AREA
-#endif
-
#define __phys_addr_nodebug(x) ((x) - PAGE_OFFSET)
#ifdef CONFIG_DEBUG_VIRTUAL
extern unsigned long __phys_addr(unsigned long);
diff --git a/arch/x86/mm/hugetlbpage.c b/arch/x86/mm/hugetlbpage.c
index 9d980d88b7..8c9f647ff9 100644
--- a/arch/x86/mm/hugetlbpage.c
+++ b/arch/x86/mm/hugetlbpage.c
@@ -87,9 +87,7 @@ int pmd_huge_support(void)
}
#endif

-/* x86_64 also uses this file */
-
-#ifdef HAVE_ARCH_HUGETLB_UNMAPPED_AREA
+#ifdef CONFIG_HUGETLB_PAGE
static unsigned long hugetlb_get_unmapped_area_bottomup(struct file *file,
unsigned long addr, unsigned long len,
unsigned long pgoff, unsigned long flags)
@@ -99,7 +97,7 @@ static unsigned long hugetlb_get_unmapped_area_bottomup(struct file *file,

info.flags = 0;
info.length = len;
- info.low_limit = TASK_UNMAPPED_BASE;
+ info.low_limit = current->mm->mmap_legacy_base;
info.high_limit = TASK_SIZE;
info.align_mask = PAGE_MASK & ~huge_page_mask(h);
info.align_offset = 0;
@@ -172,8 +170,7 @@ hugetlb_get_unmapped_area(struct file *file, unsigned long addr,
return hugetlb_get_unmapped_area_topdown(file, addr, len,
pgoff, flags);
}
-
-#endif /*HAVE_ARCH_HUGETLB_UNMAPPED_AREA*/
+#endif /* CONFIG_HUGETLB_PAGE */

#ifdef CONFIG_X86_64
static __init int setup_hugepagesz(char *opt)
--
1.8.4.rc3

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Dave Hansen

unread,
Oct 22, 2013, 11:30:02 AM10/22/13
to
On 10/22/2013 06:52 AM, Kirill A. Shutemov wrote:
> Matthew noticed that hugetlb doesn't participate in ASLR on x86-64.
> The reason is genereic hugetlb_get_unmapped_area() which is used on
> x86-64. It doesn't support randomization and use bottom-up unmapped area
> lookup, instead of usual top-down on x86-64.

I have to wonder if this was on purpose in order to keep the large and
small mappings separate. We don't *have* to keep them separate this, of
course, but it makes me wonder.

> x86 has arch-specific hugetlb_get_unmapped_area(), but it's used only on
> x86-32.
>
> Let's use arch-specific hugetlb_get_unmapped_area() on x86-64 too.
> It fixes the issue and make hugetlb use top-down unmapped area lookup.

Shouldn't we fix the generic code instead of further specializing the
x86 stuff?

In any case, you probably also want to run this through: the
libhugetlbfs tests:

http://sourceforge.net/p/libhugetlbfs/code/ci/master/tree/tests/

Kirill A. Shutemov

unread,
Oct 22, 2013, 2:00:02 PM10/22/13
to
Dave Hansen wrote:
> On 10/22/2013 06:52 AM, Kirill A. Shutemov wrote:
> > Matthew noticed that hugetlb doesn't participate in ASLR on x86-64.
> > The reason is genereic hugetlb_get_unmapped_area() which is used on
> > x86-64. It doesn't support randomization and use bottom-up unmapped area
> > lookup, instead of usual top-down on x86-64.
>
> I have to wonder if this was on purpose in order to keep the large and
> small mappings separate. We don't *have* to keep them separate this, of
> course, but it makes me wonder.

I haven't seen any evidence that it's on purpose, but who knows...

In x86-specific hugetlb_get_unmapped_area() there's explicit check what is
mm->get_unmapped_area top-down or bottom-up, and doing the same.

> > x86 has arch-specific hugetlb_get_unmapped_area(), but it's used only on
> > x86-32.
> >
> > Let's use arch-specific hugetlb_get_unmapped_area() on x86-64 too.
> > It fixes the issue and make hugetlb use top-down unmapped area lookup.
>
> Shouldn't we fix the generic code instead of further specializing the
> x86 stuff?

For that we need to modify info.low_limit to mm->mmap_legacy_base (which
is x86 specific, no-go) or switch to top-down and set info.high_limit to
mm->mmap_base.

I don't know how it can affect other architectures.

> In any case, you probably also want to run this through: the
> libhugetlbfs tests:
>
> http://sourceforge.net/p/libhugetlbfs/code/ci/master/tree/tests/

I've got the same fail list for upstream and patched kernel, so no
regression was found.

********** TEST SUMMARY
* 2M
* 32-bit 64-bit
* Total testcases: 107 110
* Skipped: 0 0
* PASS: 98 108
* FAIL: 2 2
* Killed by signal: 7 0
* Bad configuration: 0 0
* Expected FAIL: 0 0
* Unexpected PASS: 0 0
* Strange test result: 0 0
**********

--
Kirill A. Shutemov

Kirill A. Shutemov

unread,
Nov 4, 2013, 5:50:01 AM11/4/13
to
Kirill A. Shutemov wrote:
> Matthew noticed that hugetlb doesn't participate in ASLR on x86-64.
> The reason is genereic hugetlb_get_unmapped_area() which is used on
> x86-64. It doesn't support randomization and use bottom-up unmapped area
> lookup, instead of usual top-down on x86-64.
>
> x86 has arch-specific hugetlb_get_unmapped_area(), but it's used only on
> x86-32.
>
> Let's use arch-specific hugetlb_get_unmapped_area() on x86-64 too.
> It fixes the issue and make hugetlb use top-down unmapped area lookup.
>
> Signed-off-by: Kirill A. Shutemov <kirill....@linux.intel.com>
> Cc: Matthew Wilcox <wi...@linux.intel.com>

Andrew, any comments?

--
Kirill A. Shutemov

Andrew Morton

unread,
Nov 4, 2013, 4:10:02 PM11/4/13
to
On Mon, 4 Nov 2013 12:41:52 +0200 (EET) "Kirill A. Shutemov" <kirill....@linux.intel.com> wrote:

> Kirill A. Shutemov wrote:
> > Matthew noticed that hugetlb doesn't participate in ASLR on x86-64.
> > The reason is genereic hugetlb_get_unmapped_area() which is used on
> > x86-64. It doesn't support randomization and use bottom-up unmapped area
> > lookup, instead of usual top-down on x86-64.
> >
> > x86 has arch-specific hugetlb_get_unmapped_area(), but it's used only on
> > x86-32.
> >
> > Let's use arch-specific hugetlb_get_unmapped_area() on x86-64 too.
> > It fixes the issue and make hugetlb use top-down unmapped area lookup.
> >
> > Signed-off-by: Kirill A. Shutemov <kirill....@linux.intel.com>
> > Cc: Matthew Wilcox <wi...@linux.intel.com>
>
> Andrew, any comments?

whome? I'm convinced, but it's an x86 patch. I tossed it in there so
it gets a bit of linux-next exposure.

Kirill A. Shutemov

unread,
Nov 11, 2013, 9:50:02 AM11/11/13
to
On Tue, Oct 22, 2013 at 04:52:20PM +0300, Kirill A. Shutemov wrote:
> Matthew noticed that hugetlb doesn't participate in ASLR on x86-64.
> The reason is genereic hugetlb_get_unmapped_area() which is used on
> x86-64. It doesn't support randomization and use bottom-up unmapped area
> lookup, instead of usual top-down on x86-64.
>
> x86 has arch-specific hugetlb_get_unmapped_area(), but it's used only on
> x86-32.
>
> Let's use arch-specific hugetlb_get_unmapped_area() on x86-64 too.
> It fixes the issue and make hugetlb use top-down unmapped area lookup.
>
> Signed-off-by: Kirill A. Shutemov <kirill....@linux.intel.com>
> Cc: Matthew Wilcox <wi...@linux.intel.com>

Gentelmen,

Could you take a look on the patch, please?

It's currently in -mm to get it tested on -next, but it should go through
x86 tree, I believe.
--
Kirill A. Shutemov
0 new messages