[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <CAKv+Gu8TnraRGj_b=pcb6xTKMLX7GLZeJGmJ4R3vU6ygnr2kTA@mail.gmail.com>
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
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
