Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Thu, 28 Jun 2018 01:29:42 +0200
From: Ard Biesheuvel <ard.biesheuvel@...aro.org>
To: Laura Abbott <labbott@...hat.com>
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 28 June 2018 at 01:28, Laura Abbott <labbott@...hat.com> wrote:
> 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.
>

OK, thanks for tracking that down!

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.