From: vladimir.murzin@arm.com (Vladimir Murzin)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 5/5] arm64: add KASan support
Date: Mon, 24 Aug 2015 17:16:50 +0100 [thread overview]
Message-ID: <55DB4372.5010406@arm.com> (raw)
In-Reply-To: <CAPAsAGyg_oUvUrfSSQccVMcGtY_bwR8n6tf3tFsnh43YT6-b4w@mail.gmail.com>
On 24/08/15 17:00, Andrey Ryabinin wrote:
> 2015-08-24 18:44 GMT+03:00 Vladimir Murzin <vladimir.murzin@arm.com>:
>>
>> Another option would be having "sparse" shadow memory based on page
>> extension. I did play with that some time ago based on ideas from
>> original v1 KASan support for x86/arm - it is how 614be38 "irqchip:
>> gic-v3: Fix out of bounds access to cpu_logical_map" was caught.
>> It doesn't require any VA reservations, only some contiguous memory for
>> the page_ext itself, which serves as indirection level for the 0-order
>> shadow pages.
>
> We won't be able to use inline instrumentation (I could live with that),
> and most importantly, we won't be able to use stack instrumentation.
> GCC needs to know shadow address for inline and/or stack instrumentation
> to generate correct code.
It's definitely a trade-off ;)
Just for my understanding does that stack instrumentation is controlled
via -asan-stack?
Thanks
Vladimir
>
>> In theory such design can be reused by others 32-bit arches and, I
>> think, nommu too. Additionally, the shadow pages might be movable with
>> help of driver-page migration patch series [1].
>> The cost is obvious - performance drop, although I didn't bother
>> measuring it.
>>
>> [1] https://lwn.net/Articles/650917/
>>
>> Cheers
>> Vladimir
>>
>
WARNING: multiple messages have this Message-ID (diff)
From: Vladimir Murzin <vladimir.murzin@arm.com>
To: Andrey Ryabinin <ryabinin.a.a@gmail.com>
Cc: Linus Walleij <linus.walleij@linaro.org>,
Russell King - ARM Linux <linux@arm.linux.org.uk>,
Arnd Bergmann <arnd@arndb.de>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
Catalin Marinas <Catalin.Marinas@arm.com>,
Will Deacon <Will.Deacon@arm.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
David Keitel <dkeitel@codeaurora.org>,
Alexander Potapenko <glider@google.com>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
Andrew Morton <akpm@linux-foundation.org>,
Dmitry Vyukov <dvyukov@google.com>
Subject: Re: [PATCH v2 5/5] arm64: add KASan support
Date: Mon, 24 Aug 2015 17:16:50 +0100 [thread overview]
Message-ID: <55DB4372.5010406@arm.com> (raw)
In-Reply-To: <CAPAsAGyg_oUvUrfSSQccVMcGtY_bwR8n6tf3tFsnh43YT6-b4w@mail.gmail.com>
On 24/08/15 17:00, Andrey Ryabinin wrote:
> 2015-08-24 18:44 GMT+03:00 Vladimir Murzin <vladimir.murzin@arm.com>:
>>
>> Another option would be having "sparse" shadow memory based on page
>> extension. I did play with that some time ago based on ideas from
>> original v1 KASan support for x86/arm - it is how 614be38 "irqchip:
>> gic-v3: Fix out of bounds access to cpu_logical_map" was caught.
>> It doesn't require any VA reservations, only some contiguous memory for
>> the page_ext itself, which serves as indirection level for the 0-order
>> shadow pages.
>
> We won't be able to use inline instrumentation (I could live with that),
> and most importantly, we won't be able to use stack instrumentation.
> GCC needs to know shadow address for inline and/or stack instrumentation
> to generate correct code.
It's definitely a trade-off ;)
Just for my understanding does that stack instrumentation is controlled
via -asan-stack?
Thanks
Vladimir
>
>> In theory such design can be reused by others 32-bit arches and, I
>> think, nommu too. Additionally, the shadow pages might be movable with
>> help of driver-page migration patch series [1].
>> The cost is obvious - performance drop, although I didn't bother
>> measuring it.
>>
>> [1] https://lwn.net/Articles/650917/
>>
>> Cheers
>> Vladimir
>>
>
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
WARNING: multiple messages have this Message-ID (diff)
From: Vladimir Murzin <vladimir.murzin@arm.com>
To: Andrey Ryabinin <ryabinin.a.a@gmail.com>
Cc: Linus Walleij <linus.walleij@linaro.org>,
Russell King - ARM Linux <linux@arm.linux.org.uk>,
Arnd Bergmann <arnd@arndb.de>,
"linux-mm@kvack.org" <linux-mm@kvack.org>,
Catalin Marinas <Catalin.Marinas@arm.com>,
Will Deacon <Will.Deacon@arm.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
David Keitel <dkeitel@codeaurora.org>,
Alexander Potapenko <glider@google.com>,
"linux-arm-kernel@lists.infradead.org"
<linux-arm-kernel@lists.infradead.org>,
Andrew Morton <akpm@linux-foundation.org>,
Dmitry Vyukov <dvyukov@google.com>
Subject: Re: [PATCH v2 5/5] arm64: add KASan support
Date: Mon, 24 Aug 2015 17:16:50 +0100 [thread overview]
Message-ID: <55DB4372.5010406@arm.com> (raw)
In-Reply-To: <CAPAsAGyg_oUvUrfSSQccVMcGtY_bwR8n6tf3tFsnh43YT6-b4w@mail.gmail.com>
On 24/08/15 17:00, Andrey Ryabinin wrote:
> 2015-08-24 18:44 GMT+03:00 Vladimir Murzin <vladimir.murzin@arm.com>:
>>
>> Another option would be having "sparse" shadow memory based on page
>> extension. I did play with that some time ago based on ideas from
>> original v1 KASan support for x86/arm - it is how 614be38 "irqchip:
>> gic-v3: Fix out of bounds access to cpu_logical_map" was caught.
>> It doesn't require any VA reservations, only some contiguous memory for
>> the page_ext itself, which serves as indirection level for the 0-order
>> shadow pages.
>
> We won't be able to use inline instrumentation (I could live with that),
> and most importantly, we won't be able to use stack instrumentation.
> GCC needs to know shadow address for inline and/or stack instrumentation
> to generate correct code.
It's definitely a trade-off ;)
Just for my understanding does that stack instrumentation is controlled
via -asan-stack?
Thanks
Vladimir
>
>> In theory such design can be reused by others 32-bit arches and, I
>> think, nommu too. Additionally, the shadow pages might be movable with
>> help of driver-page migration patch series [1].
>> The cost is obvious - performance drop, although I didn't bother
>> measuring it.
>>
>> [1] https://lwn.net/Articles/650917/
>>
>> Cheers
>> Vladimir
>>
>
next prev parent reply other threads:[~2015-08-24 16:16 UTC|newest]
Thread overview: 127+ 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:58 ` Andrey Ryabinin
2015-05-15 13:58 ` 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-15 13:59 ` Andrey Ryabinin
2015-05-15 13:59 ` Andrey Ryabinin
2015-05-16 11:27 ` Paul Bolle
2015-05-16 11:27 ` Paul Bolle
2015-05-16 11:27 ` Paul Bolle
2015-05-18 7:43 ` Andrey Ryabinin
2015-05-18 7:43 ` Andrey Ryabinin
2015-05-18 7:43 ` Andrey Ryabinin
2015-05-18 8:34 ` Paul Bolle
2015-05-18 8:34 ` Paul Bolle
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 ` Andrey Ryabinin
2015-05-15 13:59 ` 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 ` Andrey Ryabinin
2015-05-15 13:59 ` 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 ` Andrey Ryabinin
2015-05-15 13:59 ` Andrey Ryabinin
2015-05-15 13:59 ` [PATCH v2 5/5] arm64: add KASan support Andrey Ryabinin
2015-05-15 13:59 ` Andrey Ryabinin
2015-05-15 13:59 ` Andrey Ryabinin
2015-05-26 13:35 ` Linus Walleij
2015-05-26 13:35 ` Linus Walleij
2015-05-26 13:35 ` Linus Walleij
2015-05-26 14:12 ` Andrey Ryabinin
2015-05-26 14:12 ` Andrey Ryabinin
2015-05-26 14:12 ` Andrey Ryabinin
2015-05-26 14:22 ` Andrey Ryabinin
2015-05-26 14:22 ` Andrey Ryabinin
2015-05-26 14:22 ` Andrey Ryabinin
2015-05-26 20:28 ` Linus Walleij
2015-05-26 20:28 ` Linus Walleij
2015-05-26 20:28 ` Linus Walleij
2015-05-27 12:40 ` Linus Walleij
2015-05-27 12:40 ` Linus Walleij
2015-05-27 12:40 ` Linus Walleij
2015-06-11 13:39 ` Linus Walleij
2015-06-11 13:39 ` Linus Walleij
2015-06-11 13:39 ` Linus Walleij
2015-06-12 18:14 ` Andrey Ryabinin
2015-06-12 18:14 ` Andrey Ryabinin
2015-06-12 18:14 ` Andrey Ryabinin
2015-06-13 15:25 ` Linus Walleij
2015-06-13 15:25 ` Linus Walleij
2015-06-13 15:25 ` Linus Walleij
2015-06-17 21:32 ` Andrey Ryabinin
2015-06-17 21:32 ` Andrey Ryabinin
2015-06-17 21:32 ` Andrey Ryabinin
2015-07-21 10:36 ` Linus Walleij
2015-07-21 10:36 ` Linus Walleij
2015-07-21 10:36 ` Linus Walleij
2015-07-21 14:27 ` Andrey Ryabinin
2015-07-21 14:27 ` Andrey Ryabinin
2015-07-21 14:27 ` Andrey Ryabinin
2015-07-21 21:27 ` Linus Walleij
2015-07-21 21:27 ` Linus Walleij
2015-07-21 21:27 ` Linus Walleij
2015-07-22 17:54 ` Andrey Ryabinin
2015-07-22 17:54 ` Andrey Ryabinin
2015-07-22 17:54 ` Andrey Ryabinin
2015-08-19 12:14 ` Linus Walleij
2015-08-19 12:14 ` Linus Walleij
2015-08-19 12:14 ` Linus Walleij
2015-08-19 14:51 ` Andrey Ryabinin
2015-08-19 14:51 ` Andrey Ryabinin
2015-08-19 14:51 ` Andrey Ryabinin
2015-08-24 13:02 ` Linus Walleij
2015-08-24 13:02 ` Linus Walleij
2015-08-24 13:02 ` Linus Walleij
2015-08-24 13:15 ` Russell King - ARM Linux
2015-08-24 13:15 ` Russell King - ARM Linux
2015-08-24 13:15 ` Russell King - ARM Linux
2015-08-24 13:45 ` Linus Walleij
2015-08-24 13:45 ` Linus Walleij
2015-08-24 13:45 ` Linus Walleij
2015-08-24 14:15 ` Andrey Ryabinin
2015-08-24 14:15 ` Andrey Ryabinin
2015-08-24 14:15 ` Andrey Ryabinin
2015-08-24 15:44 ` Vladimir Murzin
2015-08-24 15:44 ` Vladimir Murzin
2015-08-24 15:44 ` Vladimir Murzin
2015-08-24 16:00 ` Andrey Ryabinin
2015-08-24 16:00 ` Andrey Ryabinin
2015-08-24 16:00 ` Andrey Ryabinin
2015-08-24 16:16 ` Vladimir Murzin [this message]
2015-08-24 16:16 ` Vladimir Murzin
2015-08-24 16:16 ` Vladimir Murzin
2015-08-24 16:18 ` Andrey Ryabinin
2015-08-24 16:18 ` Andrey Ryabinin
2015-08-24 16:18 ` Andrey Ryabinin
2015-08-24 17:47 ` Russell King - ARM Linux
2015-08-24 17:47 ` Russell King - ARM Linux
2015-08-24 17:47 ` Russell King - ARM Linux
2015-08-25 9:15 ` Will Deacon
2015-08-25 9:15 ` Will Deacon
2015-08-25 9:15 ` Will Deacon
2015-07-08 15:48 ` Catalin Marinas
2015-07-08 15:48 ` Catalin Marinas
2015-07-08 15:48 ` Catalin Marinas
2015-07-10 17:11 ` Andrey Ryabinin
2015-07-10 17:11 ` Andrey Ryabinin
2015-07-10 17:11 ` Andrey Ryabinin
2015-07-14 15:04 ` Catalin Marinas
2015-07-14 15:04 ` Catalin Marinas
2015-07-14 15:04 ` Catalin Marinas
2015-07-15 8:55 ` Andrey Ryabinin
2015-07-15 8:55 ` Andrey Ryabinin
2015-07-15 8:55 ` Andrey Ryabinin
2015-07-15 16:37 ` Catalin Marinas
2015-07-15 16:37 ` Catalin Marinas
2015-07-15 16:37 ` Catalin Marinas
2015-07-16 15:30 ` Andrey Ryabinin
2015-07-16 15:30 ` Andrey Ryabinin
2015-07-16 15:30 ` Andrey Ryabinin
2015-07-16 16:03 ` Catalin Marinas
2015-07-16 16:03 ` Catalin Marinas
2015-07-16 16:03 ` Catalin Marinas
2015-07-17 13:13 ` Andrey Ryabinin
2015-07-17 13:13 ` Andrey Ryabinin
2015-07-17 13:13 ` Andrey Ryabinin
2015-07-18 2:44 ` Patrick Daly
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=55DB4372.5010406@arm.com \
--to=vladimir.murzin@arm.com \
--cc=linux-arm-kernel@lists.infradead.org \
/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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.