linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: linus.walleij@linaro.org (Linus Walleij)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 5/5] arm64: add KASan support
Date: Mon, 24 Aug 2015 15:45:18 +0200	[thread overview]
Message-ID: <CACRpkdYwpucRiXM05y00RQY=gKv8W6YjCNspYFRMGaM605cU0w@mail.gmail.com> (raw)
In-Reply-To: <20150824131557.GB7557@n2100.arm.linux.org.uk>

On Mon, Aug 24, 2015 at 3:15 PM, Russell King - ARM Linux
<linux@arm.linux.org.uk> wrote:
> On Tue, Jul 21, 2015 at 11:27:56PM +0200, Linus Walleij wrote:
>> On Tue, Jul 21, 2015 at 4:27 PM, Andrey Ryabinin <a.ryabinin@samsung.com> wrote:
>>
>> > I used vexpress. Anyway, it doesn't matter now, since I have an update
>> > with a lot of stuff fixed, and it works on hardware.
>> > I still need to do some work on it and tomorrow, probably, I will share.
>>
>> Ah awesome. I have a stash of ARM boards so I can test it on a
>> range of hardware once you feel it's ready.
>>
>> Sorry for pulling stuff out of your hands, people are excited about
>> KASan ARM32 as it turns out.
>
> People may be excited about it because it's a new feature, but we really
> need to consider whether gobbling up 512MB of userspace for it is a good
> idea or not.  There are programs around which like to map large amounts
> of memory into their process space, and the more we steal from them, the
> more likely these programs are to fail.

I looked at some different approaches over the last weeks for this
when playing around with KASan.

It seems since KASan was developed on 64bit systems, this was
not much of an issue for them as they could take their shadow
memory from the vmalloc space.

I think it is possible to actually just steal as much memory as is
needed to cover the kernel, and not 1/8 of the entire addressable
32bit space. So instead of covering all from 0x0-0xffffffff
at least just MODULES_VADDR thru 0xffffffff should be enough.
So if that is 0xbf000000-0xffffffff in most cases, 0x41000000
bytes, then 1/8 of that, 0x8200000, 130MB should be enough.
(Andrey need to say if this is possible.)

That will probably miss some usecases I'm not familiar with, where
the kernel is actually executing something below 0xbf000000...

I looked at taking memory from vmalloc instead, but ran into
problems since this is subject to the highmem split and KASan
need to have it's address offset at compile time. On
Ux500 I managed to remove all the static maps and steal memory
from the top of the vmalloc area instead of the beginning, but
that is probably not generally feasible.

I suspect you have better ideas than what I can come up
with though.

Yours,
Linus Walleij

  reply	other threads:[~2015-08-24 13:45 UTC|newest]

Thread overview: 42+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-05-15 13:58 [PATCH v2 0/5] KASan for arm64 Andrey Ryabinin
2015-05-15 13:59 ` [PATCH v2 1/5] kasan, x86: move KASAN_SHADOW_OFFSET to the arch Kconfig Andrey Ryabinin
2015-05-16 11:27   ` Paul Bolle
2015-05-18  7:43     ` Andrey Ryabinin
2015-05-18  8:34       ` Paul Bolle
2015-05-15 13:59 ` [PATCH v2 2/5] x86: kasan: fix types in kasan page tables declarations Andrey Ryabinin
2015-05-15 13:59 ` [PATCH v2 3/5] x86: kasan: generalize populate_zero_shadow() code Andrey Ryabinin
2015-05-15 13:59 ` [PATCH v2 4/5] kasan, x86: move populate_zero_shadow() out of arch directory Andrey Ryabinin
2015-05-15 13:59 ` [PATCH v2 5/5] arm64: add KASan support Andrey Ryabinin
2015-05-26 13:35   ` Linus Walleij
2015-05-26 14:12     ` Andrey Ryabinin
2015-05-26 14:22       ` Andrey Ryabinin
2015-05-26 20:28         ` Linus Walleij
2015-05-27 12:40   ` Linus Walleij
2015-06-11 13:39   ` Linus Walleij
2015-06-12 18:14     ` Andrey Ryabinin
2015-06-13 15:25       ` Linus Walleij
2015-06-17 21:32         ` Andrey Ryabinin
2015-07-21 10:36           ` Linus Walleij
2015-07-21 14:27             ` Andrey Ryabinin
2015-07-21 21:27               ` Linus Walleij
2015-07-22 17:54                 ` Andrey Ryabinin
2015-08-19 12:14                   ` Linus Walleij
2015-08-19 14:51                     ` Andrey Ryabinin
2015-08-24 13:02                       ` Linus Walleij
2015-08-24 13:15                 ` Russell King - ARM Linux
2015-08-24 13:45                   ` Linus Walleij [this message]
2015-08-24 14:15                     ` Andrey Ryabinin
2015-08-24 15:44                       ` Vladimir Murzin
2015-08-24 16:00                         ` Andrey Ryabinin
2015-08-24 16:16                           ` Vladimir Murzin
2015-08-24 16:18                             ` Andrey Ryabinin
2015-08-24 17:47                       ` Russell King - ARM Linux
2015-08-25  9:15                         ` Will Deacon
2015-07-08 15:48   ` Catalin Marinas
2015-07-10 17:11     ` Andrey Ryabinin
2015-07-14 15:04       ` Catalin Marinas
2015-07-15  8:55         ` Andrey Ryabinin
2015-07-15 16:37           ` Catalin Marinas
2015-07-16 15:30             ` Andrey Ryabinin
2015-07-16 16:03               ` Catalin Marinas
2015-07-17 13:13                 ` Andrey Ryabinin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CACRpkdYwpucRiXM05y00RQY=gKv8W6YjCNspYFRMGaM605cU0w@mail.gmail.com' \
    --to=linus.walleij@linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --subject='Re: [PATCH v2 5/5] arm64: add KASan support' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
on how to clone and mirror all data and code used for this inbox