[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Wed, 27 Jan 2016 15:31:37 +0100
From: Ard Biesheuvel <ard.biesheuvel@...aro.org>
To: Mark Rutland <mark.rutland@....com>
Cc: Kees Cook <keescook@...omium.org>, Arnd Bergmann <arnd@...db.de>,
kernel-hardening@...ts.openwall.com,
Sharma Bhupesh <bhupesh.sharma@...escale.com>, Catalin Marinas <catalin.marinas@....com>,
Will Deacon <will.deacon@....com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, Leif Lindholm <leif.lindholm@...aro.org>,
Stuart Yoder <stuart.yoder@...escale.com>, Marc Zyngier <marc.zyngier@....com>,
Christoffer Dall <christoffer.dall@...aro.org>,
"linux-arm-kernel@...ts.infradead.org" <linux-arm-kernel@...ts.infradead.org>
Subject: Re: [PATCH v3 07/21] arm64: move kernel image to base of vmalloc area
On 15 January 2016 at 12:23, Mark Rutland <mark.rutland@....com> wrote:
> On Fri, Jan 15, 2016 at 10:54:26AM +0100, Ard Biesheuvel wrote:
>> On 14 January 2016 at 19:57, Mark Rutland <mark.rutland@....com> wrote:
>> > On Wed, Jan 13, 2016 at 01:51:10PM +0000, Mark Rutland wrote:
>> >> On Wed, Jan 13, 2016 at 09:39:41AM +0100, Ard Biesheuvel wrote:
>> >> > If I remove the rounding, I get false positive kasan errors which I
>> >> > have not quite diagnosed yet, but are probably due to the fact that
>> >> > the rounding performed by vmemmap_populate() goes in the wrong
>> >> > direction.
>> >
>> > As far as I can see, it implicitly rounds the base down and end up to
>> > SWAPPER_BLOCK_SIZE granularity.
>> >
>> > I can see that it might map too much memory, but I can't see why that
>> > should trigger KASAN failures. Regardless of what was mapped KASAN
>> > should stick to the region it cares about, and everything else should
>> > stay out of that.
>> >
>> > When do you see the failures, and are they in any way consistent?
>> >
>> > Do you have an example to hand?
>> >
>>
>> For some reason, this issue has evaporated, i.e., I can no longer
>> reproduce it on my WIP v4 branch.
>> So I will remove the rounding.
>
> Ok.
>
> I'll let you know if I stumble across anything that looks like a
> potential cause of the KASAN failures, and I'll try to give v4 a go at
> some point soon.
>
OK, I managed to track this down (I think). The issue here is that,
while vmemmap_populate() does the right thing wrt the start and end
boundaries, populate_zero_shadow() will map the adjoining regions down
to page granularity, replacing vmemmap_populate()'s PMD block mappings
with PMD table mappings. So I need to put back the rounding (I removed
it in v4)
Thanks,
Ard.
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.
