lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <568D4256.5030700@arm.com>
Date:	Wed, 06 Jan 2016 16:35:34 +0000
From:	James Morse <james.morse@....com>
To:	Ard Biesheuvel <ard.biesheuvel@...aro.org>
CC:	linux-arm-kernel@...ts.infradead.org,
	kernel-hardening@...ts.openwall.com, will.deacon@....com,
	catalin.marinas@....com, mark.rutland@....com,
	leif.lindholm@...aro.org, keescook@...omium.org,
	linux-kernel@...r.kernel.org, stuart.yoder@...escale.com,
	bhupesh.sharma@...escale.com, arnd@...db.de, marc.zyngier@....com,
	christoffer.dall@...aro.org
Subject: Re: [PATCH v2 04/13] arm64: decouple early fixmap init from linear
 mapping

Hi Ard!

On 30/12/15 15:26, Ard Biesheuvel wrote:
> Since the early fixmap page tables are populated using pages that are
> part of the static footprint of the kernel, they are covered by the
> initial kernel mapping, and we can refer to them without using __va/__pa
> translations, which are tied to the linear mapping.
> 
> Instead, let's introduce __phys_to_kimg, which will be tied to the kernel
> virtual mapping, regardless of whether or not it intersects with the linear
> mapping. This will allow us to move the kernel out of the linear mapping in
> a subsequent patch.
> 

I gave your arm64-kaslr-v2 branch a go on juno r1, currently with
ARM64_RELOCATABLE_KERNEL=n, to find it didn't boot.

git bisect pointed to this patch. From the debugger it looks like
rubbish is ending up the page tables after early_fixmap_init(), printing
bits of bm_pmd and friends shows these aren't zeroed.

I think this is because the section(".pgdir") is dragging these outside
the __bss_start/__bss_stop range that is zeroed in head.S:__mmap_switched().

The following inelegant patch fixes this problem for me:
----------------------------%<----------------------------
diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index a78fc5a882da..15fc9712ddc1 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -559,6 +559,7 @@ void __init early_fixmap_init(void)
        if (pgd_none(*pgd)) {
                static pud_t bm_pud[PTRS_PER_PUD] __pgdir;

+               memset(bm_pud, 0, sizeof(bm_pud));
                pgd_populate(&init_mm, pgd, bm_pud);
                memblock_reserve(__pa(bm_pud), sizeof(bm_pud));
        }
@@ -570,6 +571,7 @@ void __init early_fixmap_init(void)
        if (pud_none(*pud)) {
                static pmd_t bm_pmd[PTRS_PER_PMD] __pgdir;

+               memset(bm_pmd, 0, sizeof(bm_pmd));
                pud_populate(&init_mm, pud, bm_pmd);
                memblock_reserve(__pa(bm_pmd), sizeof(bm_pmd));
        }
@@ -580,6 +582,7 @@ void __init early_fixmap_init(void)
        if (pmd_none(*pmd)) {
                static pte_t bm_pte[PTRS_PER_PTE] __pgdir;

+               memset(bm_pte, 0, sizeof(bm_pte));
                pmd_populate_kernel(&init_mm, pmd, bm_pte);
                memblock_reserve(__pa(bm_pte), sizeof(bm_pte));
        }
----------------------------%<----------------------------

I'm sure there is a better way!


Thanks,

James

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ