Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Wed, 27 Jun 2018 16:28:04 -0700
From: Laura Abbott <labbott@...hat.com>
To: Ard Biesheuvel <ard.biesheuvel@...aro.org>
Cc: linux-arm-kernel <linux-arm-kernel@...ts.infradead.org>,
 Mark Rutland <mark.rutland@....com>, Kees Cook <keescook@...omium.org>,
 Will Deacon <will.deacon@....com>, Catalin Marinas
 <catalin.marinas@....com>, James Morse <james.morse@....com>,
 Kernel Hardening <kernel-hardening@...ts.openwall.com>,
 YaoJun <yaojun8558363@...il.com>
Subject: Re: [RFC PATCH] arm64/mm: unmap the linear alias of module
 allocations

On 06/26/2018 06:15 PM, Laura Abbott wrote:
> +static void remap_linear_module_alias(void *module_region, int enable)
> +{
> +       struct vm_struct *vm = find_vm_area(module_region);
> +       struct page **p;
> +       unsigned long size;
> +
> +       WARN_ON(!vm || !vm->pages);
> +
> +       for (p = vm->pages, size = vm->size; size > 0; size -= PAGE_SIZE)
> +               set_memory_valid((u64)page_address(*p++), 1, enable);
> +}

So I think the weirdness is caused by using vm->size here. The size of
the array is actually tracked by vm->nr_pages since vm->size may vary
depending on the guard page. I think this ended being an off by one
error with setting a non-existent page valid, hence the oddness in
the entry. If I switch to using vm->nr_pages, I don't see the entry
anymore.

Thanks,
Laura

Powered by blists - more mailing lists

Your e-mail address:

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.