LinuxPPC-Dev Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Daniel Axtens <dja@axtens.net>
To: aneesh.kumar@linux.ibm.com, christophe.leroy@c-s.fr,
	bsingharora@gmail.com
Cc: linuxppc-dev@lists.ozlabs.org, kasan-dev@googlegroups.com,
	Daniel Axtens <dja@axtens.net>
Subject: [RFCv2 PATCH 0/4] powerpc: KASAN for 64-bit Book3E
Date: Tue, 12 Mar 2019 12:23:44 +1100	[thread overview]
Message-ID: <20190312012348.4854-1-dja@axtens.net> (raw)

Building on the work of Christophe, Aneesh and Balbir, I've ported
KASAN to the e6500, a 64-bit Book3E processor which doesn't have a
hashed page table. It applies on top of Christophe's series, v9, plus
the proposed new version of patch 2.

It requires some changes to the KASAN core; we use the less ugly
outline readiness check patch proposed by Christophe.

The KASAN shadow area is mapped into vmemmap space:
0x8000 0400 0000 0000 to 0x8000 0600 0000 0000.
To do this we require that vmemmap be disabled. (This is the default
in the kernel config that QorIQ provides for the machine in their
SDK anyway - they use flat memory.)

Only outline instrumentation is supported and only KASAN_MINIMAL works.
Only the kernel linear mapping (0xc000...) is checked. The vmalloc and
ioremap areas (also in 0x800...) are all mapped to a zero page. As
with the Book3S hash series, this requires overriding the memory <->
shadow mapping.

Also, as with both previous 64-bit series, early instrumentation is not
supported.

KVM, kexec and xmon have not been tested.

Thanks to those who have done the heavy lifting over the past several years:
 - Christophe's 32 bit series: https://lists.ozlabs.org/pipermail/linuxppc-dev/2019-February/185379.html
 - Aneesh's Book3S hash series: https://lwn.net/Articles/655642/
 - Balbir's Book3S radix series: https://patchwork.ozlabs.org/patch/795211/

While useful if you have an Book3E device, this is mostly intended as
a warm-up exercise for reviving Aneesh's series for book3s hash. I
expect that the changes to the KASAN core will be required for that
too, but I'll check against the book3s version before I send a non-RFC
version. Once I do that I'll revisit the vmemmap decision as well.

Changes from RFCv1:

 - Use Christophe's new version of outline readiness check
 
 - Rebase on top of Christophe's v9 + the proposed changes to
   string/memory functions

Regards,
Daniel

Daniel Axtens (4):
  kasan: do not open-code addr_has_shadow
  kasan: allow architectures to manage the memory-to-shadow mapping
  kasan: allow architectures to provide an outline readiness check
  powerpc: KASAN for 64bit Book3E

 arch/powerpc/Kconfig                         |  1 +
 arch/powerpc/Kconfig.debug                   |  2 +-
 arch/powerpc/include/asm/kasan.h             | 73 +++++++++++++++++++-
 arch/powerpc/mm/Makefile                     |  2 +
 arch/powerpc/mm/kasan/Makefile               |  1 +
 arch/powerpc/mm/kasan/kasan_init_book3e_64.c | 53 ++++++++++++++
 include/linux/kasan.h                        |  6 ++
 mm/kasan/generic.c                           |  6 +-
 mm/kasan/generic_report.c                    |  2 +-
 mm/kasan/kasan.h                             |  6 +-
 mm/kasan/report.c                            |  6 +-
 mm/kasan/tags.c                              |  3 +-
 12 files changed, 149 insertions(+), 12 deletions(-)
 create mode 100644 arch/powerpc/mm/kasan/kasan_init_book3e_64.c

-- 
2.19.1


             reply	other threads:[~2019-03-12  1:25 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-03-12  1:23 Daniel Axtens [this message]
2019-03-12  1:23 ` [RFCv2 PATCH 1/4] kasan: do not open-code addr_has_shadow Daniel Axtens
2019-03-12  1:23 ` [RFCv2 PATCH 2/4] kasan: allow architectures to manage the memory-to-shadow mapping Daniel Axtens
2019-03-12  1:23 ` [RFCv2 PATCH 3/4] kasan: allow architectures to provide an outline readiness check Daniel Axtens
2019-03-12  1:23 ` [RFCv2 PATCH 4/4] powerpc: KASAN for 64bit Book3E Daniel Axtens
2019-03-12  8:30   ` 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=20190312012348.4854-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=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