kasan: Always respect CONFIG_KASAN_STACK
Subsystems (4)
Nathan Chancellor
maintainerPATCH 1/1 kasan: Always respect CONFIG_KASAN_STACK
Currently, the asan-stack parameter is only passed along if CFLAGS_KASAN_SHADOW is not empty, which requires KASAN_SHADOW_OFFSET to be defined in Kconfig so that the value can be checked. In RISC-V's case, KASAN_SHADOW_OFFSET is not defined in Kconfig, which means that asan-stack does not get disabled with clang even when CONFIG_KASAN_STACK is disabled, resulting in large stack warnings with allmodconfig:
drivers/video/fbdev/omap2/omapfb/displays/panel-lgphilips-lb035q02.c:117:12:
error: stack frame size (14400) exceeds limit (2048) in function 'lb035q02_connect' [-Werror,-Wframe-larger-than]
static int lb035q02_connect(struct omap_dss_device *dssdev)
^
1 error generated.
Ensure that the value of CONFIG_KASAN_STACK is always passed along to the compiler so that these warnings do not happen when CONFIG_KASAN_STACK is disabled.
References: 6baec880d7a5 ("kasan: turn off asan-stack for clang-8 and earlier")
--- scripts/Makefile.kasan | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
scripts/Makefile.kasan +2 -1
@@ -33,10 +33,11 @@ else CFLAGS_KASAN := $(CFLAGS_KASAN_SHADOW) \ $(call cc-param,asan-globals=1) \ $(call cc-param,asan-instrumentation-with-call-threshold=$(call_threshold)) \ - $(call cc-param,asan-stack=$(stack_enable)) \ $(call cc-param,asan-instrument-allocas=1) endif +CFLAGS_KASAN += $(call cc-param,asan-stack=$(stack_enable)) + endif # CONFIG_KASAN_GENERIC ifdef CONFIG_KASAN_SW_TAGS
base-commit: 4057525736b159bd456732d11270af2cc49ec21f
Signature · 1 line
2.33.0.514.g99c99ed825
Quoted 14 lines · Nathan Chancellor
Currently, the asan-stack parameter is only passed along if
CFLAGS_KASAN_SHADOWis not empty, which requiresKASAN_SHADOW_OFFSETto be defined inKconfigso that the value can be checked. In RISC-V's case,KASAN_SHADOW_OFFSETis not defined inKconfig, which means that asan-stack does not get disabled with clang even whenCONFIG_KASAN_STACKis disabled, resulting in large stack warnings with allmodconfig:
drivers/video/fbdev/omap2/omapfb/displays/panel-lgphilips-lb035q02.c:117:12:
error: stack frame size (14400) exceeds limit (2048) in function 'lb035q02_connect' [-Werror,-Wframe-larger-than]
static intlb035q02_connect(struct omap_dss_device *dssdev)^1 error generated.
Quoted 7 lines
Ensure that the value of
CONFIG_KASAN_STACKis always passed along to the compiler so that these warnings do not happen whenCONFIG_KASAN_STACKis disabled.References:
6baec880d7a5("kasan: turn off asan-stack for clang-8 and earlier")Signed-off-by Nathan Chancellor <[email protected]>
[ Which tree are you planning to take it through? ]
Note, arch/riscv/include/asm/kasan.h mentions KASAN_SHADOW_OFFSET in comment (copied from arm64). Did RISC-V just forget to copy over the Kconfig option?
Quoted 27 lines
--- scripts/Makefile.kasan | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)scripts/Makefile.kasan +2
-1@@ -33,10 +33,11 @@ else CFLAGS_KASAN := $(CFLAGS_KASAN_SHADOW) \ $(call cc-param,asan-globals=1) \ $(call cc-param,asan-instrumentation-with-call-threshold=$(call_threshold)) \ - $(call cc-param,asan-stack=$(stack_enable)) \ $(call cc-param,asan-instrument-allocas=1) endif +CFLAGS_KASAN += $(call cc-param,asan-stack=$(stack_enable)) + endif # CONFIG_KASAN_GENERIC ifdef CONFIG_KASAN_SW_TAGSbase-commit:
4057525736b159bd456732d11270af2cc49ec21f--
2.33.0.514.g99c99ed825
Nathan Chancellor
maintainerQuoted 19 lines · Marco Elver
Quoted 18 lines · Nathan Chancellor
Currently, the asan-stack parameter is only passed along if
CFLAGS_KASAN_SHADOWis not empty, which requiresKASAN_SHADOW_OFFSETto be defined inKconfigso that the value can be checked. In RISC-V's case,KASAN_SHADOW_OFFSETis not defined inKconfig, which means that asan-stack does not get disabled with clang even whenCONFIG_KASAN_STACKis disabled, resulting in large stack warnings with allmodconfig:
drivers/video/fbdev/omap2/omapfb/displays/panel-lgphilips-lb035q02.c:117:12:
error: stack frame size (14400) exceeds limit (2048) in function 'lb035q02_connect' [-Werror,-Wframe-larger-than]
static intlb035q02_connect(struct omap_dss_device *dssdev)^1 error generated.
Ensure that the value of
CONFIG_KASAN_STACKis always passed along to the compiler so that these warnings do not happen whenCONFIG_KASAN_STACKis disabled.
Quoted 5 lines
Quoted 3 lines
References:
6baec880d7a5("kasan: turn off asan-stack for clang-8 and earlier")Signed-off-by Nathan Chancellor <[email protected]>Reviewed-by Marco Elver <[email protected]>
Thanks!
Quoted 1 line
[ Which tree are you planning to take it through? ]
Gah, I was intending for it to go through -mm, then I cc'd neither Andrew nor linux-mm... :/ Andrew, do you want me to resend or can you grab it from LKML?
Quoted 3 lines
Note,
arch/riscv/include/asm/kasan.hmentionsKASAN_SHADOW_OFFSETin comment (copied from arm64). Did RISC-V just forget to copy over theKconfigoption?
I do see it defined in that file as well but you are right that they did not copy the Kconfig logic, even though it was present in the tree when RISC-V KASAN was implemented. Perhaps they should so that they get access to the other flags in the "else" branch?
Quoted 27 lines
Quoted 27 lines
--- scripts/Makefile.kasan | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)scripts/Makefile.kasan +2
-1@@ -33,10 +33,11 @@ else CFLAGS_KASAN := $(CFLAGS_KASAN_SHADOW) \ $(call cc-param,asan-globals=1) \ $(call cc-param,asan-instrumentation-with-call-threshold=$(call_threshold)) \ - $(call cc-param,asan-stack=$(stack_enable)) \ $(call cc-param,asan-instrument-allocas=1) endif +CFLAGS_KASAN += $(call cc-param,asan-stack=$(stack_enable)) + endif # CONFIG_KASAN_GENERIC ifdef CONFIG_KASAN_SW_TAGSbase-commit:
4057525736b159bd456732d11270af2cc49ec21f--
2.33.0.514.g99c99ed825
Quoted 26 lines · On Thu, 23 Sep 2021 07:59:46 PDT (-0700), [email protected] wrote:
Quoted 19 lines · Marco Elver
Quoted 18 lines · Nathan Chancellor
Currently, the asan-stack parameter is only passed along if
CFLAGS_KASAN_SHADOWis not empty, which requiresKASAN_SHADOW_OFFSETto be defined inKconfigso that the value can be checked. In RISC-V's case,KASAN_SHADOW_OFFSETis not defined inKconfig, which means that asan-stack does not get disabled with clang even whenCONFIG_KASAN_STACKis disabled, resulting in large stack warnings with allmodconfig:
drivers/video/fbdev/omap2/omapfb/displays/panel-lgphilips-lb035q02.c:117:12:
error: stack frame size (14400) exceeds limit (2048) in function 'lb035q02_connect' [-Werror,-Wframe-larger-than]
static intlb035q02_connect(struct omap_dss_device *dssdev)^1 error generated.
Ensure that the value of
CONFIG_KASAN_STACKis always passed along to the compiler so that these warnings do not happen whenCONFIG_KASAN_STACKis disabled.Quoted 5 lines
Quoted 3 lines
References:
6baec880d7a5("kasan: turn off asan-stack for clang-8 and earlier")Signed-off-by Nathan Chancellor <[email protected]>Reviewed-by Marco Elver <[email protected]>
Quoted 7 lines
Thanks!
Quoted 1 line
[ Which tree are you planning to take it through? ]
Gah, I was intending for it to go through -mm, then I cc'd neither Andrew nor linux-mm... :/ Andrew, do you want me to resend or can you grab it from LKML?
(assuming you still want it through somewhere else)
Quoted 8 lines
Quoted 3 lines
Note,
arch/riscv/include/asm/kasan.hmentionsKASAN_SHADOW_OFFSETin comment (copied from arm64). Did RISC-V just forget to copy over theKconfigoption?I do see it defined in that file as well but you are right that they did not copy the
Kconfiglogic, even though it was present in the tree when RISC-V KASAN was implemented. Perhaps they should so that they get access to the other flags in the "else" branch?
Ya, looks like we just screwed this up. I'm seeing some warnings like
cc1: warning: ‘-fsanitize=kernel-address’ with stack protection is not supported without ‘-fasan-shadow-offset=’ for this target
which is how I ended up here, I'm assuming that's what you're talking about here? LMK if you were planning on sending along a fix or if you want me to go figure it out.
Quoted 28 lines
Quoted 28 lines
Quoted 28 lines
--- scripts/Makefile.kasan | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)scripts/Makefile.kasan +2
-1@@ -33,10 +33,11 @@ else CFLAGS_KASAN := $(CFLAGS_KASAN_SHADOW) \ $(call cc-param,asan-globals=1) \ $(call cc-param,asan-instrumentation-with-call-threshold=$(call_threshold)) \ - $(call cc-param,asan-stack=$(stack_enable)) \ $(call cc-param,asan-instrument-allocas=1) endif +CFLAGS_KASAN += $(call cc-param,asan-stack=$(stack_enable)) + endif # CONFIG_KASAN_GENERIC ifdef CONFIG_KASAN_SW_TAGSbase-commit:
4057525736b159bd456732d11270af2cc49ec21f--
2.33.0.514.g99c99ed825
Nathan Chancellor
maintainerQuoted 31 lines · Palmer Dabbelt
Quoted 30 lines · On Thu, 23 Sep 2021 07:59:46 PDT (-0700), [email protected] wrote:
Quoted 19 lines · Marco Elver
Quoted 18 lines · Nathan Chancellor
Currently, the asan-stack parameter is only passed along if
CFLAGS_KASAN_SHADOWis not empty, which requiresKASAN_SHADOW_OFFSETto be defined inKconfigso that the value can be checked. In RISC-V's case,KASAN_SHADOW_OFFSETis not defined inKconfig, which means that asan-stack does not get disabled with clang even whenCONFIG_KASAN_STACKis disabled, resulting in large stack warnings with allmodconfig:
drivers/video/fbdev/omap2/omapfb/displays/panel-lgphilips-lb035q02.c:117:12:
error: stack frame size (14400) exceeds limit (2048) in function 'lb035q02_connect' [-Werror,-Wframe-larger-than]
static intlb035q02_connect(struct omap_dss_device *dssdev)^1 error generated.
Ensure that the value of
CONFIG_KASAN_STACKis always passed along to the compiler so that these warnings do not happen whenCONFIG_KASAN_STACKis disabled.Quoted 5 lines
Quoted 3 lines
References:
6baec880d7a5("kasan: turn off asan-stack for clang-8 and earlier")Signed-off-by Nathan Chancellor <[email protected]>Reviewed-by Marco Elver <[email protected]>Thanks!
Quoted 1 line
[ Which tree are you planning to take it through? ]
Quoted 7 lines
Quoted 3 lines
Gah, I was intending for it to go through -mm, then I cc'd neither Andrew nor linux-mm... :/ Andrew, do you want me to resend or can you grab it from LKML?
Acked-by Palmer Dabbelt <[email protected]>(assuming you still want it through somewhere else)
Thanks, it is now in mainline as commit 19532869feb9 ("kasan: always respect CONFIG_KASAN_STACK").
Quoted 4 lines
Quoted 4 lines
Quoted 3 lines
Note,
arch/riscv/include/asm/kasan.hmentionsKASAN_SHADOW_OFFSETin comment (copied from arm64). Did RISC-V just forget to copy over theKconfigoption?
Quoted 8 lines
Quoted 4 lines
I do see it defined in that file as well but you are right that they did not copy the
Kconfiglogic, even though it was present in the tree when RISC-V KASAN was implemented. Perhaps they should so that they get access to the other flags in the "else" branch?Ya, looks like we just screwed this up. I'm seeing some warnings like
cc1: warning: ‘-fsanitize=kernel-address’ with stack protection is not supported without ‘-fasan-shadow-offset=’ for this target
Hmmm, I thought I did a GCC build with this change but I must not have :/
Quoted 3 lines
which is how I ended up here, I'm assuming that's what you're talking about here? LMK if you were planning on sending along a fix or if you want me to go figure it out.
I took a look at moving the logic into Kconfig like arm64 before sending this change and I did not really understand it well enough to do so. I think it would be best if you were able to do that so that nothing gets messed up.
Cheers,
Nathan
Alex Ghiti
reviewerHi Nathan,
Le 14/10/2021 à 18:55, Nathan Chancellor a écrit :
Quoted 59 lines · Palmer Dabbelt
Quoted 31 lines · On Thu, 23 Sep 2021 07:59:46 PDT (-0700), [email protected] wrote:
Quoted 30 lines · Marco Elver
Quoted 19 lines · Nathan Chancellor
Quoted 18 lines
Currently, the asan-stack parameter is only passed along if
CFLAGS_KASAN_SHADOWis not empty, which requiresKASAN_SHADOW_OFFSETto be defined inKconfigso that the value can be checked. In RISC-V's case,KASAN_SHADOW_OFFSETis not defined inKconfig, which means that asan-stack does not get disabled with clang even whenCONFIG_KASAN_STACKis disabled, resulting in large stack warnings with allmodconfig:
drivers/video/fbdev/omap2/omapfb/displays/panel-lgphilips-lb035q02.c:117:12:
error: stack frame size (14400) exceeds limit (2048) in function 'lb035q02_connect' [-Werror,-Wframe-larger-than]
static intlb035q02_connect(struct omap_dss_device *dssdev)^1 error generated.
Ensure that the value of
CONFIG_KASAN_STACKis always passed along to the compiler so that these warnings do not happen whenCONFIG_KASAN_STACKis disabled.Quoted 5 lines
Quoted 3 lines
References:
6baec880d7a5("kasan: turn off asan-stack for clang-8 and earlier")Signed-off-by Nathan Chancellor <[email protected]>Reviewed-by Marco Elver <[email protected]>Thanks!
Quoted 1 line
[ Which tree are you planning to take it through? ]
Quoted 7 lines
Quoted 3 lines
Gah, I was intending for it to go through -mm, then I cc'd neither Andrew nor linux-mm... :/ Andrew, do you want me to resend or can you grab it from LKML?
Acked-by Palmer Dabbelt <[email protected]>(assuming you still want it through somewhere else)
Thanks, it is now in mainline as commit
19532869feb9("kasan: always respectCONFIG_KASAN_STACK").Quoted 4 lines
Quoted 4 lines
Quoted 3 lines
Note,
arch/riscv/include/asm/kasan.hmentionsKASAN_SHADOW_OFFSETin comment (copied from arm64). Did RISC-V just forget to copy over theKconfigoption?Quoted 8 lines
Quoted 4 lines
I do see it defined in that file as well but you are right that they did not copy the
Kconfiglogic, even though it was present in the tree when RISC-V KASAN was implemented. Perhaps they should so that they get access to the other flags in the "else" branch?Ya, looks like we just screwed this up. I'm seeing some warnings like
cc1: warning: ‘-fsanitize=kernel-address’ with stack protection is not supported without ‘-fasan-shadow-offset=’ for this target
Hmmm, I thought I did a GCC build with this change but I must not have :/
Quoted 9 lines
Quoted 3 lines
which is how I ended up here, I'm assuming that's what you're talking about here? LMK if you were planning on sending along a fix or if you want me to go figure it out.
I took a look at moving the logic into
Kconfiglike arm64 before sending this change and I did not really understand it well enough to do so. I think it would be best if you were able to do that so that nothing gets messed up.
I'll do it tomorrow, I'm the last one who touched kasan on riscv :)
Thanks,
Alex
Quoted 8 lines
Cheers,
Nathan_______________________________________________
linux-riscv mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-riscv
Alexandre ghiti
reviewerQuoted 78 lines · Alex Ghiti
Hi Nathan,
Le 14/10/2021 à 18:55, Nathan Chancellor a écrit :
Quoted 75 lines · Palmer Dabbelt
Quoted 38 lines · On Thu, 23 Sep 2021 07:59:46 PDT (-0700), [email protected] wrote:
Quoted 37 lines · Marco Elver
Quoted 25 lines
Quoted 23 lines · Nathan Chancellor
Currently, the asan-stack parameter is only passed along if
CFLAGS_KASAN_SHADOWis not empty, which requiresKASAN_SHADOW_OFFSETto
be defined inKconfigso that the value can be checked. In RISC-V's case,KASAN_SHADOW_OFFSETis not defined inKconfig, which means that
asan-stack does not get disabled with clang even whenCONFIG_KASAN_STACK
is disabled, resulting in large stack warnings with allmodconfig:
drivers/video/fbdev/omap2/omapfb/displays/panel-lgphilips-lb035q02.c:117:12:error: stack frame size (14400) exceeds limit (2048) in function '
lb035q02_connect' [-Werror,-Wframe-larger-than] static intlb035q02_connect(struct omap_dss_device *dssdev)^
1 error generated.Ensure that the value of
CONFIG_KASAN_STACKis always passed along to
the compiler so that these warnings do not happen whenCONFIG_KASAN_STACKis disabled.Quoted 6 lines
Quoted 4 lines
References:
6baec880d7a5("kasan: turn off asan-stack for clang-8 and earlier")Signed-off-by Nathan Chancellor <[email protected]>Reviewed-by Marco Elver <[email protected]>Thanks!
Quoted 1 line
[ Which tree are you planning to take it through? ]
Quoted 7 lines
Quoted 3 lines
Gah, I was intending for it to go through -mm, then I cc'd neither Andrew nor linux-mm... :/ Andrew, do you want me to resend or can you grab it from LKML?
Acked-by Palmer Dabbelt <[email protected]>(assuming you still want it through somewhere else)
Thanks, it is now in mainline as commit
19532869feb9("kasan: always respectCONFIG_KASAN_STACK").Quoted 11 lines
Quoted 10 lines
Quoted 3 lines
Note,
arch/riscv/include/asm/kasan.hmentionsKASAN_SHADOW_OFFSETin comment (copied from arm64). Did RISC-V just forget to copy over theKconfigoption?I do see it defined in that file as well but you are right that they did
not copy theKconfiglogic, even though it was present in the tree when
RISC-V KASAN was implemented. Perhaps they should so that they get access to the other flags in the "else" branch?Quoted 4 lines
Ya, looks like we just screwed this up. I'm seeing some warnings like
cc1: warning: ‘-fsanitize=kernel-address’ with stack protection is not supported without ‘-fasan-shadow-offset=’ for this target
Hmmm, I thought I did a GCC build with this change but I must not have :/
Quoted 5 lines
which is how I ended up here, I'm assuming that's what you're talking about
here? LMK if you were planning on sending along a fix or if you want me to
go figure it out.
Quoted 8 lines
Quoted 5 lines
I took a look at moving the logic into
Kconfiglike arm64 before sending this change and I did not really understand it well enough to do so. I think it would be best if you were able to do that so that nothing gets messed up.I'll do it tomorrow, I'm the last one who touched kasan on riscv :)
Adding KASAN_SHADOW_OFFSET config makes kasan kernel fails to boot. It receives a *write* fault at the beginning of a memblock_alloc function while populating the kernel shadow memory: the trap address is in the kasan shadow virtual address range and this corresponds to a kernel address in init_stack. The question is: how do I populate the stack shadow mapping without using memblock API? It's weird, I don't find anything on other architectures.
And just a short note: I have realized this will break with the sv48 patchset as we decide at runtime the address space width and the kasan shadow start address is different between sv39 and sv48. I will have to do like x86 and move the kasan shadow start at the end of the address space so that it is the same for both sv39 and sv48.
Thanks,
Alex
Quoted 17 lines
Thanks,
Alex
Quoted 8 lines
Cheers,
Nathan_______________________________________________
linux-riscv mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-riscv_______________________________________________
linux-riscv mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-riscv
Hi,
Quoted 89 lines · Alexandre ghiti
Quoted 78 lines · Alex Ghiti
Hi Nathan,
Quoted 75 lines · Nathan Chancellor
Quoted 38 lines · Palmer Dabbelt
Quoted 37 lines · On Thu, 23 Sep 2021 07:59:46 PDT (-0700), [email protected] wrote:
Quoted 25 lines · Marco Elver
Quoted 23 lines · Nathan Chancellor
Currently, the asan-stack parameter is only passed along if
CFLAGS_KASAN_SHADOWis not empty, which requiresKASAN_SHADOW_OFFSETto
be defined inKconfigso that the value can be checked. In RISC-V's case,KASAN_SHADOW_OFFSETis not defined inKconfig, which means that
asan-stack does not get disabled with clang even whenCONFIG_KASAN_STACK
is disabled, resulting in large stack warnings with allmodconfig:
drivers/video/fbdev/omap2/omapfb/displays/panel-lgphilips-lb035q02.c:117:12:error: stack frame size (14400) exceeds limit (2048) in function '
lb035q02_connect' [-Werror,-Wframe-larger-than] static intlb035q02_connect(struct omap_dss_device *dssdev)^1 error generated.
Ensure that the value of
CONFIG_KASAN_STACKis always passed along to
the compiler so that these warnings do not happen whenCONFIG_KASAN_STACKis disabled.Quoted 6 lines
Quoted 4 lines
References:
6baec880d7a5("kasan: turn off asan-stack for clang-8 and earlier")Signed-off-by Nathan Chancellor <[email protected]>Reviewed-by Marco Elver <[email protected]>Thanks!
Quoted 1 line
[ Which tree are you planning to take it through? ]
Quoted 7 lines
Quoted 3 lines
Gah, I was intending for it to go through -mm, then I cc'd neither Andrew nor linux-mm... :/ Andrew, do you want me to resend or can you grab it from LKML?
Acked-by Palmer Dabbelt <[email protected]>(assuming you still want it through somewhere else)
Thanks, it is now in mainline as commit
19532869feb9("kasan: always respectCONFIG_KASAN_STACK").Quoted 11 lines
Quoted 10 lines
Quoted 3 lines
Note,
arch/riscv/include/asm/kasan.hmentionsKASAN_SHADOW_OFFSETin comment (copied from arm64). Did RISC-V just forget to copy over theKconfigoption?I do see it defined in that file as well but you are right that they did
not copy theKconfiglogic, even though it was present in the tree when
RISC-V KASAN was implemented. Perhaps they should so that they get access to the other flags in the "else" branch?Quoted 4 lines
Ya, looks like we just screwed this up. I'm seeing some warnings like
cc1: warning: ‘-fsanitize=kernel-address’ with stack protection
is not supported without ‘-fasan-shadow-offset=’ for this targetHmmm, I thought I did a GCC build with this change but I must not have :/
Quoted 5 lines
which is how I ended up here, I'm assuming that's what you're talking about
here? LMK if you were planning on sending along a fix or if you want me to
go figure it out.Quoted 8 lines
Quoted 5 lines
I took a look at moving the logic into
Kconfiglike arm64 before sending this change and I did not really understand it well enough to do so. I think it would be best if you were able to do that so that nothing gets messed up.I'll do it tomorrow, I'm the last one who touched kasan on riscv :)
Quoted 7 lines
Adding
KASAN_SHADOW_OFFSETconfig makes kasan kernel fails to boot. It receives a *write* fault at the beginning of amemblock_allocfunction while populating the kernel shadow memory: the trap address is in the kasan shadow virtual address range and this corresponds to a kernel address ininit_stack. The question is: how do I populate the stack shadow mapping without using memblock API? It's weird, I don't find anything on other architectures.
@kasan: Any idea what we are doing wrong in riscv to encounter the above situation?
Thanks,
Alex
Quoted 34 lines
And just a short note: I have realized this will break with the sv48 patchset as we decide at runtime the address space width and the kasan shadow start address is different between sv39 and sv48. I will have to do like x86 and move the kasan shadow start at the end of the address space so that it is the same for both sv39 and sv48.
Thanks,
Alex
Quoted 13 lines
Thanks,
Alex
Quoted 8 lines
Cheers,
Nathan_______________________________________________
linux-riscv mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-riscvQuoted 4 lines
_______________________________________________
linux-riscv mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-riscv_______________________________________________
linux-riscv mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-riscv
Dmitry Vyukov
reviewerQuoted 101 lines · Alexandre Ghiti
Hi,
Quoted 89 lines · Alexandre ghiti
Quoted 78 lines · Alex Ghiti
Hi Nathan,
Quoted 75 lines · Nathan Chancellor
Quoted 38 lines · Palmer Dabbelt
Quoted 37 lines · On Thu, 23 Sep 2021 07:59:46 PDT (-0700), [email protected] wrote:
Quoted 25 lines · Marco Elver
Quoted 23 lines · Nathan Chancellor
Currently, the asan-stack parameter is only passed along if
CFLAGS_KASAN_SHADOWis not empty, which requiresKASAN_SHADOW_OFFSETto
be defined inKconfigso that the value can be checked. In RISC-V's case,KASAN_SHADOW_OFFSETis not defined inKconfig, which means that
asan-stack does not get disabled with clang even whenCONFIG_KASAN_STACK
is disabled, resulting in large stack warnings with allmodconfig:
drivers/video/fbdev/omap2/omapfb/displays/panel-lgphilips-lb035q02.c:117:12:error: stack frame size (14400) exceeds limit (2048) in function '
lb035q02_connect' [-Werror,-Wframe-larger-than] static intlb035q02_connect(struct omap_dss_device *dssdev)^1 error generated.
Ensure that the value of
CONFIG_KASAN_STACKis always passed along to
the compiler so that these warnings do not happen whenCONFIG_KASAN_STACKis disabled.Quoted 6 lines
Quoted 4 lines
References:
6baec880d7a5("kasan: turn off asan-stack for clang-8 and earlier")Signed-off-by Nathan Chancellor <[email protected]>Reviewed-by Marco Elver <[email protected]>Thanks!
Quoted 1 line
[ Which tree are you planning to take it through? ]
Quoted 7 lines
Quoted 3 lines
Gah, I was intending for it to go through -mm, then I cc'd neither Andrew nor linux-mm... :/ Andrew, do you want me to resend or can you grab it from LKML?
Acked-by Palmer Dabbelt <[email protected]>(assuming you still want it through somewhere else)
Thanks, it is now in mainline as commit
19532869feb9("kasan: always respectCONFIG_KASAN_STACK").Quoted 11 lines
Quoted 10 lines
Quoted 3 lines
Note,
arch/riscv/include/asm/kasan.hmentionsKASAN_SHADOW_OFFSETin comment (copied from arm64). Did RISC-V just forget to copy over theKconfigoption?I do see it defined in that file as well but you are right that they did
not copy theKconfiglogic, even though it was present in the tree when
RISC-V KASAN was implemented. Perhaps they should so that they get access to the other flags in the "else" branch?Quoted 4 lines
Ya, looks like we just screwed this up. I'm seeing some warnings like
cc1: warning: ‘-fsanitize=kernel-address’ with stack protection
is not supported without ‘-fasan-shadow-offset=’ for this targetHmmm, I thought I did a GCC build with this change but I must not have :/
Quoted 5 lines
which is how I ended up here, I'm assuming that's what you're talking about
here? LMK if you were planning on sending along a fix or if you want me to
go figure it out.Quoted 8 lines
Quoted 5 lines
I took a look at moving the logic into
Kconfiglike arm64 before sending this change and I did not really understand it well enough to do so. I think it would be best if you were able to do that so that nothing gets messed up.I'll do it tomorrow, I'm the last one who touched kasan on riscv :)
Quoted 7 lines
Adding
KASAN_SHADOW_OFFSETconfig makes kasan kernel fails to boot. It receives a *write* fault at the beginning of amemblock_allocfunction while populating the kernel shadow memory: the trap address is in the kasan shadow virtual address range and this corresponds to a kernel address ininit_stack. The question is: how do I populate the stack shadow mapping without using memblock API? It's weird, I don't find anything on other architectures.
Quoted 2 lines
@kasan: Any idea what we are doing wrong in riscv to encounter the above situation?
Hi Alex, Palmer,
The patch changes the definition of the KASAN_SHADOW_OFFSET const. Does it's value change as a result or not? Have you tried to print it before/after?
If value does not change, then this is more mysterious. If it changes, then there lots of possible explanations (points to unmapped region, overlaps with something), but we need to know values before/after to answer this.
Quoted 38 lines
Thanks,
Alex
Quoted 34 lines
And just a short note: I have realized this will break with the sv48 patchset as we decide at runtime the address space width and the kasan shadow start address is different between sv39 and sv48. I will have to do like x86 and move the kasan shadow start at the end of the address space so that it is the same for both sv39 and sv48.
Thanks,
Alex
Quoted 13 lines
Thanks,
Alex
Quoted 8 lines
Cheers,
Nathan_______________________________________________
linux-riscv mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-riscvQuoted 4 lines
_______________________________________________
linux-riscv mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-riscv_______________________________________________
linux-riscv mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-riscv
Quoted 107 lines · Dmitry Vyukov
Quoted 101 lines · Alexandre Ghiti
Hi,
Quoted 89 lines · Alexandre ghiti
Quoted 78 lines · Alex Ghiti
Hi Nathan,
Quoted 75 lines · Nathan Chancellor
Quoted 38 lines · Palmer Dabbelt
Quoted 37 lines · On Thu, 23 Sep 2021 07:59:46 PDT (-0700), [email protected] wrote:
Quoted 25 lines · Marco Elver
Quoted 23 lines · Nathan Chancellor
Currently, the asan-stack parameter is only passed along if
CFLAGS_KASAN_SHADOWis not empty, which requiresKASAN_SHADOW_OFFSETto
be defined inKconfigso that the value can be checked. In RISC-V's case,KASAN_SHADOW_OFFSETis not defined inKconfig, which means that
asan-stack does not get disabled with clang even whenCONFIG_KASAN_STACK
is disabled, resulting in large stack warnings with allmodconfig:
drivers/video/fbdev/omap2/omapfb/displays/panel-lgphilips-lb035q02.c:117:12:error: stack frame size (14400) exceeds limit (2048) in function '
lb035q02_connect' [-Werror,-Wframe-larger-than] static intlb035q02_connect(struct omap_dss_device *dssdev)^1 error generated.
Ensure that the value of
CONFIG_KASAN_STACKis always passed along to
the compiler so that these warnings do not happen whenCONFIG_KASAN_STACKis disabled.Quoted 6 lines
Quoted 4 lines
References:
6baec880d7a5("kasan: turn off asan-stack for clang-8 and earlier")Signed-off-by Nathan Chancellor <[email protected]>Reviewed-by Marco Elver <[email protected]>Thanks!
Quoted 1 line
[ Which tree are you planning to take it through? ]
Quoted 7 lines
Quoted 3 lines
Gah, I was intending for it to go through -mm, then I cc'd neither Andrew nor linux-mm... :/ Andrew, do you want me to resend or can you grab it from LKML?
Acked-by Palmer Dabbelt <[email protected]>(assuming you still want it through somewhere else)
Thanks, it is now in mainline as commit
19532869feb9("kasan: always respectCONFIG_KASAN_STACK").Quoted 11 lines
Quoted 10 lines
Quoted 3 lines
Note,
arch/riscv/include/asm/kasan.hmentionsKASAN_SHADOW_OFFSETin comment (copied from arm64). Did RISC-V just forget to copy over theKconfigoption?I do see it defined in that file as well but you are right that they did
not copy theKconfiglogic, even though it was present in the tree when
RISC-V KASAN was implemented. Perhaps they should so that they get access to the other flags in the "else" branch?Quoted 4 lines
Ya, looks like we just screwed this up. I'm seeing some warnings like
cc1: warning: ‘-fsanitize=kernel-address’ with stack protection
is not supported without ‘-fasan-shadow-offset=’ for this targetHmmm, I thought I did a GCC build with this change but I must not have :/
Quoted 5 lines
which is how I ended up here, I'm assuming that's what you're talking about
here? LMK if you were planning on sending along a fix or if you want me to
go figure it out.Quoted 8 lines
Quoted 5 lines
I took a look at moving the logic into
Kconfiglike arm64 before sending this change and I did not really understand it well enough to do so. I think it would be best if you were able to do that so that nothing gets messed up.I'll do it tomorrow, I'm the last one who touched kasan on riscv :)
Quoted 7 lines
Adding
KASAN_SHADOW_OFFSETconfig makes kasan kernel fails to boot. It receives a *write* fault at the beginning of amemblock_allocfunction while populating the kernel shadow memory: the trap address is in the kasan shadow virtual address range and this corresponds to a kernel address ininit_stack. The question is: how do I populate the stack shadow mapping without using memblock API? It's weird, I don't find anything on other architectures.Quoted 2 lines
@kasan: Any idea what we are doing wrong in riscv to encounter the above situation?
Quoted 8 lines
Hi Alex, Palmer,
The patch changes the definition of the
KASAN_SHADOW_OFFSETconst. Does it's value change as a result or not? Have you tried to print it before/after?
If value does not change, then this is more mysterious. If it changes, then there lots of possible explanations (points to unmapped region, overlaps with something), but we need to know values before/after to
So I debugged a bit more what happened here, and actually the culprit is the call to kasan_populate_early_shadow at the beginning of kasan_init which write-protects the access to kasan_early_shadow_page and hence the write fault later when using memblock. I don't see the point of this call anyway since we populate swapper_pg_dir in kasan_early_init and then we write-protect the access to kasan_early_shadow_page at the end of kasan_init.
But that may not be ideal, so I'm open to a better suggestion than just removing the call to kasan_populate_early_shadow.
Sorry I did not dig further before asking and thanks for your time,
Alex
Quoted 41 lines
answer this.
Quoted 38 lines
Thanks,
Alex
Quoted 34 lines
And just a short note: I have realized this will break with the sv48 patchset as we decide at runtime the address space width and the kasan shadow start address is different between sv39 and sv48. I will have to do like x86 and move the kasan shadow start at the end of the address space so that it is the same for both sv39 and sv48.
Thanks,
Alex
Quoted 13 lines
Thanks,
Alex
Quoted 8 lines
Cheers,
Nathan_______________________________________________
linux-riscv mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-riscvQuoted 4 lines
_______________________________________________
linux-riscv mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-riscv_______________________________________________
linux-riscv mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-riscv
Palmer Dabbelt
maintainerQuoted 66 lines · On Thu, 14 Oct 2021 11:31:00 PDT (-0700), [email protected] wrote:
Hi Nathan,
Le 14/10/2021 à 18:55, Nathan Chancellor a écrit :
Quoted 63 lines · Palmer Dabbelt
Quoted 31 lines · On Thu, 23 Sep 2021 07:59:46 PDT (-0700), [email protected] wrote:
Quoted 30 lines · Marco Elver
Quoted 19 lines · Nathan Chancellor
Quoted 18 lines
Currently, the asan-stack parameter is only passed along if
CFLAGS_KASAN_SHADOWis not empty, which requiresKASAN_SHADOW_OFFSETto be defined inKconfigso that the value can be checked. In RISC-V's case,KASAN_SHADOW_OFFSETis not defined inKconfig, which means that asan-stack does not get disabled with clang even whenCONFIG_KASAN_STACKis disabled, resulting in large stack warnings with allmodconfig:
drivers/video/fbdev/omap2/omapfb/displays/panel-lgphilips-lb035q02.c:117:12:
error: stack frame size (14400) exceeds limit (2048) in function 'lb035q02_connect' [-Werror,-Wframe-larger-than]
static intlb035q02_connect(struct omap_dss_device *dssdev)^1 error generated.
Ensure that the value of
CONFIG_KASAN_STACKis always passed along to the compiler so that these warnings do not happen whenCONFIG_KASAN_STACKis disabled.Quoted 5 lines
Quoted 3 lines
References:
6baec880d7a5("kasan: turn off asan-stack for clang-8 and earlier")Signed-off-by Nathan Chancellor <[email protected]>Reviewed-by Marco Elver <[email protected]>Thanks!
Quoted 1 line
[ Which tree are you planning to take it through? ]
Quoted 7 lines
Quoted 3 lines
Gah, I was intending for it to go through -mm, then I cc'd neither Andrew nor linux-mm... :/ Andrew, do you want me to resend or can you grab it from LKML?
Acked-by Palmer Dabbelt <[email protected]>(assuming you still want it through somewhere else)
Thanks, it is now in mainline as commit
19532869feb9("kasan: always respectCONFIG_KASAN_STACK").Quoted 4 lines
Quoted 4 lines
Quoted 3 lines
Note,
arch/riscv/include/asm/kasan.hmentionsKASAN_SHADOW_OFFSETin comment (copied from arm64). Did RISC-V just forget to copy over theKconfigoption?Quoted 8 lines
Quoted 4 lines
I do see it defined in that file as well but you are right that they did not copy the
Kconfiglogic, even though it was present in the tree when RISC-V KASAN was implemented. Perhaps they should so that they get access to the other flags in the "else" branch?Ya, looks like we just screwed this up. I'm seeing some warnings like
cc1: warning: ‘-fsanitize=kernel-address’ with stack protection is not supported without ‘-fasan-shadow-offset=’ for this target
Hmmm, I thought I did a GCC build with this change but I must not have :/
Quoted 3 lines
which is how I ended up here, I'm assuming that's what you're talking about here? LMK if you were planning on sending along a fix or if you want me to go figure it out.
Quoted 7 lines
Quoted 5 lines
I took a look at moving the logic into
Kconfiglike arm64 before sending this change and I did not really understand it well enough to do so. I think it would be best if you were able to do that so that nothing gets messed up.I'll do it tomorrow, I'm the last one who touched kasan on riscv :)
Any luck? I tried what I think is the simple way to do it last week, (merging with Linus' tree is turning these warnings into build failures) but it's hanging on boot. Not sure what's going on
diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index c3f3fd583e04..d3998b4a45f1 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -212,6 +212,12 @@ config PGTABLE_LEVELS
config LOCKDEP_SUPPORT
def_bool y +config KASAN_SHADOW_OFFSET
+ hex + depends on KASAN_GENERIC + default 0xdfffffc800000000 if 64BIT + default 0xffffffff if 32BIT
+
source "arch/riscv/Kconfig.socs"
source "arch/riscv/Kconfig.erratas"
diff --git a/arch/riscv/include/asm/kasan.h b/arch/riscv/include/asm/kasan.h
index a2b3d9cdbc86..b00f503ec124 100644
--- a/arch/riscv/include/asm/kasan.h
+++ b/arch/riscv/include/asm/kasan.h
@@ -30,8 +30,7 @@
#define KASAN_SHADOW_SIZE (UL(1) << ((CONFIG_VA_BITS - 1) - KASAN_SHADOW_SCALE_SHIFT))
#define KASAN_SHADOW_START KERN_VIRT_START
#define KASAN_SHADOW_END (KASAN_SHADOW_START + KASAN_SHADOW_SIZE)
-#define KASAN_SHADOW_OFFSET (KASAN_SHADOW_END - (1ULL << \
- (64 - KASAN_SHADOW_SCALE_SHIFT)))
+#define KASAN_SHADOW_OFFSET _AC(CONFIG_KASAN_SHADOW_OFFSET, UL) void kasan_init(void);
asmlinkage void kasan_early_init(void);Quoted 13 lines
Thanks,
Alex
Quoted 8 lines
Cheers,
Nathan_______________________________________________
linux-riscv mailing list
[email protected]
http://lists.infradead.org/mailman/listinfo/linux-riscv
Andrey Konovalov
reviewerQuoted 31 lines · Nathan Chancellor
Currently, the asan-stack parameter is only passed along if
CFLAGS_KASAN_SHADOWis not empty, which requiresKASAN_SHADOW_OFFSETto be defined inKconfigso that the value can be checked. In RISC-V's case,KASAN_SHADOW_OFFSETis not defined inKconfig, which means that asan-stack does not get disabled with clang even whenCONFIG_KASAN_STACKis disabled, resulting in large stack warnings with allmodconfig:
drivers/video/fbdev/omap2/omapfb/displays/panel-lgphilips-lb035q02.c:117:12:
error: stack frame size (14400) exceeds limit (2048) in function 'lb035q02_connect' [-Werror,-Wframe-larger-than]
static intlb035q02_connect(struct omap_dss_device *dssdev)^1 error generated.
Ensure that the value of
CONFIG_KASAN_STACKis always passed along to the compiler so that these warnings do not happen whenCONFIG_KASAN_STACKis disabled.References:
6baec880d7a5("kasan: turn off asan-stack for clang-8 and earlier")Signed-off-by Nathan Chancellor <[email protected]>--- scripts/Makefile.kasan | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)scripts/Makefile.kasan +0
-0
scripts/Makefile.kasan else · line 37
Quoted 6 lines
scripts/Makefile.kasan +0
-1@@ -33,10 +33,11 @@ else CFLAGS_KASAN := $(CFLAGS_KASAN_SHADOW) \ $(call cc-param,asan-globals=1) \ $(call cc-param,asan-instrumentation-with-call-threshold=$(call_threshold)) \ - $(call cc-param,asan-stack=$(stack_enable)) \ $(call cc-param,asan-instrument-allocas=1) endif
This part of code always looked weird to me.
Shouldn't we be able to pull all these options out of the else section?
Then, the code structure would make sense: first, try applying KASAN_SHADOW_OFFSET; if failed, use CFLAGS_KASAN_MINIMAL; and then try applying all these options one by one.
Quoted 10 lines
scripts/Makefile.kasan +2
-0+CFLAGS_KASAN += $(call cc-param,asan-stack=$(stack_enable)) + endif # CONFIG_KASAN_GENERIC ifdef CONFIG_KASAN_SW_TAGSbase-commit:
4057525736b159bd456732d11270af2cc49ec21f--
2.33.0.514.g99c99ed825
Nathan Chancellor
maintainerQuoted 41 lines · Andrey Konovalov
Quoted 31 lines · Nathan Chancellor
Currently, the asan-stack parameter is only passed along if
CFLAGS_KASAN_SHADOWis not empty, which requiresKASAN_SHADOW_OFFSETto be defined inKconfigso that the value can be checked. In RISC-V's case,KASAN_SHADOW_OFFSETis not defined inKconfig, which means that asan-stack does not get disabled with clang even whenCONFIG_KASAN_STACKis disabled, resulting in large stack warnings with allmodconfig:
drivers/video/fbdev/omap2/omapfb/displays/panel-lgphilips-lb035q02.c:117:12:
error: stack frame size (14400) exceeds limit (2048) in function 'lb035q02_connect' [-Werror,-Wframe-larger-than]
static intlb035q02_connect(struct omap_dss_device *dssdev)^1 error generated.
Ensure that the value of
CONFIG_KASAN_STACKis always passed along to the compiler so that these warnings do not happen whenCONFIG_KASAN_STACKis disabled.References:
6baec880d7a5("kasan: turn off asan-stack for clang-8 and earlier")Signed-off-by Nathan Chancellor <[email protected]>--- scripts/Makefile.kasan | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)scripts/Makefile.kasan +0
-0scripts/Makefile.kasan else · line 37
Quoted 6 lines
scripts/Makefile.kasan +0
-1@@ -33,10 +33,11 @@ else CFLAGS_KASAN := $(CFLAGS_KASAN_SHADOW) \ $(call cc-param,asan-globals=1) \ $(call cc-param,asan-instrumentation-with-call-threshold=$(call_threshold)) \ - $(call cc-param,asan-stack=$(stack_enable)) \ $(call cc-param,asan-instrument-allocas=1) endifThis part of code always looked weird to me.
Quoted 5 lines
Shouldn't we be able to pull all these options out of the else section?
Then, the code structure would make sense: first, try applying
KASAN_SHADOW_OFFSET; if failed, useCFLAGS_KASAN_MINIMAL; and then try applying all these options one by one.
Prior to commit 1a69e7ce8391 ("kasan/Makefile: support LLVM style asan parameters"), all the flags were run under one cc-option, meaning that if $(KASAN_SHADOW_OFFSET) was not set, the whole call would fail. However, after that commit, it is possible to do this but I was not sure if that was intentional so I went for the minimal fix.
Cheers,
Nathan
Andrey Konovalov
reviewerQuoted 9 lines · Nathan Chancellor
Quoted 8 lines
This part of code always looked weird to me.
Shouldn't we be able to pull all these options out of the else section?
Then, the code structure would make sense: first, try applying
KASAN_SHADOW_OFFSET; if failed, useCFLAGS_KASAN_MINIMAL; and then try applying all these options one by one.
Quoted 5 lines
Prior to commit
1a69e7ce8391("kasan/Makefile: support LLVM style asan parameters"), all the flags were run under one cc-option, meaning that if $(KASAN_SHADOW_OFFSET) was not set, the whole call would fail. However, after that commit, it is possible to do this but I was not sure if that was intentional so I went for the minimal fix.
Ack. Filed https://bugzilla.kernel.org/show_bug.cgi?id=214629 for the rest.
Thanks!