| 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
| ||
|
Message-ID: <CAKv+Gu_m353cv=Pf2cEUDLn8=5YTLjLDDO23n=P14nWXydQWDQ@mail.gmail.com>
Date: Mon, 24 Dec 2018 10:45:42 +0100
From: Ard Biesheuvel <ard.biesheuvel@...aro.org>
To: Yueyi Li <liyueyi@...e.com>
Cc: "catalin.marinas@....com" <catalin.marinas@....com>,
"will.deacon@....com" <will.deacon@....com>,
"akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
"linux-arm-kernel@...ts.infradead.org"
<linux-arm-kernel@...ts.infradead.org>,
"markus@...rhumer.com" <markus@...rhumer.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] arm64: kaslr: Reserve size of ARM64_MEMSTART_ALIGN in
linear region
On Mon, 24 Dec 2018 at 08:40, Yueyi Li <liyueyi@...e.com> wrote:
>
> When KASLR enaled(CONFIG_RANDOMIZE_BASE=y), the top 4K virtual
> address have chance to be mapped to physical address, but which
> is expected to leave room for ERR_PTR.
>
> Also, it might cause some other warparound issue when somewhere
> use the last memory page but no overflow check. Such as the last
> page compressed by LZO:
>
> [ 2738.034508] Unable to handle kernel NULL pointer dereference at virtual address 00000009
> [ 2738.034515] Mem abort info:
> [ 2738.034518] Exception class = DABT (current EL), IL = 32 bits
> [ 2738.034520] SET = 0, FnV = 0
> [ 2738.034523] EA = 0, S1PTW = 0
> [ 2738.034524] FSC = 5
> [ 2738.034526] Data abort info:
> [ 2738.034528] ISV = 0, ISS = 0x00000005
> [ 2738.034530] CM = 0, WnR = 0
> [ 2738.034533] user pgtable: 4k pages, 39-bit VAs, pgd = ffffffff94cee000
> [ 2738.034535] [0000000000000009] *pgd=0000000000000000, *pud=0000000000000000
> ...
> [ 2738.034592] pc : lzo1x_1_do_compress+0x198/0x610
> [ 2738.034595] lr : lzo1x_1_compress+0x98/0x3d8
> [ 2738.034597] sp : ffffff801caa3470 pstate : 00c00145
> [ 2738.034598] x29: ffffff801caa3500 x28: 0000000000001000
> [ 2738.034601] x27: 0000000000001000 x26: fffffffffffff000
> [ 2738.034604] x25: ffffffff4ebc0000 x24: 0000000000000000
> [ 2738.034607] x23: 000000000000004c x22: fffffffffffff7b8
> [ 2738.034610] x21: ffffffff2e2ee0b3 x20: ffffffff2e2ee0bb
> [ 2738.034612] x19: 0000000000000fcc x18: fffffffffffff84a
> [ 2738.034615] x17: 00000000801b03d6 x16: 0000000000000782
> [ 2738.034618] x15: ffffffff2e2ee0bf x14: fffffffffffffff0
> [ 2738.034620] x13: 000000000000000f x12: 0000000000000020
> [ 2738.034623] x11: 000000001824429d x10: ffffffffffffffec
> [ 2738.034626] x9 : 0000000000000009 x8 : 0000000000000000
> [ 2738.034628] x7 : 0000000000000868 x6 : 0000000000000434
> [ 2738.034631] x5 : ffffffff4ebc0000 x4 : 0000000000000000
> [ 2738.034633] x3 : ffffff801caa3510 x2 : ffffffff2e2ee000
> [ 2738.034636] x1 : 0000000000000000 x0 : fffffffffffff000
> ...
> [ 2738.034717] Process kworker/u16:1 (pid: 8705, stack limit = 0xffffff801caa0000)
> [ 2738.034720] Call trace:
> [ 2738.034722] lzo1x_1_do_compress+0x198/0x610
> [ 2738.034725] lzo_compress+0x48/0x88
> [ 2738.034729] crypto_compress+0x14/0x20
> [ 2738.034733] zcomp_compress+0x2c/0x38
> [ 2738.034736] zram_bvec_rw+0x3d0/0x860
> [ 2738.034738] zram_rw_page+0x88/0xe0
> [ 2738.034742] bdev_write_page+0x70/0xc0
> [ 2738.034745] __swap_writepage+0x58/0x3f8
> [ 2738.034747] swap_writepage+0x40/0x50
> [ 2738.034750] shrink_page_list+0x4fc/0xe58
> [ 2738.034753] reclaim_pages_from_list+0xa0/0x150
> [ 2738.034756] reclaim_pte_range+0x18c/0x1f8
> [ 2738.034759] __walk_page_range+0xf8/0x1e0
> [ 2738.034762] walk_page_range+0xf8/0x130
> [ 2738.034765] reclaim_task_anon+0xcc/0x168
> [ 2738.034767] swap_fn+0x438/0x668
> [ 2738.034771] process_one_work+0x1fc/0x460
> [ 2738.034773] worker_thread+0x2d0/0x478
> [ 2738.034775] kthread+0x110/0x120
> [ 2738.034778] ret_from_fork+0x10/0x18
> [ 2738.034781] Code: 3800167f 54ffffa8 d100066f 14000031 (b9400131)
> [ 2738.034784] ---[ end trace 9b5cca106f0e54d1 ]---
> [ 2738.035473] Kernel panic - not syncing: Fatal exception
>
> in = 0xfffffffffffff000
> in_len = 4096
> ip = x9 = 0x0000000000000009 overflowed.
>
> Always leave room the last size of ARM64_MEMSTART_ALIGN region
> in linear region.
>
> Signed-off-by: liyueyi <liyueyi@...e.com>
> ---
> arch/arm64/mm/init.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/arch/arm64/mm/init.c b/arch/arm64/mm/init.c
> index 0340e45..20fe11e 100644
> --- a/arch/arm64/mm/init.c
> +++ b/arch/arm64/mm/init.c
> @@ -439,7 +439,8 @@ void __init arm64_memblock_init(void)
> if (IS_ENABLED(CONFIG_RANDOMIZE_BASE)) {
> extern u16 memstart_offset_seed;
> u64 range = linear_region_size -
> - (memblock_end_of_DRAM() - memblock_start_of_DRAM());
> + (memblock_end_of_DRAM() - memblock_start_of_DRAM()) -
> + ARM64_MEMSTART_ALIGN;
>
> /*
> * If the size of the linear region exceeds, by a sufficient
Does the following change fix your issue as well?
index 9b432d9fcada..9dcf0ff75a11 100644
--- a/arch/arm64/mm/init.c
+++ b/arch/arm64/mm/init.c
@@ -447,7 +447,7 @@ void __init arm64_memblock_init(void)
* memory spans, randomize the linear region as well.
*/
if (memstart_offset_seed > 0 && range >= ARM64_MEMSTART_ALIGN) {
- range = range / ARM64_MEMSTART_ALIGN + 1;
+ range /= ARM64_MEMSTART_ALIGN;
memstart_addr -= ARM64_MEMSTART_ALIGN *
((range * memstart_offset_seed) >> 16);
}
Powered by blists - more mailing lists