On Mon, Aug 24, 2015 at 06:47:36PM +0100, Russell King - ARM Linux wrote:
> On Mon, Aug 24, 2015 at 05:15:22PM +0300, Andrey Ryabinin wrote:
> > Yes, ~130Mb (3G/1G split) should work. 512Mb shadow is optional.
> > The only advantage of 512Mb shadow is better handling of user memory
> > accesses
On Mon, Aug 24, 2015 at 06:47:36PM +0100, Russell King - ARM Linux wrote:
On Mon, Aug 24, 2015 at 05:15:22PM +0300, Andrey Ryabinin wrote:
Yes, ~130Mb (3G/1G split) should work. 512Mb shadow is optional.
The only advantage of 512Mb shadow is better handling of user memory
accesses bugs
On Mon, Aug 24, 2015 at 05:15:22PM +0300, Andrey Ryabinin wrote:
> Yes, ~130Mb (3G/1G split) should work. 512Mb shadow is optional.
> The only advantage of 512Mb shadow is better handling of user memory
> accesses bugs
> (access to user memory without copy_from_user/copy_to_user/strlen_user etc
>
2015-08-24 19:16 GMT+03:00 Vladimir Murzin :
> On 24/08/15 17:00, Andrey Ryabinin wrote:
>> 2015-08-24 18:44 GMT+03:00 Vladimir Murzin :
>>>
>>> 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
On 24/08/15 17:00, Andrey Ryabinin wrote:
> 2015-08-24 18:44 GMT+03:00 Vladimir Murzin :
>>
>> 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
2015-08-24 18:44 GMT+03:00 Vladimir Murzin :
>
> 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
On 24/08/15 15:15, Andrey Ryabinin wrote:
> 2015-08-24 16:45 GMT+03:00 Linus Walleij :
>> On Mon, Aug 24, 2015 at 3:15 PM, Russell King - ARM Linux
>> 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
wrote:
2015-08-24 16:45 GMT+03:00 Linus Walleij :
> On Mon, Aug 24, 2015 at 3:15 PM, Russell King - ARM Linux
> 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
>>> wrote:
>>>
>>> > I used vexpress. Anyway, it doesn't matter
On Mon, Aug 24, 2015 at 3:15 PM, Russell King - ARM Linux
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
>> wrote:
>>
>> > I used vexpress. Anyway, it doesn't matter now, since I have an update
>> > with a lot of stuff
On Tue, Jul 21, 2015 at 11:27:56PM +0200, Linus Walleij wrote:
> On Tue, Jul 21, 2015 at 4:27 PM, Andrey Ryabinin
> 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
On Wed, Aug 19, 2015 at 4:51 PM, Andrey Ryabinin wrote:
> On 08/19/2015 03:14 PM, Linus Walleij wrote:
>> Integrator/AP (ARMv5):
>>
>> This one mounted with an ARMv5 ARM926 tile. It boots nicely
>> (but takes forever) with KASan and run all test cases (!) just like
>> for the other platforms but
On Mon, Aug 24, 2015 at 3:15 PM, Russell King - ARM Linux
li...@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.ryabi...@samsung.com
wrote:
I used vexpress. Anyway, it doesn't matter now, since I have
On Wed, Aug 19, 2015 at 4:51 PM, Andrey Ryabinin ryabinin@gmail.com wrote:
On 08/19/2015 03:14 PM, Linus Walleij wrote:
Integrator/AP (ARMv5):
This one mounted with an ARMv5 ARM926 tile. It boots nicely
(but takes forever) with KASan and run all test cases (!) just like
for the other
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.ryabi...@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
2015-08-24 16:45 GMT+03:00 Linus Walleij linus.wall...@linaro.org:
On Mon, Aug 24, 2015 at 3:15 PM, Russell King - ARM Linux
li...@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.ryabi...@samsung.com
2015-08-24 19:16 GMT+03:00 Vladimir Murzin vladimir.mur...@arm.com:
On 24/08/15 17:00, Andrey Ryabinin wrote:
2015-08-24 18:44 GMT+03:00 Vladimir Murzin vladimir.mur...@arm.com:
Another option would be having sparse shadow memory based on page
extension. I did play with that some time ago
2015-08-24 18:44 GMT+03:00 Vladimir Murzin vladimir.mur...@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
On 24/08/15 17:00, Andrey Ryabinin wrote:
2015-08-24 18:44 GMT+03:00 Vladimir Murzin vladimir.mur...@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
On 24/08/15 15:15, Andrey Ryabinin wrote:
2015-08-24 16:45 GMT+03:00 Linus Walleij linus.wall...@linaro.org:
On Mon, Aug 24, 2015 at 3:15 PM, Russell King - ARM Linux
li...@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,
On Mon, Aug 24, 2015 at 05:15:22PM +0300, Andrey Ryabinin wrote:
Yes, ~130Mb (3G/1G split) should work. 512Mb shadow is optional.
The only advantage of 512Mb shadow is better handling of user memory
accesses bugs
(access to user memory without copy_from_user/copy_to_user/strlen_user etc
On 08/19/2015 03:14 PM, Linus Walleij wrote:
> On Wed, Jul 22, 2015 at 7:54 PM, Andrey Ryabinin
> wrote:
>
>> So here is updated version:
>> git://github.com/aryabinin/linux.git kasan/arm_v0_1
>>
>> The code is still ugly in some places and it probably have some bugs.
>> Lightly tested
On Wed, Jul 22, 2015 at 7:54 PM, Andrey Ryabinin wrote:
> So here is updated version:
> git://github.com/aryabinin/linux.git kasan/arm_v0_1
>
> The code is still ugly in some places and it probably have some bugs.
> Lightly tested on exynos 5410/5420.
I compiled this for various ARM
On Wed, Jul 22, 2015 at 7:54 PM, Andrey Ryabinin a.ryabi...@samsung.com wrote:
So here is updated version:
git://github.com/aryabinin/linux.git kasan/arm_v0_1
The code is still ugly in some places and it probably have some bugs.
Lightly tested on exynos 5410/5420.
I compiled this
On 08/19/2015 03:14 PM, Linus Walleij wrote:
On Wed, Jul 22, 2015 at 7:54 PM, Andrey Ryabinin a.ryabi...@samsung.com
wrote:
So here is updated version:
git://github.com/aryabinin/linux.git kasan/arm_v0_1
The code is still ugly in some places and it probably have some bugs.
On 07/22/2015 12:27 AM, Linus Walleij wrote:
> On Tue, Jul 21, 2015 at 4:27 PM, Andrey Ryabinin
> 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,
On 07/22/2015 12:27 AM, Linus Walleij wrote:
On Tue, Jul 21, 2015 at 4:27 PM, Andrey Ryabinin a.ryabi...@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
On Tue, Jul 21, 2015 at 4:27 PM, Andrey Ryabinin 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
On 07/21/2015 01:36 PM, Linus Walleij wrote:
> On Wed, Jun 17, 2015 at 11:32 PM, Andrey Ryabinin
> wrote:
>> 2015-06-13 18:25 GMT+03:00 Linus Walleij :
>>>
>>> On Fri, Jun 12, 2015 at 8:14 PM, Andrey Ryabinin
>>> wrote:
2015-06-11 16:39 GMT+03:00 Linus Walleij :
> On Fri, May 15, 2015
On Wed, Jun 17, 2015 at 11:32 PM, Andrey Ryabinin
wrote:
> 2015-06-13 18:25 GMT+03:00 Linus Walleij :
>>
>> On Fri, Jun 12, 2015 at 8:14 PM, Andrey Ryabinin
>> wrote:
>> > 2015-06-11 16:39 GMT+03:00 Linus Walleij :
>> >> On Fri, May 15, 2015 at 3:59 PM, Andrey Ryabinin
>> >> wrote:
>> >>
>>
On Tue, Jul 21, 2015 at 4:27 PM, Andrey Ryabinin a.ryabi...@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
On Wed, Jun 17, 2015 at 11:32 PM, Andrey Ryabinin
ryabinin@gmail.com wrote:
2015-06-13 18:25 GMT+03:00 Linus Walleij linus.wall...@linaro.org:
On Fri, Jun 12, 2015 at 8:14 PM, Andrey Ryabinin ryabinin@gmail.com
wrote:
2015-06-11 16:39 GMT+03:00 Linus Walleij
On 07/21/2015 01:36 PM, Linus Walleij wrote:
On Wed, Jun 17, 2015 at 11:32 PM, Andrey Ryabinin
ryabinin@gmail.com wrote:
2015-06-13 18:25 GMT+03:00 Linus Walleij linus.wall...@linaro.org:
On Fri, Jun 12, 2015 at 8:14 PM, Andrey Ryabinin ryabinin@gmail.com
wrote:
2015-06-11 16:39
On 07/16/2015 07:03 PM, Catalin Marinas wrote:
> On Thu, Jul 16, 2015 at 06:30:11PM +0300, Andrey Ryabinin wrote:
>>
>> I think this may work, if pud_none(*pud) will be replaced with
>> !pud_val(*pud).
>> We can't use pud_none() because with 2-level page tables it's always false,
>> so
>> we
On 07/16/2015 07:03 PM, Catalin Marinas wrote:
On Thu, Jul 16, 2015 at 06:30:11PM +0300, Andrey Ryabinin wrote:
I think this may work, if pud_none(*pud) will be replaced with
!pud_val(*pud).
We can't use pud_none() because with 2-level page tables it's always false,
so
we will never go
On Thu, Jul 16, 2015 at 06:30:11PM +0300, Andrey Ryabinin wrote:
> On 07/15/2015 07:37 PM, Catalin Marinas wrote:
> > Ok, so simply taking the call out of the loop won't work unless we
> > conditionally define these functions (wouldn't be too bad since we have
> > some #if CONFIG_PGTABLE_LEVELS
On 07/15/2015 07:37 PM, Catalin Marinas wrote:
> Ok, so simply taking the call out of the loop won't work unless we
> conditionally define these functions (wouldn't be too bad since we have
> some #if CONFIG_PGTABLE_LEVELS already introduced by this patch but it
> would be nicer without).
>
>
On 07/15/2015 07:37 PM, Catalin Marinas wrote:
Ok, so simply taking the call out of the loop won't work unless we
conditionally define these functions (wouldn't be too bad since we have
some #if CONFIG_PGTABLE_LEVELS already introduced by this patch but it
would be nicer without).
Anyway, I
On Thu, Jul 16, 2015 at 06:30:11PM +0300, Andrey Ryabinin wrote:
On 07/15/2015 07:37 PM, Catalin Marinas wrote:
Ok, so simply taking the call out of the loop won't work unless we
conditionally define these functions (wouldn't be too bad since we have
some #if CONFIG_PGTABLE_LEVELS already
On Wed, Jul 15, 2015 at 11:55:20AM +0300, Andrey Ryabinin wrote:
> On 07/14/2015 06:04 PM, Catalin Marinas wrote:
> > On Fri, Jul 10, 2015 at 08:11:03PM +0300, Andrey Ryabinin wrote:
> >>> kasan_early_pte_populate();
> >>> kasan_early_pmd_populate(..., pte);
> >>>
On 07/14/2015 06:04 PM, Catalin Marinas wrote:
> On Fri, Jul 10, 2015 at 08:11:03PM +0300, Andrey Ryabinin wrote:
+#if CONFIG_PGTABLE_LEVELS > 3
+pud_t kasan_zero_pud[PTRS_PER_PUD] __page_aligned_bss;
+#endif
+#if CONFIG_PGTABLE_LEVELS > 2
+pmd_t
On 07/14/2015 06:04 PM, Catalin Marinas wrote:
On Fri, Jul 10, 2015 at 08:11:03PM +0300, Andrey Ryabinin wrote:
+#if CONFIG_PGTABLE_LEVELS 3
+pud_t kasan_zero_pud[PTRS_PER_PUD] __page_aligned_bss;
+#endif
+#if CONFIG_PGTABLE_LEVELS 2
+pmd_t kasan_zero_pmd[PTRS_PER_PMD] __page_aligned_bss;
On Wed, Jul 15, 2015 at 11:55:20AM +0300, Andrey Ryabinin wrote:
On 07/14/2015 06:04 PM, Catalin Marinas wrote:
On Fri, Jul 10, 2015 at 08:11:03PM +0300, Andrey Ryabinin wrote:
kasan_early_pte_populate();
kasan_early_pmd_populate(..., pte);
kasan_early_pud_populate(..., pmd);
On Fri, Jul 10, 2015 at 08:11:03PM +0300, Andrey Ryabinin wrote:
> >> +#if CONFIG_PGTABLE_LEVELS > 3
> >> +pud_t kasan_zero_pud[PTRS_PER_PUD] __page_aligned_bss;
> >> +#endif
> >> +#if CONFIG_PGTABLE_LEVELS > 2
> >> +pmd_t kasan_zero_pmd[PTRS_PER_PMD] __page_aligned_bss;
> >> +#endif
> >> +pte_t
On Fri, Jul 10, 2015 at 08:11:03PM +0300, Andrey Ryabinin wrote:
+#if CONFIG_PGTABLE_LEVELS 3
+pud_t kasan_zero_pud[PTRS_PER_PUD] __page_aligned_bss;
+#endif
+#if CONFIG_PGTABLE_LEVELS 2
+pmd_t kasan_zero_pmd[PTRS_PER_PMD] __page_aligned_bss;
+#endif
+pte_t
>> select HAVE_ARCH_KGDB
>> select HAVE_ARCH_SECCOMP_FILTER
>> select HAVE_ARCH_TRACEHOOK
>> @@ -119,6 +120,12 @@ config GENERIC_CSUM
>> config GENERIC_CALIBRATE_DELAY
>> def_bool y
>>
>> +config KASAN_SHADOW_OFFSET
>> +hex
>> +default 0xdfff2000 if
select HAVE_ARCH_KGDB
select HAVE_ARCH_SECCOMP_FILTER
select HAVE_ARCH_TRACEHOOK
@@ -119,6 +120,12 @@ config GENERIC_CSUM
config GENERIC_CALIBRATE_DELAY
def_bool y
+config KASAN_SHADOW_OFFSET
+hex
+default 0xdfff2000 if ARM64_VA_BITS_48
+
On Fri, May 15, 2015 at 04:59:04PM +0300, Andrey Ryabinin wrote:
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index 7796af4..4cc73cc 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -44,6 +44,7 @@ config ARM64
> select HAVE_ARCH_AUDITSYSCALL
> select
On Fri, May 15, 2015 at 04:59:04PM +0300, Andrey Ryabinin wrote:
diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 7796af4..4cc73cc 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -44,6 +44,7 @@ config ARM64
select HAVE_ARCH_AUDITSYSCALL
select
2015-06-13 18:25 GMT+03:00 Linus Walleij :
>
> On Fri, Jun 12, 2015 at 8:14 PM, Andrey Ryabinin
> wrote:
> > 2015-06-11 16:39 GMT+03:00 Linus Walleij :
> >> On Fri, May 15, 2015 at 3:59 PM, Andrey Ryabinin
> >> wrote:
> >>
> >>> This patch adds arch specific code for kernel address sanitizer
>
2015-06-13 18:25 GMT+03:00 Linus Walleij linus.wall...@linaro.org:
On Fri, Jun 12, 2015 at 8:14 PM, Andrey Ryabinin ryabinin@gmail.com
wrote:
2015-06-11 16:39 GMT+03:00 Linus Walleij linus.wall...@linaro.org:
On Fri, May 15, 2015 at 3:59 PM, Andrey Ryabinin a.ryabi...@samsung.com
On Fri, Jun 12, 2015 at 8:14 PM, Andrey Ryabinin wrote:
> 2015-06-11 16:39 GMT+03:00 Linus Walleij :
>> On Fri, May 15, 2015 at 3:59 PM, Andrey Ryabinin
>> wrote:
>>
>>> This patch adds arch specific code for kernel address sanitizer
>>> (see Documentation/kasan.txt).
>>
>> I looked closer at
On Fri, Jun 12, 2015 at 8:14 PM, Andrey Ryabinin ryabinin@gmail.com wrote:
2015-06-11 16:39 GMT+03:00 Linus Walleij linus.wall...@linaro.org:
On Fri, May 15, 2015 at 3:59 PM, Andrey Ryabinin a.ryabi...@samsung.com
wrote:
This patch adds arch specific code for kernel address sanitizer
2015-06-11 16:39 GMT+03:00 Linus Walleij :
> On Fri, May 15, 2015 at 3:59 PM, Andrey Ryabinin
> wrote:
>
>> This patch adds arch specific code for kernel address sanitizer
>> (see Documentation/kasan.txt).
>
> I looked closer at this again ... I am trying to get KASan up for
> ARM(32) with some
2015-06-11 16:39 GMT+03:00 Linus Walleij linus.wall...@linaro.org:
On Fri, May 15, 2015 at 3:59 PM, Andrey Ryabinin a.ryabi...@samsung.com
wrote:
This patch adds arch specific code for kernel address sanitizer
(see Documentation/kasan.txt).
I looked closer at this again ... I am trying to
On Fri, May 15, 2015 at 3:59 PM, Andrey Ryabinin wrote:
> This patch adds arch specific code for kernel address sanitizer
> (see Documentation/kasan.txt).
I looked closer at this again ... I am trying to get KASan up for
ARM(32) with some tricks and hacks.
> +config KASAN_SHADOW_OFFSET
> +
On Fri, May 15, 2015 at 3:59 PM, Andrey Ryabinin a.ryabi...@samsung.com wrote:
This patch adds arch specific code for kernel address sanitizer
(see Documentation/kasan.txt).
I looked closer at this again ... I am trying to get KASan up for
ARM(32) with some tricks and hacks.
+config
On Fri, May 15, 2015 at 3:59 PM, Andrey Ryabinin wrote:
> This patch adds arch specific code for kernel address sanitizer
> (see Documentation/kasan.txt).
OK fixed a newer GCC (4.9.3, so still just KASAN_OUTLINE), compiled
and booted on the ARM Juno Development System:
kasan test:
On Fri, May 15, 2015 at 3:59 PM, Andrey Ryabinin a.ryabi...@samsung.com wrote:
This patch adds arch specific code for kernel address sanitizer
(see Documentation/kasan.txt).
OK fixed a newer GCC (4.9.3, so still just KASAN_OUTLINE), compiled
and booted on the ARM Juno Development System:
On Tue, May 26, 2015 at 4:22 PM, Andrey Ryabinin wrote:
> On 05/26/2015 05:12 PM, Andrey Ryabinin wrote:
>> On 05/26/2015 04:35 PM, Linus Walleij wrote:
>>> I wonder were the problem lies, any hints where to start looking
>>> to fix this?
>>>
>>
>> I suspect that your compiler lack
On 05/26/2015 05:12 PM, Andrey Ryabinin wrote:
> On 05/26/2015 04:35 PM, Linus Walleij wrote:
>> I wonder were the problem lies, any hints where to start looking
>> to fix this?
>>
>
> I suspect that your compiler lack -fsantize=kernel-address support.
> It seems that GCC 4.9.2 doesn't supports
On 05/26/2015 04:35 PM, Linus Walleij wrote:
> On Fri, May 15, 2015 at 3:59 PM, Andrey Ryabinin
> wrote:
>
> And then at boot I just get this:
>
> kasan test: kmalloc_oob_right out-of-bounds to right
> kasan test: kmalloc_oob_left out-of-bounds to left
> kasan test: kmalloc_node_oob_right
On Fri, May 15, 2015 at 3:59 PM, Andrey Ryabinin wrote:
> This patch adds arch specific code for kernel address sanitizer
> (see Documentation/kasan.txt).
I'm trying to test this on the Juno hardware (39 VA bits).
I get this at boot:
Virtual kernel memory layout:
kasan :
On Tue, May 26, 2015 at 4:22 PM, Andrey Ryabinin a.ryabi...@samsung.com wrote:
On 05/26/2015 05:12 PM, Andrey Ryabinin wrote:
On 05/26/2015 04:35 PM, Linus Walleij wrote:
I wonder were the problem lies, any hints where to start looking
to fix this?
I suspect that your compiler lack
On Fri, May 15, 2015 at 3:59 PM, Andrey Ryabinin a.ryabi...@samsung.com wrote:
This patch adds arch specific code for kernel address sanitizer
(see Documentation/kasan.txt).
I'm trying to test this on the Juno hardware (39 VA bits).
I get this at boot:
Virtual kernel memory layout:
kasan
On 05/26/2015 05:12 PM, Andrey Ryabinin wrote:
On 05/26/2015 04:35 PM, Linus Walleij wrote:
I wonder were the problem lies, any hints where to start looking
to fix this?
I suspect that your compiler lack -fsantize=kernel-address support.
It seems that GCC 4.9.2 doesn't supports
On 05/26/2015 04:35 PM, Linus Walleij wrote:
On Fri, May 15, 2015 at 3:59 PM, Andrey Ryabinin a.ryabi...@samsung.com
wrote:
And then at boot I just get this:
kasan test: kmalloc_oob_right out-of-bounds to right
kasan test: kmalloc_oob_left out-of-bounds to left
kasan test:
This patch adds arch specific code for kernel address sanitizer
(see Documentation/kasan.txt).
1/8 of kernel addresses reserved for shadow memory. There was no
big enough hole for this, so virtual addresses for shadow were
stolen from vmalloc area.
At early boot stage the whole shadow region
This patch adds arch specific code for kernel address sanitizer
(see Documentation/kasan.txt).
1/8 of kernel addresses reserved for shadow memory. There was no
big enough hole for this, so virtual addresses for shadow were
stolen from vmalloc area.
At early boot stage the whole shadow region
68 matches
Mail list logo
