[lkml]   [2020]   [Feb]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [PATCH v7 4/4] powerpc: Book3S 64-bit "heavyweight" KASAN support

Le 13/02/2020 à 01:47, Daniel Axtens a écrit :
> KASAN support on Book3S is a bit tricky to get right:
> - It would be good to support inline instrumentation so as to be able to
> catch stack issues that cannot be caught with outline mode.
> - Inline instrumentation requires a fixed offset.
> - Book3S runs code in real mode after booting. Most notably a lot of KVM
> runs in real mode, and it would be good to be able to instrument it.
> - Because code runs in real mode after boot, the offset has to point to
> valid memory both in and out of real mode.
> [ppc64 mm note: The kernel installs a linear mapping at effective
> address c000... onward. This is a one-to-one mapping with physical
> memory from 0000... onward. Because of how memory accesses work on
> powerpc 64-bit Book3S, a kernel pointer in the linear map accesses the
> same memory both with translations on (accessing as an 'effective
> address'), and with translations off (accessing as a 'real
> address'). This works in both guests and the hypervisor. For more
> details, see s5.7 of Book III of version 3 of the ISA, in particular
> the Storage Control Overview, s5.7.3, and s5.7.5 - noting that this
> KASAN implementation currently only supports Radix.]
> One approach is just to give up on inline instrumentation. This way all
> checks can be delayed until after everything set is up correctly, and the
> address-to-shadow calculations can be overridden. However, the features and
> speed boost provided by inline instrumentation are worth trying to do
> better.
> If _at compile time_ it is known how much contiguous physical memory a
> system has, the top 1/8th of the first block of physical memory can be set
> aside for the shadow. This is a big hammer and comes with 3 big
> consequences:
> - there's no nice way to handle physically discontiguous memory, so only
> the first physical memory block can be used.
> - kernels will simply fail to boot on machines with less memory than
> specified when compiling.
> - kernels running on machines with more memory than specified when
> compiling will simply ignore the extra memory.
> Implement and document KASAN this way. The current implementation is Radix
> only.
> Despite the limitations, it can still find bugs,
> e.g.
> At the moment, this physical memory limit must be set _even for outline
> mode_. This may be changed in a later series - a different implementation
> could be added for outline mode that dynamically allocates shadow at a
> fixed offset. For example, see
> Suggested-by: Michael Ellerman <>
> Cc: Balbir Singh <> # ppc64 out-of-line radix version
> Cc: Christophe Leroy <> # ppc32 version
> Signed-off-by: Daniel Axtens <>

Reviewed-by: <> # focussed mainly on
Documentation and things impacting PPC32

 \ /
  Last update: 2020-02-13 07:09    [W:0.068 / U:1.992 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site