From: Christophe Leroy <christophe.leroy@c-s.fr>
To: Daniel Axtens <dja@axtens.net>,
linux-kernel@vger.kernel.org, linux-mm@kvack.org,
linuxppc-dev@lists.ozlabs.org, kasan-dev@googlegroups.com,
aneesh.kumar@linux.ibm.com, bsingharora@gmail.com
Cc: Michael Ellerman <mpe@ellerman.id.au>
Subject: Re: [PATCH v7 4/4] powerpc: Book3S 64-bit "heavyweight" KASAN support
Date: Thu, 13 Feb 2020 07:08:27 +0100 [thread overview]
Message-ID: <67370fc6-8fe8-c5ba-d97a-4a4c399b0ae0@c-s.fr> (raw)
In-Reply-To: <20200213004752.11019-5-dja@axtens.net>
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. http://patchwork.ozlabs.org/patch/1103775/
>
> 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 https://patchwork.ozlabs.org/patch/795211/
>
> Suggested-by: Michael Ellerman <mpe@ellerman.id.au>
> Cc: Balbir Singh <bsingharora@gmail.com> # ppc64 out-of-line radix version
> Cc: Christophe Leroy <christophe.leroy@c-s.fr> # ppc32 version
> Signed-off-by: Daniel Axtens <dja@axtens.net>
Reviewed-by: <christophe.leroy@c-s.fr> # focussed mainly on
Documentation and things impacting PPC32
next prev parent reply other threads:[~2020-02-13 6:08 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-13 0:47 [PATCH v7 0/4] KASAN for powerpc64 radix Daniel Axtens
2020-02-13 0:47 ` [PATCH v7 1/4] kasan: define and use MAX_PTRS_PER_* for early shadow tables Daniel Axtens
2020-02-13 0:47 ` [PATCH v7 2/4] kasan: Document support on 32-bit powerpc Daniel Axtens
2020-02-13 0:47 ` [PATCH v7 3/4] powerpc/mm/kasan: rename kasan_init_32.c to init_32.c Daniel Axtens
2020-02-13 0:47 ` [PATCH v7 4/4] powerpc: Book3S 64-bit "heavyweight" KASAN support Daniel Axtens
2020-02-13 6:08 ` Christophe Leroy [this message]
2020-02-13 11:36 ` Christophe Leroy
2020-03-06 13:09 ` Daniel Axtens
2020-02-16 23:08 ` Michael Neuling
2020-02-17 6:45 ` Christophe Leroy
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=67370fc6-8fe8-c5ba-d97a-4a4c399b0ae0@c-s.fr \
--to=christophe.leroy@c-s.fr \
--cc=aneesh.kumar@linux.ibm.com \
--cc=bsingharora@gmail.com \
--cc=dja@axtens.net \
--cc=kasan-dev@googlegroups.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mpe@ellerman.id.au \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).