From: Daniel Axtens <hidden> Date: 2019-02-15 00:06:43
Building on the work of Christophe, Aneesh and Balbir, I've ported
KASAN to the e6500, a 64-bit Book3E processor which doesn't have a
hashed page table. It applies on top of Christophe's series, v5.
It requires some changes to the KASAN core - please let me know if
these are problematic and we see if an alternative approach is
possible.
The KASAN shadow area is mapped into vmemmap space:
0x8000 0400 0000 0000 to 0x8000 0600 0000 0000.
To do this we require that vmemmap be disabled. (This is the default
in the kernel config that QorIQ provides for the machine in their
SDK anyway - they use flat memory.)
Only outline instrumentation is supported and only KASAN_MINIMAL works.
Only the kernel linear mapping (0xc000...) is checked. The vmalloc and
ioremap areas (also in 0x800...) are all mapped to a zero page. As
with the Book3S hash series, this requires overriding the memory <->
shadow mapping.
Also, as with both previous 64-bit series, early instrumentation is not
supported.
KVM, kexec and xmon have not been tested.
Thanks to those who have done the heavy lifting over the past several years:
- Christophe's 32 bit series: https://lists.ozlabs.org/pipermail/linuxppc-dev/2019-February/185379.html
- Aneesh's Book3S hash series: https://lwn.net/Articles/655642/
- Balbir's Book3S radix series: https://patchwork.ozlabs.org/patch/795211/
While useful if you have an Book3E device, this is mostly intended
as a warm-up exercise for reviving Aneesh's series for book3s hash.
In particular, changes to the kasan core are going to be required
for hash and radix as well.
Regards,
Daniel
Daniel Axtens (5):
kasan: do not open-code addr_has_shadow
kasan: allow architectures to manage the memory-to-shadow mapping
kasan: allow architectures to provide an outline readiness check
powerpc: move KASAN into its own subdirectory
powerpc: KASAN for 64bit Book3E
arch/powerpc/Kconfig | 1 +
arch/powerpc/Makefile | 2 +
arch/powerpc/include/asm/kasan.h | 77 +++++++++++++++++--
arch/powerpc/include/asm/ppc_asm.h | 7 ++
arch/powerpc/include/asm/string.h | 7 +-
arch/powerpc/lib/mem_64.S | 6 +-
arch/powerpc/lib/memcmp_64.S | 5 +-
arch/powerpc/lib/memcpy_64.S | 3 +-
arch/powerpc/lib/string.S | 15 ++--
arch/powerpc/mm/Makefile | 4 +-
arch/powerpc/mm/kasan/Makefile | 6 ++
.../{kasan_init.c => kasan/kasan_init_32.c} | 0
arch/powerpc/mm/kasan/kasan_init_book3e_64.c | 53 +++++++++++++
arch/powerpc/purgatory/Makefile | 3 +
arch/powerpc/xmon/Makefile | 1 +
include/linux/kasan.h | 6 ++
mm/kasan/generic.c | 5 +-
mm/kasan/generic_report.c | 2 +-
mm/kasan/kasan.h | 6 +-
mm/kasan/report.c | 6 +-
mm/kasan/tags.c | 3 +-
21 files changed, 188 insertions(+), 30 deletions(-)
create mode 100644 arch/powerpc/mm/kasan/Makefile
rename arch/powerpc/mm/{kasan_init.c => kasan/kasan_init_32.c} (100%)
create mode 100644 arch/powerpc/mm/kasan/kasan_init_book3e_64.c
--
2.19.1
From: Daniel Axtens <hidden> Date: 2019-02-15 00:08:15
We have a couple of places checking for the existence of a shadow
mapping for an address by open-coding the inverse of the check in
addr_has_shadow.
Replace the open-coded versions with the helper. This will be
needed in future to allow architectures to override the layout
of the shadow mapping.
Signed-off-by: Daniel Axtens <redacted>
---
mm/kasan/generic.c | 3 +--
mm/kasan/tags.c | 3 +--
2 files changed, 2 insertions(+), 4 deletions(-)
From: Daniel Axtens <hidden> Date: 2019-02-15 00:09:40
Currently, shadow addresses are always addr >> shift + offset.
However, for powerpc, the virtual address space is fragmented in
ways that make this simple scheme impractical.
Allow architectures to override:
- kasan_shadow_to_mem
- kasan_mem_to_shadow
- addr_has_shadow
Rename addr_has_shadow to kasan_addr_has_shadow as if it is
overridden it will be available in more places, increasing the
risk of collisions.
If architectures do not #define their own versions, the generic
code will continue to run as usual.
Signed-off-by: Daniel Axtens <redacted>
---
include/linux/kasan.h | 2 ++
mm/kasan/generic.c | 2 +-
mm/kasan/generic_report.c | 2 +-
mm/kasan/kasan.h | 6 +++++-
mm/kasan/report.c | 6 +++---
mm/kasan/tags.c | 2 +-
6 files changed, 13 insertions(+), 7 deletions(-)
From: Daniel Axtens <hidden> Date: 2019-02-15 00:11:22
In powerpc (as I understand it), we spend a lot of time in boot
running in real mode before MMU paging is initalised. During
this time we call a lot of generic code, including printk(). If
we try to access the shadow region during this time, things fail.
My attempts to move early init before the first printk have not
been successful. (Both previous RFCs for ppc64 - by 2 different
people - have needed this trick too!)
So, allow architectures to define a check_return_arch_not_ready()
hook that bails out of check_memory_region_inline() unless the
arch has done all of the init.
Link: https://lore.kernel.org/patchwork/patch/592820/ # ppc64 hash series
Link: https://patchwork.ozlabs.org/patch/795211/ # ppc radix series
Originally-by: Balbir Singh [off-list ref]
Cc: Aneesh Kumar K.V <redacted>
Signed-off-by: Daniel Axtens <redacted>
---
include/linux/kasan.h | 4 ++++
mm/kasan/generic.c | 2 ++
2 files changed, 6 insertions(+)
diff --git a/arch/powerpc/mm/kasan_init.c b/arch/powerpc/mm/kasan/kasan_init_32.csimilarity index 100%rename from arch/powerpc/mm/kasan_init.crename to arch/powerpc/mm/kasan/kasan_init_32.c
--
2.19.1
From: Daniel Axtens <hidden> Date: 2019-02-15 00:14:46
Wire up KASAN. Only outline instrumentation is supported.
The KASAN shadow area is mapped into vmemmap space:
0x8000 0400 0000 0000 to 0x8000 0600 0000 0000.
To do this we require that vmemmap be disabled. (This is the default
in the kernel config that QorIQ provides for the machine in their
SDK anyway - they use flat memory.)
Only the kernel linear mapping (0xc000...) is checked. The vmalloc and
ioremap areas (also in 0x800...) are all mapped to a zero page. As
with the Book3S hash series, this requires overriding the memory <->
shadow mapping.
Also, as with both previous 64-bit series, early instrumentation is not
supported. It would allow us to drop the check_return_arch_not_ready()
hook in the KASAN core, but it's tricky to get it set up early enough:
we need it setup before the first call to instrumented code like printk().
Perhaps in the future.
Only KASAN_MINIMAL works.
Lightly tested on e6500. KVM, kexec and xmon have not been tested.
The test_kasan module fires warnings as expected, except for the
following tests:
- Expected/by design:
kasan test: memcg_accounted_kmem_cache allocate memcg accounted object
- Due to only supporting KASAN_MINIMAL:
kasan test: kasan_stack_oob out-of-bounds on stack
kasan test: kasan_global_oob out-of-bounds global variable
kasan test: kasan_alloca_oob_left out-of-bounds to left on alloca
kasan test: kasan_alloca_oob_right out-of-bounds to right on alloca
kasan test: use_after_scope_test use-after-scope on int
kasan test: use_after_scope_test use-after-scope on array
Thanks to those who have done the heavy lifting over the past several years:
- Christophe's 32 bit series: https://lists.ozlabs.org/pipermail/linuxppc-dev/2019-February/185379.html
- Aneesh's Book3S hash series: https://lwn.net/Articles/655642/
- Balbir's Book3S radix series: https://patchwork.ozlabs.org/patch/795211/
Cc: Christophe Leroy <redacted>
Cc: Aneesh Kumar K.V <redacted>
Cc: Balbir Singh <bsingharora@gmail.com>
Signed-off-by: Daniel Axtens <redacted>
---
While useful if you have a book3e device, this is mostly intended
as a warm-up exercise for reviving Aneesh's series for book3s hash.
In particular, changes to the kasan core are going to be required
for hash and radix as well.
---
arch/powerpc/Kconfig | 1 +
arch/powerpc/Makefile | 2 +
arch/powerpc/include/asm/kasan.h | 77 ++++++++++++++++++--
arch/powerpc/include/asm/ppc_asm.h | 7 ++
arch/powerpc/include/asm/string.h | 7 +-
arch/powerpc/lib/mem_64.S | 6 +-
arch/powerpc/lib/memcmp_64.S | 5 +-
arch/powerpc/lib/memcpy_64.S | 3 +-
arch/powerpc/lib/string.S | 15 ++--
arch/powerpc/mm/Makefile | 2 +
arch/powerpc/mm/kasan/Makefile | 1 +
arch/powerpc/mm/kasan/kasan_init_book3e_64.c | 53 ++++++++++++++
arch/powerpc/purgatory/Makefile | 3 +
arch/powerpc/xmon/Makefile | 1 +
14 files changed, 164 insertions(+), 19 deletions(-)
create mode 100644 arch/powerpc/mm/kasan/kasan_init_book3e_64.c
From: Andrew Donnellan <hidden> Date: 2019-02-15 00:16:32
On 15/2/19 11:04 am, Daniel Axtens wrote:
We have a couple of places checking for the existence of a shadow
mapping for an address by open-coding the inverse of the check in
addr_has_shadow.
Replace the open-coded versions with the helper. This will be
needed in future to allow architectures to override the layout
of the shadow mapping.
Signed-off-by: Daniel Axtens <redacted>
diff --git a/arch/powerpc/mm/kasan_init.c b/arch/powerpc/mm/kasan/kasan_init_32.csimilarity index 100%rename from arch/powerpc/mm/kasan_init.crename to arch/powerpc/mm/kasan/kasan_init_32.c
--
Andrew Donnellan OzLabs, ADL Canberra
andrew.donnellan@au1.ibm.com IBM Australia Limited
On Fri, Feb 15, 2019 at 1:05 AM Daniel Axtens [off-list ref] wrote:
Currently, shadow addresses are always addr >> shift + offset.
However, for powerpc, the virtual address space is fragmented in
ways that make this simple scheme impractical.
Allow architectures to override:
- kasan_shadow_to_mem
- kasan_mem_to_shadow
- addr_has_shadow
Rename addr_has_shadow to kasan_addr_has_shadow as if it is
overridden it will be available in more places, increasing the
risk of collisions.
If architectures do not #define their own versions, the generic
code will continue to run as usual.
Signed-off-by: Daniel Axtens <redacted>
2.19.1
--
You received this message because you are subscribed to the Google Groups "kasan-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kasan-dev+unsubscribe@googlegroups.com.
To post to this group, send email to kasan-dev@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kasan-dev/20190215000441.14323-3-dja%40axtens.net.
For more options, visit https://groups.google.com/d/optout.
On Fri, Feb 15, 2019 at 1:12 AM Andrew Donnellan
[off-list ref] wrote:
On 15/2/19 11:04 am, Daniel Axtens wrote:
quoted
We have a couple of places checking for the existence of a shadow
mapping for an address by open-coding the inverse of the check in
addr_has_shadow.
Replace the open-coded versions with the helper. This will be
needed in future to allow architectures to override the layout
of the shadow mapping.
Signed-off-by: Daniel Axtens <redacted>
--
Andrew Donnellan OzLabs, ADL Canberra
andrew.donnellan@au1.ibm.com IBM Australia Limited
--
You received this message because you are subscribed to the Google Groups "kasan-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kasan-dev+unsubscribe@googlegroups.com.
To post to this group, send email to kasan-dev@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kasan-dev/f155a38b-c6ab-7825-71e2-15709f9410f6%40au1.ibm.com.
For more options, visit https://groups.google.com/d/optout.
On Fri, Feb 15, 2019 at 1:05 AM Daniel Axtens [off-list ref] wrote:
quoted hunk
In powerpc (as I understand it), we spend a lot of time in boot
running in real mode before MMU paging is initalised. During
this time we call a lot of generic code, including printk(). If
we try to access the shadow region during this time, things fail.
My attempts to move early init before the first printk have not
been successful. (Both previous RFCs for ppc64 - by 2 different
people - have needed this trick too!)
So, allow architectures to define a check_return_arch_not_ready()
hook that bails out of check_memory_region_inline() unless the
arch has done all of the init.
Link: https://lore.kernel.org/patchwork/patch/592820/ # ppc64 hash series
Link: https://patchwork.ozlabs.org/patch/795211/ # ppc radix series
Originally-by: Balbir Singh [off-list ref]
Cc: Aneesh Kumar K.V <redacted>
Signed-off-by: Daniel Axtens <redacted>
---
include/linux/kasan.h | 4 ++++
mm/kasan/generic.c | 2 ++
2 files changed, 6 insertions(+)
@@ -14,6 +14,10 @@ struct task_struct;#include<asm/kasan.h>#include<asm/pgtable.h>+#ifndef check_return_arch_not_ready+#define check_return_arch_not_ready() do { } while (0)+#endif
Please do a bool-returning function. There is no need for
macro-super-powers here and normal C should be the default choice in
such cases.
It will be inlined and an empty impl will dissolve just as the macro.
@@ -170,6 +170,8 @@ static __always_inline void check_memory_region_inline(unsigned long addr,size_tsize,boolwrite,unsignedlongret_ip){+check_return_arch_not_ready();+if(unlikely(size==0))return;--
2.19.1
--
You received this message because you are subscribed to the Google Groups "kasan-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kasan-dev+unsubscribe@googlegroups.com.
To post to this group, send email to kasan-dev@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kasan-dev/20190215000441.14323-4-dja%40axtens.net.
For more options, visit https://groups.google.com/d/optout.
On Fri, Feb 15, 2019 at 1:05 AM Daniel Axtens [off-list ref] wrote:
Wire up KASAN. Only outline instrumentation is supported.
The KASAN shadow area is mapped into vmemmap space:
0x8000 0400 0000 0000 to 0x8000 0600 0000 0000.
To do this we require that vmemmap be disabled. (This is the default
in the kernel config that QorIQ provides for the machine in their
SDK anyway - they use flat memory.)
Only the kernel linear mapping (0xc000...) is checked. The vmalloc and
ioremap areas (also in 0x800...) are all mapped to a zero page. As
with the Book3S hash series, this requires overriding the memory <->
shadow mapping.
Also, as with both previous 64-bit series, early instrumentation is not
supported. It would allow us to drop the check_return_arch_not_ready()
hook in the KASAN core, but it's tricky to get it set up early enough:
we need it setup before the first call to instrumented code like printk().
Perhaps in the future.
Only KASAN_MINIMAL works.
Lightly tested on e6500. KVM, kexec and xmon have not been tested.
Hi Daniel,
This is great!
Not related to the patch, but if you booted a real devices and used it
to some degree, I wonder if you hit any KASAN reports?
Thanks
quoted hunk
The test_kasan module fires warnings as expected, except for the
following tests:
- Expected/by design:
kasan test: memcg_accounted_kmem_cache allocate memcg accounted object
- Due to only supporting KASAN_MINIMAL:
kasan test: kasan_stack_oob out-of-bounds on stack
kasan test: kasan_global_oob out-of-bounds global variable
kasan test: kasan_alloca_oob_left out-of-bounds to left on alloca
kasan test: kasan_alloca_oob_right out-of-bounds to right on alloca
kasan test: use_after_scope_test use-after-scope on int
kasan test: use_after_scope_test use-after-scope on array
Thanks to those who have done the heavy lifting over the past several years:
- Christophe's 32 bit series: https://lists.ozlabs.org/pipermail/linuxppc-dev/2019-February/185379.html
- Aneesh's Book3S hash series: https://lwn.net/Articles/655642/
- Balbir's Book3S radix series: https://patchwork.ozlabs.org/patch/795211/
Cc: Christophe Leroy <redacted>
Cc: Aneesh Kumar K.V <redacted>
Cc: Balbir Singh <bsingharora@gmail.com>
Signed-off-by: Daniel Axtens <redacted>
---
While useful if you have a book3e device, this is mostly intended
as a warm-up exercise for reviving Aneesh's series for book3s hash.
In particular, changes to the kasan core are going to be required
for hash and radix as well.
---
arch/powerpc/Kconfig | 1 +
arch/powerpc/Makefile | 2 +
arch/powerpc/include/asm/kasan.h | 77 ++++++++++++++++++--
arch/powerpc/include/asm/ppc_asm.h | 7 ++
arch/powerpc/include/asm/string.h | 7 +-
arch/powerpc/lib/mem_64.S | 6 +-
arch/powerpc/lib/memcmp_64.S | 5 +-
arch/powerpc/lib/memcpy_64.S | 3 +-
arch/powerpc/lib/string.S | 15 ++--
arch/powerpc/mm/Makefile | 2 +
arch/powerpc/mm/kasan/Makefile | 1 +
arch/powerpc/mm/kasan/kasan_init_book3e_64.c | 53 ++++++++++++++
arch/powerpc/purgatory/Makefile | 3 +
arch/powerpc/xmon/Makefile | 1 +
14 files changed, 164 insertions(+), 19 deletions(-)
create mode 100644 arch/powerpc/mm/kasan/kasan_init_book3e_64.c
@@ -6,6 +6,7 @@ subdir-ccflags-y := $(call cc-disable-warning, builtin-requires-header)GCOV_PROFILE:=nUBSAN_SANITIZE:=n+KASAN_SANITIZE:=n# Disable ftrace for the entire directoryORIG_CFLAGS:=$(KBUILD_CFLAGS)--
2.19.1
--
You received this message because you are subscribed to the Google Groups "kasan-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kasan-dev+unsubscribe@googlegroups.com.
To post to this group, send email to kasan-dev@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kasan-dev/20190215000441.14323-6-dja%40axtens.net.
For more options, visit https://groups.google.com/d/optout.
Building on the work of Christophe, Aneesh and Balbir, I've ported
KASAN to the e6500, a 64-bit Book3E processor which doesn't have a
hashed page table. It applies on top of Christophe's series, v5.
It requires some changes to the KASAN core - please let me know if
these are problematic and we see if an alternative approach is
possible.
The KASAN shadow area is mapped into vmemmap space:
0x8000 0400 0000 0000 to 0x8000 0600 0000 0000.
To do this we require that vmemmap be disabled. (This is the default
in the kernel config that QorIQ provides for the machine in their
SDK anyway - they use flat memory.)
Only outline instrumentation is supported and only KASAN_MINIMAL works.
Only the kernel linear mapping (0xc000...) is checked. The vmalloc and
ioremap areas (also in 0x800...) are all mapped to a zero page. As
with the Book3S hash series, this requires overriding the memory <->
shadow mapping.
Also, as with both previous 64-bit series, early instrumentation is not
supported.
KVM, kexec and xmon have not been tested.
Thanks to those who have done the heavy lifting over the past several years:
- Christophe's 32 bit series: https://lists.ozlabs.org/pipermail/linuxppc-dev/2019-February/185379.html
- Aneesh's Book3S hash series: https://lwn.net/Articles/655642/
- Balbir's Book3S radix series: https://patchwork.ozlabs.org/patch/795211/
While useful if you have an Book3E device, this is mostly intended
as a warm-up exercise for reviving Aneesh's series for book3s hash.
In particular, changes to the kasan core are going to be required
for hash and radix as well.
Regards,
Daniel
Hi Daniel,
I'll look into your series in more details later, for now I just want to
let you know that I get a build failure:
LD vmlinux.o
lib/string.o: In function `memcmp':
/root/linux-powerpc/lib/string.c:857: multiple definition of `memcmp'
arch/powerpc/lib/memcmp_32.o:/root/linux-powerpc/arch/powerpc/lib/memcmp_32.S:16:
first defined here
Christophe
On Fri, Feb 15, 2019 at 11:04:36AM +1100, Daniel Axtens wrote:
Building on the work of Christophe, Aneesh and Balbir, I've ported
KASAN to the e6500, a 64-bit Book3E processor which doesn't have a
hashed page table. It applies on top of Christophe's series, v5.
It requires some changes to the KASAN core - please let me know if
these are problematic and we see if an alternative approach is
possible.
The KASAN shadow area is mapped into vmemmap space:
0x8000 0400 0000 0000 to 0x8000 0600 0000 0000.
To do this we require that vmemmap be disabled. (This is the default
in the kernel config that QorIQ provides for the machine in their
SDK anyway - they use flat memory.)
Only outline instrumentation is supported and only KASAN_MINIMAL works.
Only the kernel linear mapping (0xc000...) is checked. The vmalloc and
ioremap areas (also in 0x800...) are all mapped to a zero page. As
with the Book3S hash series, this requires overriding the memory <->
shadow mapping.
Also, as with both previous 64-bit series, early instrumentation is not
supported.
KVM, kexec and xmon have not been tested.
Thanks to those who have done the heavy lifting over the past several years:
- Christophe's 32 bit series: https://lists.ozlabs.org/pipermail/linuxppc-dev/2019-February/185379.html
- Aneesh's Book3S hash series: https://lwn.net/Articles/655642/
- Balbir's Book3S radix series: https://patchwork.ozlabs.org/patch/795211/
While useful if you have an Book3E device, this is mostly intended
as a warm-up exercise for reviving Aneesh's series for book3s hash.
In particular, changes to the kasan core are going to be required
for hash and radix as well.
Thanks for following through with this, could you please share details on
how you've been testing this?
I know qemu supports qemu -cpu e6500, but beyond that what does the machine
look like?
Balbir Singh.
In powerpc (as I understand it), we spend a lot of time in boot
running in real mode before MMU paging is initalised. During
this time we call a lot of generic code, including printk(). If
we try to access the shadow region during this time, things fail.
My attempts to move early init before the first printk have not
been successful. (Both previous RFCs for ppc64 - by 2 different
people - have needed this trick too!)
So, allow architectures to define a check_return_arch_not_ready()
hook that bails out of check_memory_region_inline() unless the
arch has done all of the init.
Link: https://lore.kernel.org/patchwork/patch/592820/ # ppc64 hash series
Link: https://patchwork.ozlabs.org/patch/795211/ # ppc radix series
Originally-by: Balbir Singh [off-list ref]
Cc: Aneesh Kumar K.V <redacted>
Signed-off-by: Daniel Axtens <redacted>
---
include/linux/kasan.h | 4 ++++
mm/kasan/generic.c | 2 ++
2 files changed, 6 insertions(+)
@@ -170,6 +170,8 @@ static __always_inline void check_memory_region_inline(unsigned long addr,size_tsize,boolwrite,unsignedlongret_ip){+check_return_arch_not_ready();+
Not good for readibility that the above macro embeds a return, something
like below would be better I think:
if (!kasan_arch_is_ready())
return;
Unless somebody minds, I'll do the change and take this patch in my
series in order to handle the case of book3s/32 hash.
Christophe
if (unlikely(size == 0))
return;
---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast.
https://www.avast.com/antivirus
Wire up KASAN. Only outline instrumentation is supported.
The KASAN shadow area is mapped into vmemmap space:
0x8000 0400 0000 0000 to 0x8000 0600 0000 0000.
To do this we require that vmemmap be disabled. (This is the default
in the kernel config that QorIQ provides for the machine in their
SDK anyway - they use flat memory.)
Only the kernel linear mapping (0xc000...) is checked. The vmalloc and
ioremap areas (also in 0x800...) are all mapped to a zero page. As
with the Book3S hash series, this requires overriding the memory <->
shadow mapping.
Also, as with both previous 64-bit series, early instrumentation is not
supported. It would allow us to drop the check_return_arch_not_ready()
hook in the KASAN core, but it's tricky to get it set up early enough:
we need it setup before the first call to instrumented code like printk().
Perhaps in the future.
Only KASAN_MINIMAL works.
Lightly tested on e6500. KVM, kexec and xmon have not been tested.
The test_kasan module fires warnings as expected, except for the
following tests:
- Expected/by design:
kasan test: memcg_accounted_kmem_cache allocate memcg accounted object
- Due to only supporting KASAN_MINIMAL:
kasan test: kasan_stack_oob out-of-bounds on stack
kasan test: kasan_global_oob out-of-bounds global variable
kasan test: kasan_alloca_oob_left out-of-bounds to left on alloca
kasan test: kasan_alloca_oob_right out-of-bounds to right on alloca
kasan test: use_after_scope_test use-after-scope on int
kasan test: use_after_scope_test use-after-scope on array
Thanks to those who have done the heavy lifting over the past several years:
- Christophe's 32 bit series: https://lists.ozlabs.org/pipermail/linuxppc-dev/2019-February/185379.html
You're welcome.
- Aneesh's Book3S hash series: https://lwn.net/Articles/655642/
- Balbir's Book3S radix series: https://patchwork.ozlabs.org/patch/795211/
Cc: Christophe Leroy <redacted>
Cc: Aneesh Kumar K.V <redacted>
Cc: Balbir Singh <bsingharora@gmail.com>
Signed-off-by: Daniel Axtens <redacted>
---
While useful if you have a book3e device, this is mostly intended
as a warm-up exercise for reviving Aneesh's series for book3s hash.
In particular, changes to the kasan core are going to be required
for hash and radix as well.
And part of it will be needed for hash32 as well, until we implement an
early static hash stable.
Good catch, we can't use the optimised version when CONFIG_KASAN is set
until kasan implements verifications with check_memory_region() as it
does for memmove(), memcpy() and memset().
I'll take that in my series.
That's pointless. Nobody is going to call __memcmp(), so we should just
not compile it in when CONFIG_KASAN is defined. Same for memchr(),
strncpy() and strncmp().
I'll do it in my series.
diff --git a/arch/powerpc/mm/kasan_init.c b/arch/powerpc/mm/kasan/kasan_init_32.csimilarity index 100%rename from arch/powerpc/mm/kasan_init.crename to arch/powerpc/mm/kasan/kasan_init_32.c
---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast.
https://www.avast.com/antivirus
From: Daniel Axtens <hidden> Date: 2019-02-18 06:15:20
christophe leroy [off-list ref] writes:
Le 15/02/2019 à 01:04, Daniel Axtens a écrit :
quoted
In powerpc (as I understand it), we spend a lot of time in boot
running in real mode before MMU paging is initalised. During
this time we call a lot of generic code, including printk(). If
we try to access the shadow region during this time, things fail.
My attempts to move early init before the first printk have not
been successful. (Both previous RFCs for ppc64 - by 2 different
people - have needed this trick too!)
So, allow architectures to define a check_return_arch_not_ready()
hook that bails out of check_memory_region_inline() unless the
arch has done all of the init.
Link: https://lore.kernel.org/patchwork/patch/592820/ # ppc64 hash series
Link: https://patchwork.ozlabs.org/patch/795211/ # ppc radix series
Originally-by: Balbir Singh [off-list ref]
Cc: Aneesh Kumar K.V <redacted>
Signed-off-by: Daniel Axtens <redacted>
---
include/linux/kasan.h | 4 ++++
mm/kasan/generic.c | 2 ++
2 files changed, 6 insertions(+)
@@ -170,6 +170,8 @@ static __always_inline void check_memory_region_inline(unsigned long addr,size_tsize,boolwrite,unsignedlongret_ip){+check_return_arch_not_ready();+
Not good for readibility that the above macro embeds a return, something
like below would be better I think:
if (!kasan_arch_is_ready())
return;
Unless somebody minds, I'll do the change and take this patch in my
series in order to handle the case of book3s/32 hash.
Please do; feel free to take as many of the patches as you would like
and I'll rebase whatever is left on the next version of your series.
The idea with the macro magic was to take advantage of the speed of
static keys (I think, I borrowed it from Balbir's patch). Perhaps an
inline function will achieve this anyway, but given that KASAN with
outline instrumentation is inevitably slow, I guess it doesn't matter
much either way.
Regards,
Daniel
Christophe
quoted
if (unlikely(size == 0))
return;
---
L'absence de virus dans ce courrier électronique a été vérifiée par le logiciel antivirus Avast.
https://www.avast.com/antivirus
Wire up KASAN. Only outline instrumentation is supported.
The KASAN shadow area is mapped into vmemmap space:
0x8000 0400 0000 0000 to 0x8000 0600 0000 0000.
To do this we require that vmemmap be disabled. (This is the default
in the kernel config that QorIQ provides for the machine in their
SDK anyway - they use flat memory.)
Only the kernel linear mapping (0xc000...) is checked. The vmalloc and
ioremap areas (also in 0x800...) are all mapped to a zero page. As
with the Book3S hash series, this requires overriding the memory <->
shadow mapping.
Also, as with both previous 64-bit series, early instrumentation is not
supported. It would allow us to drop the check_return_arch_not_ready()
hook in the KASAN core, but it's tricky to get it set up early enough:
we need it setup before the first call to instrumented code like printk().
Perhaps in the future.
Only KASAN_MINIMAL works.
Lightly tested on e6500. KVM, kexec and xmon have not been tested.
The test_kasan module fires warnings as expected, except for the
following tests:
- Expected/by design:
kasan test: memcg_accounted_kmem_cache allocate memcg accounted object
- Due to only supporting KASAN_MINIMAL:
kasan test: kasan_stack_oob out-of-bounds on stack
kasan test: kasan_global_oob out-of-bounds global variable
kasan test: kasan_alloca_oob_left out-of-bounds to left on alloca
kasan test: kasan_alloca_oob_right out-of-bounds to right on alloca
kasan test: use_after_scope_test use-after-scope on int
kasan test: use_after_scope_test use-after-scope on array
Thanks to those who have done the heavy lifting over the past several years:
- Christophe's 32 bit series: https://lists.ozlabs.org/pipermail/linuxppc-dev/2019-February/185379.html
- Aneesh's Book3S hash series: https://lwn.net/Articles/655642/
- Balbir's Book3S radix series: https://patchwork.ozlabs.org/patch/795211/
Cc: Christophe Leroy <redacted>
Cc: Aneesh Kumar K.V <redacted>
Cc: Balbir Singh <bsingharora@gmail.com>
Signed-off-by: Daniel Axtens <redacted>
---
While useful if you have a book3e device, this is mostly intended
as a warm-up exercise for reviving Aneesh's series for book3s hash.
In particular, changes to the kasan core are going to be required
for hash and radix as well.
---
arch/powerpc/Kconfig | 1 +
arch/powerpc/Makefile | 2 +
arch/powerpc/include/asm/kasan.h | 77 ++++++++++++++++++--
arch/powerpc/include/asm/ppc_asm.h | 7 ++
arch/powerpc/include/asm/string.h | 7 +-
arch/powerpc/lib/mem_64.S | 6 +-
arch/powerpc/lib/memcmp_64.S | 5 +-
arch/powerpc/lib/memcpy_64.S | 3 +-
arch/powerpc/lib/string.S | 15 ++--
arch/powerpc/mm/Makefile | 2 +
arch/powerpc/mm/kasan/Makefile | 1 +
arch/powerpc/mm/kasan/kasan_init_book3e_64.c | 53 ++++++++++++++
arch/powerpc/purgatory/Makefile | 3 +
arch/powerpc/xmon/Makefile | 1 +
14 files changed, 164 insertions(+), 19 deletions(-)
create mode 100644 arch/powerpc/mm/kasan/kasan_init_book3e_64.c
I suppose it probably doesn't! I copied Balbir's code without much
thought as it seemed a lot smarter than my random global variable code.
Regards,
Daniel
From: Daniel Axtens <hidden> Date: 2019-02-19 06:38:13
Hi Balbir,
Thanks for following through with this, could you please share details on
how you've been testing this?
I know qemu supports qemu -cpu e6500, but beyond that what does the machine
look like?
I've been using a T4240RDB, so real hardware. It boots both the QorIQ
Yocto-based distro and Debian ppc64. I have run parts of kselftest and
am currently running LTP - so far no errors have triggered.
Regards,
Daniel
From: Daniel Axtens <hidden> Date: 2019-02-19 06:40:02
Dmitry Vyukov [off-list ref] writes:
On Fri, Feb 15, 2019 at 1:05 AM Daniel Axtens [off-list ref] wrote:
quoted
Wire up KASAN. Only outline instrumentation is supported.
The KASAN shadow area is mapped into vmemmap space:
0x8000 0400 0000 0000 to 0x8000 0600 0000 0000.
To do this we require that vmemmap be disabled. (This is the default
in the kernel config that QorIQ provides for the machine in their
SDK anyway - they use flat memory.)
Only the kernel linear mapping (0xc000...) is checked. The vmalloc and
ioremap areas (also in 0x800...) are all mapped to a zero page. As
with the Book3S hash series, this requires overriding the memory <->
shadow mapping.
Also, as with both previous 64-bit series, early instrumentation is not
supported. It would allow us to drop the check_return_arch_not_ready()
hook in the KASAN core, but it's tricky to get it set up early enough:
we need it setup before the first call to instrumented code like printk().
Perhaps in the future.
Only KASAN_MINIMAL works.
Lightly tested on e6500. KVM, kexec and xmon have not been tested.
Hi Daniel,
This is great!
Not related to the patch, but if you booted a real devices and used it
to some degree, I wonder if you hit any KASAN reports?
Not yet, but the hope is that I will be able to extend this to book3s
and then it will be more useful in combination with syzkaller.
Regards,
Daniel
Thanks
quoted
The test_kasan module fires warnings as expected, except for the
following tests:
- Expected/by design:
kasan test: memcg_accounted_kmem_cache allocate memcg accounted object
- Due to only supporting KASAN_MINIMAL:
kasan test: kasan_stack_oob out-of-bounds on stack
kasan test: kasan_global_oob out-of-bounds global variable
kasan test: kasan_alloca_oob_left out-of-bounds to left on alloca
kasan test: kasan_alloca_oob_right out-of-bounds to right on alloca
kasan test: use_after_scope_test use-after-scope on int
kasan test: use_after_scope_test use-after-scope on array
Thanks to those who have done the heavy lifting over the past several years:
- Christophe's 32 bit series: https://lists.ozlabs.org/pipermail/linuxppc-dev/2019-February/185379.html
- Aneesh's Book3S hash series: https://lwn.net/Articles/655642/
- Balbir's Book3S radix series: https://patchwork.ozlabs.org/patch/795211/
Cc: Christophe Leroy <redacted>
Cc: Aneesh Kumar K.V <redacted>
Cc: Balbir Singh <bsingharora@gmail.com>
Signed-off-by: Daniel Axtens <redacted>
---
While useful if you have a book3e device, this is mostly intended
as a warm-up exercise for reviving Aneesh's series for book3s hash.
In particular, changes to the kasan core are going to be required
for hash and radix as well.
---
arch/powerpc/Kconfig | 1 +
arch/powerpc/Makefile | 2 +
arch/powerpc/include/asm/kasan.h | 77 ++++++++++++++++++--
arch/powerpc/include/asm/ppc_asm.h | 7 ++
arch/powerpc/include/asm/string.h | 7 +-
arch/powerpc/lib/mem_64.S | 6 +-
arch/powerpc/lib/memcmp_64.S | 5 +-
arch/powerpc/lib/memcpy_64.S | 3 +-
arch/powerpc/lib/string.S | 15 ++--
arch/powerpc/mm/Makefile | 2 +
arch/powerpc/mm/kasan/Makefile | 1 +
arch/powerpc/mm/kasan/kasan_init_book3e_64.c | 53 ++++++++++++++
arch/powerpc/purgatory/Makefile | 3 +
arch/powerpc/xmon/Makefile | 1 +
14 files changed, 164 insertions(+), 19 deletions(-)
create mode 100644 arch/powerpc/mm/kasan/kasan_init_book3e_64.c
@@ -6,6 +6,7 @@ subdir-ccflags-y := $(call cc-disable-warning, builtin-requires-header)GCOV_PROFILE:=nUBSAN_SANITIZE:=n+KASAN_SANITIZE:=n# Disable ftrace for the entire directoryORIG_CFLAGS:=$(KBUILD_CFLAGS)--
2.19.1
--
You received this message because you are subscribed to the Google Groups "kasan-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kasan-dev+unsubscribe@googlegroups.com.
To post to this group, send email to kasan-dev@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kasan-dev/20190215000441.14323-6-dja%40axtens.net.
For more options, visit https://groups.google.com/d/optout.
Hi Daniel,
Le 18/02/2019 à 07:13, Daniel Axtens a écrit :
christophe leroy [off-list ref] writes:
quoted
Le 15/02/2019 à 01:04, Daniel Axtens a écrit :
quoted
In powerpc (as I understand it), we spend a lot of time in boot
running in real mode before MMU paging is initalised. During
this time we call a lot of generic code, including printk(). If
we try to access the shadow region during this time, things fail.
My attempts to move early init before the first printk have not
been successful. (Both previous RFCs for ppc64 - by 2 different
people - have needed this trick too!)
So, allow architectures to define a check_return_arch_not_ready()
hook that bails out of check_memory_region_inline() unless the
arch has done all of the init.
Link: https://lore.kernel.org/patchwork/patch/592820/ # ppc64 hash series
Link: https://patchwork.ozlabs.org/patch/795211/ # ppc radix series
Originally-by: Balbir Singh [off-list ref]
Cc: Aneesh Kumar K.V <redacted>
Signed-off-by: Daniel Axtens <redacted>
---
include/linux/kasan.h | 4 ++++
mm/kasan/generic.c | 2 ++
2 files changed, 6 insertions(+)
@@ -170,6 +170,8 @@ static __always_inline void check_memory_region_inline(unsigned long addr,size_tsize,boolwrite,unsignedlongret_ip){+check_return_arch_not_ready();+
Not good for readibility that the above macro embeds a return, something
like below would be better I think:
if (!kasan_arch_is_ready())
return;
Unless somebody minds, I'll do the change and take this patch in my
series in order to handle the case of book3s/32 hash.
Please do; feel free to take as many of the patches as you would like
and I'll rebase whatever is left on the next version of your series.
I have now done a big step with v7: works on both nohash and hash ppc32
without any special feature in the core of kasan. Have to do more tests
on the hash version, but it seems promissing.
I have kept your patches on sync on top of it (allthough totally
untested), you can find them in
https://github.com/chleroy/linux/commits/kasan
The idea with the macro magic was to take advantage of the speed of
static keys (I think, I borrowed it from Balbir's patch). Perhaps an
inline function will achieve this anyway, but given that KASAN with
outline instrumentation is inevitably slow, I guess it doesn't matter
much either way.
You'll see in the modifications I've done to your patches, we can still
use static keys while using static inline functions.
Christophe
From: Daniel Axtens <hidden> Date: 2019-02-26 00:15:51
quoted
quoted
Unless somebody minds, I'll do the change and take this patch in my
series in order to handle the case of book3s/32 hash.
Please do; feel free to take as many of the patches as you would like
and I'll rebase whatever is left on the next version of your series.
I have now done a big step with v7: works on both nohash and hash ppc32
without any special feature in the core of kasan. Have to do more tests
on the hash version, but it seems promissing.
I have kept your patches on sync on top of it (allthough totally
untested), you can find them in
https://github.com/chleroy/linux/commits/kasan
Thanks - I've got sidetracked with other internal stuff but I hope to
get back to this later in the week.
Regards,
Daniel
quoted
The idea with the macro magic was to take advantage of the speed of
static keys (I think, I borrowed it from Balbir's patch). Perhaps an
inline function will achieve this anyway, but given that KASAN with
outline instrumentation is inevitably slow, I guess it doesn't matter
much either way.
You'll see in the modifications I've done to your patches, we can still
use static keys while using static inline functions.
Christophe