linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Daniel Axtens <dja@axtens.net>
To: linux-kernel@vger.kernel.org, linux-mm@kvack.org,
	linuxppc-dev@lists.ozlabs.org, kasan-dev@googlegroups.com,
	christophe.leroy@c-s.fr, aneesh.kumar@linux.ibm.com,
	bsingharora@gmail.com
Cc: Daniel Axtens <dja@axtens.net>
Subject: [PATCH v9 0/6] KASAN for powerpc64 radix
Date: Wed,  2 Dec 2020 03:16:26 +1100	[thread overview]
Message-ID: <20201201161632.1234753-1-dja@axtens.net> (raw)

Building on the work of Christophe, Aneesh and Balbir, I've ported
KASAN to 64-bit Book3S kernels running on the Radix MMU.

This is a significant reworking of the previous versions. Instead of
the previous approach which supported inline instrumentation, this
series provides only outline instrumentation.

To get around the problem of accessing the shadow region inside code we run
with translations off (in 'real mode'), we we restrict checking to when
translations are enabled. This is done via a new hook in the kasan core and
by excluding larger quantites of arch code from instrumentation. The upside
is that we no longer require that you be able to specify the amount of
physically contiguous memory on the system at compile time. Hopefully this
is a better trade-off. More details in patch 6.

kexec works. Both 64k and 4k pages work. Running as a KVM host works, but
nothing in arch/powerpc/kvm is instrumented. It's also potentially a bit
fragile - if any real mode code paths call out to instrumented code, things
will go boom.

There are 4 failing KUnit tests:

kasan_stack_oob, kasan_alloca_oob_left & kasan_alloca_oob_right - these are
due to not supporting inline instrumentation.

kasan_global_oob - gcc puts the ASAN init code in a section called
'.init_array'. Powerpc64 module loading code goes through and _renames_ any
section beginning with '.init' to begin with '_init' in order to avoid some
complexities around our 24-bit indirect jumps. This means it renames
'.init_array' to '_init_array', and the generic module loading code then
fails to recognise the section as a constructor and thus doesn't run
it. This hack dates back to 2003 and so I'm not going to try to unpick it
in this series. (I suspect this may have previously worked if the code
ended up in .ctors rather than .init_array but I don't keep my old binaries
around so I have no real way of checking.)


Daniel Axtens (6):
  kasan: allow an architecture to disable inline instrumentation
  kasan: allow architectures to provide an outline readiness check
  kasan: define and use MAX_PTRS_PER_* for early shadow tables
  kasan: Document support on 32-bit powerpc
  powerpc/mm/kasan: rename kasan_init_32.c to init_32.c
  powerpc: Book3S 64-bit outline-only KASAN support




             reply	other threads:[~2020-12-01 16:16 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-12-01 16:16 Daniel Axtens [this message]
2020-12-01 16:16 ` [PATCH v9 1/6] kasan: allow an architecture to disable inline instrumentation Daniel Axtens
2020-12-01 16:49   ` Christophe Leroy
2020-12-01 16:16 ` [PATCH v9 2/6] kasan: allow architectures to provide an outline readiness check Daniel Axtens
2020-12-01 16:53   ` Christophe Leroy
2020-12-01 16:16 ` [PATCH v9 3/6] kasan: define and use MAX_PTRS_PER_* for early shadow tables Daniel Axtens
2020-12-01 16:54   ` Christophe Leroy
2020-12-01 16:16 ` [PATCH v9 4/6] kasan: Document support on 32-bit powerpc Daniel Axtens
2020-12-01 16:56   ` Christophe Leroy
2020-12-01 16:16 ` [PATCH v9 5/6] powerpc/mm/kasan: rename kasan_init_32.c to init_32.c Daniel Axtens
2020-12-01 16:56   ` Christophe Leroy
2020-12-01 16:16 ` [PATCH v9 6/6] powerpc: Book3S 64-bit outline-only KASAN support Daniel Axtens
2020-12-01 17:26   ` Christophe Leroy
2021-02-03 11:46     ` Daniel Axtens
2020-12-02 15:11 ` [PATCH v9 0/6] KASAN for powerpc64 radix Andrey Konovalov

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=20201201161632.1234753-1-dja@axtens.net \
    --to=dja@axtens.net \
    --cc=aneesh.kumar@linux.ibm.com \
    --cc=bsingharora@gmail.com \
    --cc=christophe.leroy@c-s.fr \
    --cc=kasan-dev@googlegroups.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=linuxppc-dev@lists.ozlabs.org \
    /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).