| Message ID | 20210319144058.772525-2-dja@axtens.net (mailing list archive) |
|---|---|
| State | Superseded |
| Headers | show |
| Series | KASAN for powerpc64 radix | expand |
| Related | show |
| Context | Check | Description |
|---|---|---|
| snowpatch_ozlabs/apply_patch | warning | Failed to apply on branch powerpc/merge (87d76f542a24ecfa797e9bd3bb56c0f19aabff57) |
| snowpatch_ozlabs/apply_patch | warning | Failed to apply on branch powerpc/next (fbda7904302499dd7ffc073a3c84eb7c9275db0a) |
| snowpatch_ozlabs/apply_patch | warning | Failed to apply on branch linus/master (8b12a62a4e3ed4ae99c715034f557eb391d6b196) |
| snowpatch_ozlabs/apply_patch | warning | Failed to apply on branch powerpc/fixes (cc7a0bb058b85ea03db87169c60c7cfdd5d34678) |
| snowpatch_ozlabs/apply_patch | warning | Failed to apply on branch linux-next (1df27313f50a57497c1faeb6a6ae4ca939c85a7d) |
| snowpatch_ozlabs/apply_patch | fail | Failed to apply to any branch |
On Sat, Mar 20, 2021 at 01:40:53AM +1100, Daniel Axtens wrote: > For annoying architectural reasons, it's very difficult to support inline > instrumentation on powerpc64. I think we can expand here and talk about how in hash mode, the vmalloc address space is in a region of memory different than where kernel virtual addresses are mapped. Did I recollect the reason correctly? > > Add a Kconfig flag to allow an arch to disable inline. (It's a bit > annoying to be 'backwards', but I'm not aware of any way to have > an arch force a symbol to be 'n', rather than 'y'.) > > We also disable stack instrumentation in this case as it does things that > are functionally equivalent to inline instrumentation, namely adding > code that touches the shadow directly without going through a C helper. > > Signed-off-by: Daniel Axtens <dja@axtens.net> > --- > lib/Kconfig.kasan | 8 ++++++++ > 1 file changed, 8 insertions(+) > > diff --git a/lib/Kconfig.kasan b/lib/Kconfig.kasan > index cffc2ebbf185..7e237dbb6df3 100644 > --- a/lib/Kconfig.kasan > +++ b/lib/Kconfig.kasan > @@ -12,6 +12,9 @@ config HAVE_ARCH_KASAN_HW_TAGS > config HAVE_ARCH_KASAN_VMALLOC > bool > > +config ARCH_DISABLE_KASAN_INLINE > + def_bool n > + Some comments on what arch's want to disable kasan inline would be helpful and why. Balbir Singh.
Balbir Singh <bsingharora@gmail.com> writes: > On Sat, Mar 20, 2021 at 01:40:53AM +1100, Daniel Axtens wrote: >> For annoying architectural reasons, it's very difficult to support inline >> instrumentation on powerpc64. > > I think we can expand here and talk about how in hash mode, the vmalloc > address space is in a region of memory different than where kernel virtual > addresses are mapped. Did I recollect the reason correctly? I think that's _a_ reason, but for radix mode (which is all I support at the moment), the reason is a bit simpler. We call into generic code like the DT parser and printk when we have translations off. The shadow region lives at c00e.... which is not part of the linear mapping, so if you try to access the shadow while in real mode you will access unmapped memory and (at least on PowerNV) take a machine check. >> >> Add a Kconfig flag to allow an arch to disable inline. (It's a bit >> annoying to be 'backwards', but I'm not aware of any way to have >> an arch force a symbol to be 'n', rather than 'y'.) >> >> We also disable stack instrumentation in this case as it does things that >> are functionally equivalent to inline instrumentation, namely adding >> code that touches the shadow directly without going through a C helper. >> >> Signed-off-by: Daniel Axtens <dja@axtens.net> >> --- >> lib/Kconfig.kasan | 8 ++++++++ >> 1 file changed, 8 insertions(+) >> >> diff --git a/lib/Kconfig.kasan b/lib/Kconfig.kasan >> index cffc2ebbf185..7e237dbb6df3 100644 >> --- a/lib/Kconfig.kasan >> +++ b/lib/Kconfig.kasan >> @@ -12,6 +12,9 @@ config HAVE_ARCH_KASAN_HW_TAGS >> config HAVE_ARCH_KASAN_VMALLOC >> bool >> >> +config ARCH_DISABLE_KASAN_INLINE >> + def_bool n >> + > > Some comments on what arch's want to disable kasan inline would > be helpful and why. Sure, added. Kind regards, Daniel
On Fri, 19 Mar 2021 at 15:41, Daniel Axtens <dja@axtens.net> wrote: > > For annoying architectural reasons, it's very difficult to support inline > instrumentation on powerpc64. > > Add a Kconfig flag to allow an arch to disable inline. (It's a bit > annoying to be 'backwards', but I'm not aware of any way to have > an arch force a symbol to be 'n', rather than 'y'.) > > We also disable stack instrumentation in this case as it does things that > are functionally equivalent to inline instrumentation, namely adding > code that touches the shadow directly without going through a C helper. > > Signed-off-by: Daniel Axtens <dja@axtens.net> > --- > lib/Kconfig.kasan | 8 ++++++++ > 1 file changed, 8 insertions(+) > > diff --git a/lib/Kconfig.kasan b/lib/Kconfig.kasan > index cffc2ebbf185..7e237dbb6df3 100644 > --- a/lib/Kconfig.kasan > +++ b/lib/Kconfig.kasan > @@ -12,6 +12,9 @@ config HAVE_ARCH_KASAN_HW_TAGS > config HAVE_ARCH_KASAN_VMALLOC > bool > > +config ARCH_DISABLE_KASAN_INLINE > + def_bool n > + Does just "bool" work here? > config CC_HAS_KASAN_GENERIC > def_bool $(cc-option, -fsanitize=kernel-address) > > @@ -130,6 +133,7 @@ config KASAN_OUTLINE > > config KASAN_INLINE > bool "Inline instrumentation" > + depends on !ARCH_DISABLE_KASAN_INLINE > help > Compiler directly inserts code checking shadow memory before > memory accesses. This is faster than outline (in some workloads > @@ -142,6 +146,7 @@ config KASAN_STACK > bool "Enable stack instrumentation (unsafe)" if CC_IS_CLANG && !COMPILE_TEST > depends on KASAN_GENERIC || KASAN_SW_TAGS > default y if CC_IS_GCC > + depends on !ARCH_DISABLE_KASAN_INLINE Minor, but perhaps this 'depends on' line could be moved up 1 line to be grouped with the other 'depends on'. > help > The LLVM stack address sanitizer has a know problem that > causes excessive stack usage in a lot of functions, see > @@ -154,6 +159,9 @@ config KASAN_STACK > but clang users can still enable it for builds without > CONFIG_COMPILE_TEST. On gcc it is assumed to always be safe > to use and enabled by default. > + If the architecture disables inline instrumentation, this is > + also disabled as it adds inline-style instrumentation that > + is run unconditionally. > > config KASAN_SW_TAGS_IDENTIFY > bool "Enable memory corruption identification" > -- > 2.27.0 > > -- > 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 view this discussion on the web visit https://groups.google.com/d/msgid/kasan-dev/20210319144058.772525-2-dja%40axtens.net.
Daniel Axtens <dja@axtens.net> writes: > Balbir Singh <bsingharora@gmail.com> writes: > >> On Sat, Mar 20, 2021 at 01:40:53AM +1100, Daniel Axtens wrote: >>> For annoying architectural reasons, it's very difficult to support inline >>> instrumentation on powerpc64. >> >> I think we can expand here and talk about how in hash mode, the vmalloc >> address space is in a region of memory different than where kernel virtual >> addresses are mapped. Did I recollect the reason correctly? > > I think that's _a_ reason, but for radix mode (which is all I support at > the moment), the reason is a bit simpler. Actually Aneesh fixed that in: 0034d395f89d ("powerpc/mm/hash64: Map all the kernel regions in the same 0xc range") The problem we had prior to that was that the linear mapping was at (0xc << 60), vmalloc was at (0xd << 60), and vmemap was at (0xf << 60). Meaning our shadow region would need to be more than (3 << 60) in size. cheers
diff --git a/lib/Kconfig.kasan b/lib/Kconfig.kasan index cffc2ebbf185..7e237dbb6df3 100644 --- a/lib/Kconfig.kasan +++ b/lib/Kconfig.kasan @@ -12,6 +12,9 @@ config HAVE_ARCH_KASAN_HW_TAGS config HAVE_ARCH_KASAN_VMALLOC bool +config ARCH_DISABLE_KASAN_INLINE + def_bool n + config CC_HAS_KASAN_GENERIC def_bool $(cc-option, -fsanitize=kernel-address) @@ -130,6 +133,7 @@ config KASAN_OUTLINE config KASAN_INLINE bool "Inline instrumentation" + depends on !ARCH_DISABLE_KASAN_INLINE help Compiler directly inserts code checking shadow memory before memory accesses. This is faster than outline (in some workloads @@ -142,6 +146,7 @@ config KASAN_STACK bool "Enable stack instrumentation (unsafe)" if CC_IS_CLANG && !COMPILE_TEST depends on KASAN_GENERIC || KASAN_SW_TAGS default y if CC_IS_GCC + depends on !ARCH_DISABLE_KASAN_INLINE help The LLVM stack address sanitizer has a know problem that causes excessive stack usage in a lot of functions, see @@ -154,6 +159,9 @@ config KASAN_STACK but clang users can still enable it for builds without CONFIG_COMPILE_TEST. On gcc it is assumed to always be safe to use and enabled by default. + If the architecture disables inline instrumentation, this is + also disabled as it adds inline-style instrumentation that + is run unconditionally. config KASAN_SW_TAGS_IDENTIFY bool "Enable memory corruption identification"
For annoying architectural reasons, it's very difficult to support inline instrumentation on powerpc64. Add a Kconfig flag to allow an arch to disable inline. (It's a bit annoying to be 'backwards', but I'm not aware of any way to have an arch force a symbol to be 'n', rather than 'y'.) We also disable stack instrumentation in this case as it does things that are functionally equivalent to inline instrumentation, namely adding code that touches the shadow directly without going through a C helper. Signed-off-by: Daniel Axtens <dja@axtens.net> --- lib/Kconfig.kasan | 8 ++++++++ 1 file changed, 8 insertions(+)