* Re: [PATCH v11 1/6] kasan: allow an architecture to disable inline instrumentation
From: Daniel Axtens @ 2021-03-22 0:29 UTC (permalink / raw)
To: Balbir Singh
Cc: aneesh.kumar, linux-kernel, linux-mm, kasan-dev, linuxppc-dev
In-Reply-To: <20210320014606.GB77072@balbir-desktop>
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
^ permalink raw reply
* Re: [GIT PULL] Please pull powerpc/linux.git powerpc-5.12-4 tag
From: pr-tracker-bot @ 2021-03-21 18:45 UTC (permalink / raw)
To: Michael Ellerman; +Cc: tyreld, Linus Torvalds, linuxppc-dev, linux-kernel
In-Reply-To: <875z1lhytk.fsf@mpe.ellerman.id.au>
The pull request you sent on Sun, 21 Mar 2021 16:15:35 +1100:
> https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git tags/powerpc-5.12-4
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/b35660a7cebdf438e01bba05075ae2bcc0125650
Thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/prtracker.html
^ permalink raw reply
* Re: [PATCH] crypto: nx: fix incorrect kernel-doc comment syntax in files
From: Randy Dunlap @ 2021-03-21 17:34 UTC (permalink / raw)
To: Aditya Srivastava
Cc: linuxppc-dev, herbert, corbet, nayna, linux-kernel, pfsmorigo,
linux-crypto, leitao, lukas.bulwahn, linux-kernel-mentees, davem,
paulus
In-Reply-To: <20210321123007.15505-1-yashsri421@gmail.com>
Looks good. Thanks.
Acked-by: Randy Dunlap <rdunlap@infradead.org>
^ permalink raw reply
* [PATCH] crypto: nx: fix incorrect kernel-doc comment syntax in files
From: Aditya Srivastava @ 2021-03-21 12:30 UTC (permalink / raw)
To: linux-kernel
Cc: nayna, herbert, corbet, rdunlap, linuxppc-dev, yashsri421,
pfsmorigo, linux-crypto, leitao, lukas.bulwahn,
linux-kernel-mentees, davem, paulus
The opening comment mark '/**' is used for highlighting the beginning of
kernel-doc comments.
There are certain files in drivers/crypto/nx, which follow this syntax,
but the content inside does not comply with kernel-doc.
Such lines were probably not meant for kernel-doc parsing, but are parsed
due to the presence of kernel-doc like comment syntax(i.e, '/**'), which
causes unexpected warnings from kernel-doc.
E.g., presence of kernel-doc like comment in the header lines for
drivers/crypto/nx/nx-sha256.c at header causes these warnings:
"warning: Function parameter or member 'tfm' not described in 'nx_crypto_ctx_sha256_init'"
"warning: expecting prototype for SHA(). Prototype was for nx_crypto_ctx_sha256_init() instead"
Similarly for other files too.
Provide a simple fix by replacing such occurrences with general comment
format, i.e. '/*', to prevent kernel-doc from parsing it.
Signed-off-by: Aditya Srivastava <yashsri421@gmail.com>
---
* Applies perfectly on next-20210319
drivers/crypto/nx/nx-aes-cbc.c | 2 +-
drivers/crypto/nx/nx-aes-ccm.c | 2 +-
drivers/crypto/nx/nx-aes-ctr.c | 2 +-
drivers/crypto/nx/nx-aes-ecb.c | 2 +-
drivers/crypto/nx/nx-aes-gcm.c | 2 +-
drivers/crypto/nx/nx-aes-xcbc.c | 2 +-
drivers/crypto/nx/nx-sha256.c | 2 +-
drivers/crypto/nx/nx-sha512.c | 2 +-
drivers/crypto/nx/nx.c | 2 +-
drivers/crypto/nx/nx_debugfs.c | 2 +-
10 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/drivers/crypto/nx/nx-aes-cbc.c b/drivers/crypto/nx/nx-aes-cbc.c
index 92e921eceed7..d6314ea9ae89 100644
--- a/drivers/crypto/nx/nx-aes-cbc.c
+++ b/drivers/crypto/nx/nx-aes-cbc.c
@@ -1,5 +1,5 @@
// SPDX-License-Identifier: GPL-2.0-only
-/**
+/*
* AES CBC routines supporting the Power 7+ Nest Accelerators driver
*
* Copyright (C) 2011-2012 International Business Machines Inc.
diff --git a/drivers/crypto/nx/nx-aes-ccm.c b/drivers/crypto/nx/nx-aes-ccm.c
index 4c9362eebefd..e7384d107573 100644
--- a/drivers/crypto/nx/nx-aes-ccm.c
+++ b/drivers/crypto/nx/nx-aes-ccm.c
@@ -1,5 +1,5 @@
// SPDX-License-Identifier: GPL-2.0-only
-/**
+/*
* AES CCM routines supporting the Power 7+ Nest Accelerators driver
*
* Copyright (C) 2012 International Business Machines Inc.
diff --git a/drivers/crypto/nx/nx-aes-ctr.c b/drivers/crypto/nx/nx-aes-ctr.c
index 6d5ce1a66f1e..13f518802343 100644
--- a/drivers/crypto/nx/nx-aes-ctr.c
+++ b/drivers/crypto/nx/nx-aes-ctr.c
@@ -1,5 +1,5 @@
// SPDX-License-Identifier: GPL-2.0-only
-/**
+/*
* AES CTR routines supporting the Power 7+ Nest Accelerators driver
*
* Copyright (C) 2011-2012 International Business Machines Inc.
diff --git a/drivers/crypto/nx/nx-aes-ecb.c b/drivers/crypto/nx/nx-aes-ecb.c
index 77e338dc33f1..7a729dc2bc17 100644
--- a/drivers/crypto/nx/nx-aes-ecb.c
+++ b/drivers/crypto/nx/nx-aes-ecb.c
@@ -1,5 +1,5 @@
// SPDX-License-Identifier: GPL-2.0-only
-/**
+/*
* AES ECB routines supporting the Power 7+ Nest Accelerators driver
*
* Copyright (C) 2011-2012 International Business Machines Inc.
diff --git a/drivers/crypto/nx/nx-aes-gcm.c b/drivers/crypto/nx/nx-aes-gcm.c
index 19c6ed5baea4..fc9baca13920 100644
--- a/drivers/crypto/nx/nx-aes-gcm.c
+++ b/drivers/crypto/nx/nx-aes-gcm.c
@@ -1,5 +1,5 @@
// SPDX-License-Identifier: GPL-2.0-only
-/**
+/*
* AES GCM routines supporting the Power 7+ Nest Accelerators driver
*
* Copyright (C) 2012 International Business Machines Inc.
diff --git a/drivers/crypto/nx/nx-aes-xcbc.c b/drivers/crypto/nx/nx-aes-xcbc.c
index 48dc1c98ca52..eb5c8f689360 100644
--- a/drivers/crypto/nx/nx-aes-xcbc.c
+++ b/drivers/crypto/nx/nx-aes-xcbc.c
@@ -1,5 +1,5 @@
// SPDX-License-Identifier: GPL-2.0-only
-/**
+/*
* AES XCBC routines supporting the Power 7+ Nest Accelerators driver
*
* Copyright (C) 2011-2012 International Business Machines Inc.
diff --git a/drivers/crypto/nx/nx-sha256.c b/drivers/crypto/nx/nx-sha256.c
index 90d9a37a57f6..b0ad665e4bda 100644
--- a/drivers/crypto/nx/nx-sha256.c
+++ b/drivers/crypto/nx/nx-sha256.c
@@ -1,5 +1,5 @@
// SPDX-License-Identifier: GPL-2.0-only
-/**
+/*
* SHA-256 routines supporting the Power 7+ Nest Accelerators driver
*
* Copyright (C) 2011-2012 International Business Machines Inc.
diff --git a/drivers/crypto/nx/nx-sha512.c b/drivers/crypto/nx/nx-sha512.c
index eb8627a0f317..c29103a1a0b6 100644
--- a/drivers/crypto/nx/nx-sha512.c
+++ b/drivers/crypto/nx/nx-sha512.c
@@ -1,5 +1,5 @@
// SPDX-License-Identifier: GPL-2.0-only
-/**
+/*
* SHA-512 routines supporting the Power 7+ Nest Accelerators driver
*
* Copyright (C) 2011-2012 International Business Machines Inc.
diff --git a/drivers/crypto/nx/nx.c b/drivers/crypto/nx/nx.c
index 1d0e8a1ba160..13bb705ba6a4 100644
--- a/drivers/crypto/nx/nx.c
+++ b/drivers/crypto/nx/nx.c
@@ -1,5 +1,5 @@
// SPDX-License-Identifier: GPL-2.0-only
-/**
+/*
* Routines supporting the Power 7+ Nest Accelerators driver
*
* Copyright (C) 2011-2012 International Business Machines Inc.
diff --git a/drivers/crypto/nx/nx_debugfs.c b/drivers/crypto/nx/nx_debugfs.c
index 1975bcbee997..ee7cd88bb10a 100644
--- a/drivers/crypto/nx/nx_debugfs.c
+++ b/drivers/crypto/nx/nx_debugfs.c
@@ -1,5 +1,5 @@
// SPDX-License-Identifier: GPL-2.0-only
-/**
+/*
* debugfs routines supporting the Power 7+ Nest Accelerators driver
*
* Copyright (C) 2011-2012 International Business Machines Inc.
--
2.17.1
^ permalink raw reply related
* Re: [PATCH next v1 2/3] printk: remove safe buffers
From: Sergey Senozhatsky @ 2021-03-21 5:26 UTC (permalink / raw)
To: John Ogness
Cc: Rafael Aquini, Peter Zijlstra, Paul Mackerras, Tiezhu Yang,
Alexey Kardashevskiy, Yue Hu, Jordan Niethe, Petr Mladek,
Kees Cook, Paul E. McKenney, Alistair Popple,
Guilherme G. Piccoli, Nicholas Piggin, Steven Rostedt,
Thomas Gleixner, kexec, linux-kernel, Eric Biederman,
Andrew Morton, linuxppc-dev, Cédric Le Goater
In-Reply-To: <20210316233326.10778-3-john.ogness@linutronix.de>
On (21/03/17 00:33), John Ogness wrote:
[..]
> void printk_nmi_direct_enter(void)
> {
> @@ -324,27 +44,8 @@ void printk_nmi_direct_exit(void)
> this_cpu_and(printk_context, ~PRINTK_NMI_DIRECT_CONTEXT_MASK);
> }
>
> -#else
> -
> -static __printf(1, 0) int vprintk_nmi(const char *fmt, va_list args)
> -{
> - return 0;
> -}
> -
> #endif /* CONFIG_PRINTK_NMI */
>
> -/*
> - * Lock-less printk(), to avoid deadlocks should the printk() recurse
> - * into itself. It uses a per-CPU buffer to store the message, just like
> - * NMI.
> - */
> -static __printf(1, 0) int vprintk_safe(const char *fmt, va_list args)
> -{
> - struct printk_safe_seq_buf *s = this_cpu_ptr(&safe_print_seq);
> -
> - return printk_safe_log_store(s, fmt, args);
> -}
> -
> /* Can be preempted by NMI. */
> void __printk_safe_enter(void)
> {
> @@ -369,7 +70,10 @@ __printf(1, 0) int vprintk_func(const char *fmt, va_list args)
> * Use the main logbuf even in NMI. But avoid calling console
> * drivers that might have their own locks.
> */
> - if ((this_cpu_read(printk_context) & PRINTK_NMI_DIRECT_CONTEXT_MASK)) {
> + if (this_cpu_read(printk_context) &
> + (PRINTK_NMI_DIRECT_CONTEXT_MASK |
> + PRINTK_NMI_CONTEXT_MASK |
> + PRINTK_SAFE_CONTEXT_MASK)) {
Do we need printk_nmi_direct_enter/exit() and PRINTK_NMI_DIRECT_CONTEXT_MASK?
Seems like all printk_safe() paths are now DIRECT - we store messages to the
prb, but don't call console drivers.
-ss
^ permalink raw reply
* Re: remove the legacy ide driver
From: John Paul Adrian Glaubitz @ 2021-03-21 9:20 UTC (permalink / raw)
To: Christoph Hellwig, David S. Miller, Jens Axboe,
Geert Uytterhoeven
Cc: Thomas Bogendoerfer, linux-doc, Bartlomiej Zolnierkiewicz,
Russell King, linux-kernel, linux-ide, linux-m68k,
Ivan Kokshaysky, linux-alpha, Matt Turner, linux-mips,
linuxppc-dev, linux-arm-kernel, Richard Henderson
In-Reply-To: <20210318045706.200458-1-hch@lst.de>
Hello Christoph!
On 3/18/21 5:56 AM, Christoph Hellwig wrote:
> libata mostly covers all hardware supported by the legacy ide driver.
> There are three mips drivers that are not supported, but the linux-mips
> list could not identify any users of those. There also are two m68k
> drivers that do not have libata equivalents, which might or might not
> have users, so we'll need some input and possibly help from the m68k
> community here.
I think those drivers were the Q60 driver and the MacIDE driver, weren't they?
Either way, I have so far been unsuccessful in obtaining access to these machines
but I assume once we gain access to such machines, Bartlomiej could convert the
drivers the same way he already converted the falcon, gayle and buddha drivers,
for example.
One could also just convert the drivers to libata and include them untested, the
conversion itself seems pretty little work for someone experienced with libata.
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer - glaubitz@debian.org
`. `' Freie Universitaet Berlin - glaubitz@physik.fu-berlin.de
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
^ permalink raw reply
* [GIT PULL] Please pull powerpc/linux.git powerpc-5.12-4 tag
From: Michael Ellerman @ 2021-03-21 5:15 UTC (permalink / raw)
To: Linus Torvalds; +Cc: tyreld, linuxppc-dev, linux-kernel
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Hi Linus,
Please pull some more powerpc fixes for 5.12:
The following changes since commit 0b736881c8f1a6cd912f7a9162b9e097b28c1c30:
powerpc/traps: unrecoverable_exception() is not an interrupt handler (2021-03-12 11:02:12 +1100)
are available in the git repository at:
https://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux.git tags/powerpc-5.12-4
for you to fetch changes up to cc7a0bb058b85ea03db87169c60c7cfdd5d34678:
PCI: rpadlpar: Fix potential drc_name corruption in store functions (2021-03-17 13:48:07 +1100)
- ------------------------------------------------------------------
powerpc fixes for 5.12 #4
Fix a possible stack corruption and subsequent DLPAR failure in the rpadlpar_io
PCI hotplug driver.
Two build fixes for uncommon configurations.
Thanks to Christophe Leroy, Tyrel Datwyler.
- ------------------------------------------------------------------
Christophe Leroy (2):
powerpc/vdso32: Add missing _restgpr_31_x to fix build failure
powerpc: Force inlining of cpu_has_feature() to avoid build failure
Tyrel Datwyler (1):
PCI: rpadlpar: Fix potential drc_name corruption in store functions
arch/powerpc/include/asm/cpu_has_feature.h | 4 ++--
arch/powerpc/kernel/vdso32/gettimeofday.S | 11 +++++++++++
drivers/pci/hotplug/rpadlpar_sysfs.c | 14 ++++++--------
3 files changed, 19 insertions(+), 10 deletions(-)
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCAAdFiEEJFGtCPCthwEv2Y/bUevqPMjhpYAFAmBW1cQACgkQUevqPMjh
pYAhog/+KVrIL4frKx1m7bmM+FJ83heS20+F7i5yQWRovR2FdgYwwbIrtxNUKzRU
sNShwQbt9H6GVEGc12kusH5M+t6wGrHrYQ47kdkD6qhDTPfQzKXsoi5eWbgMkQnx
Hd3njqjzfGFEicmfp8l+1WmoWeYpL2MLR7E/KTtS/MYMq5Gsz2lZSMEsmXlAY5Cs
5lT8dBHdH0AX9krRJk9BzKrRqB0qjrK60/sg9oLJQ4sixeWaa+dSORnJq26jYV+n
MPyaNCWF3EUrs7BNyxfZOeFwAZ0FzRSBZrgIt6MNPreT/FaL6lo2McHHyQ9Ls5Qb
yPUmioNKLhXdtcU6AZ0+QOlQvyiGJ7xb3UTAbFFq8TifYHVS0v9srBkgfcvFHycc
yjDtdeTk18WB6NSDC8zVSc+Ut5q7WZa6RLKubiCPgd5DqDkpAKcYcTQSZZUgTb6Q
IyT7bwCBqW6Z5bNTsHhSZ+Ub06L6RLTQ1IfD4GXtqe16F1eeFlMOPCP2YzGUB6s9
IB7GQilliVtRZaFCGwYyVdZCHftHVdK5k7DV+3aImzPRYOKpL4YWwrBnDoqkccYs
Mhbw2YtO7oXSZ2yXGrsu/WF56QCDf6PFO5r28dvNFEi6qZWbfLEQQLZmv/0efFtC
Je1VKXKXCfuLD2VH02F8URZpzbg90dC8YRsTUpgSLCHgiGjEOcE=
=zfoH
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: [PATCH] powerpc: epapr: A typo fix
From: Randy Dunlap @ 2021-03-20 22:41 UTC (permalink / raw)
To: Bhaskar Chowdhury; +Cc: paulus, linuxppc-dev, linux-kernel
In-Reply-To: <20210320213932.22697-1-unixbhaskar@gmail.com>
On Sun, 21 Mar 2021, Bhaskar Chowdhury wrote:
>
> s/parmeters/parameters/
>
> Signed-off-by: Bhaskar Chowdhury <unixbhaskar@gmail.com>
Acked-by: Randy Dunlap <rdunlap@infradead.org>
> ---
> arch/powerpc/include/asm/epapr_hcalls.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/include/asm/epapr_hcalls.h b/arch/powerpc/include/asm/epapr_hcalls.h
> index c99ba08a408d..cdf3c6df5123 100644
> --- a/arch/powerpc/include/asm/epapr_hcalls.h
> +++ b/arch/powerpc/include/asm/epapr_hcalls.h
> @@ -65,7 +65,7 @@
> * but the gcc inline assembly syntax does not allow us to specify registers
> * on the clobber list that are also on the input/output list. Therefore,
> * the lists of clobbered registers depends on the number of register
> - * parmeters ("+r" and "=r") passed to the hypercall.
> + * parameters ("+r" and "=r") passed to the hypercall.
> *
> * Each assembly block should use one of the HCALL_CLOBBERSx macros. As a
> * general rule, 'x' is the number of parameters passed to the assembly
> --
> 2.26.2
>
>
^ permalink raw reply
* Re: [for-stable-4.19 PATCH 1/2] vmlinux.lds.h: Create section for protection against instrumentation
From: Alexandre Chartre @ 2021-03-19 11:20 UTC (permalink / raw)
To: Greg Kroah-Hartman, Nicolas Boichat
Cc: Sasha Levin, linux-arch, Michal Marek, Arnd Bergmann,
linux-kbuild, Peter Zijlstra, Christopher Li, linux-kernel,
stable, Masahiro Yamada, linux-sparse, Paul Mackerras,
Nicholas Piggin, Thomas Gleixner, linuxppc-dev, Naveen N. Rao,
Daniel Axtens
In-Reply-To: <YFR/fQIePjDQcO5W@kroah.com>
On 3/19/21 11:39 AM, Greg Kroah-Hartman wrote:
> On Fri, Mar 19, 2021 at 07:54:15AM +0800, Nicolas Boichat wrote:
>> From: Thomas Gleixner <tglx@linutronix.de>
>>
>> commit 6553896666433e7efec589838b400a2a652b3ffa upstream.
>>
>> Some code pathes, especially the low level entry code, must be protected
>> against instrumentation for various reasons:
>>
>> - Low level entry code can be a fragile beast, especially on x86.
>>
>> - With NO_HZ_FULL RCU state needs to be established before using it.
>>
>> Having a dedicated section for such code allows to validate with tooling
>> that no unsafe functions are invoked.
>>
>> Add the .noinstr.text section and the noinstr attribute to mark
>> functions. noinstr implies notrace. Kprobes will gain a section check
>> later.
>>
>> Provide also a set of markers: instrumentation_begin()/end()
>>
>> These are used to mark code inside a noinstr function which calls
>> into regular instrumentable text section as safe.
>>
>> The instrumentation markers are only active when CONFIG_DEBUG_ENTRY is
>> enabled as the end marker emits a NOP to prevent the compiler from merging
>> the annotation points. This means the objtool verification requires a
>> kernel compiled with this option.
>>
>> Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
>> Reviewed-by: Alexandre Chartre <alexandre.chartre@oracle.com>
>> Acked-by: Peter Zijlstra <peterz@infradead.org>
>> Link: https://lkml.kernel.org/r/20200505134100.075416272@linutronix.de
>>
>> [Nicolas: context conflicts in:
>> arch/powerpc/kernel/vmlinux.lds.S
>> include/asm-generic/vmlinux.lds.h
>> include/linux/compiler.h
>> include/linux/compiler_types.h]
>> Signed-off-by: Nicolas Boichat <drinkcat@chromium.org>
>
> Did you build this on x86?
>
> I get the following build error:
>
> ld:./arch/x86/kernel/vmlinux.lds:20: syntax error
>
> And that line looks like:
>
> . = ALIGN(8); *(.text.hot .text.hot.*) *(.text .text.fixup) *(.text.unlikely .text.unlikely.*) *(.text.unknown .text.unknown.*) . = ALIGN(8); __noinstr_text_start = .; *(.__attribute__((noinline)) __attribute__((no_instrument_function)) __attribute((__section__(".noinstr.text"))).text) __noinstr_text_end = .; *(.text..refcount) *(.ref.text) *(.meminit.text*) *(.memexit.text*)
>
In the NOINSTR_TEXT macro, noinstr is expanded with the value of the noinstr
macro from linux/compiler_types.h while it shouldn't.
The problem is possibly that the noinstr macro is defined for assembly. Make
sure that the macro is not defined for assembly e.g.:
#ifndef __ASSEMBLY__
/* Section for code which can't be instrumented at all */
#define noinstr \
noinline notrace __attribute((__section__(".noinstr.text")))
#endif
alex.
^ permalink raw reply
* Re: [PATCH 00/36] [Set 4] Rid W=1 warnings in SCSI
From: Lee Jones @ 2021-03-19 8:10 UTC (permalink / raw)
To: Martin K. Petersen
Cc: Uma Krishnan, Brian Macy, Hannes Reinecke, Anil Ravindranath,
Tyrel Datwyler, willy, Le Moal, Dave Boutcher, Marvell,
Jirka Hanika, Linda Xie, C.L. Huang, target-devel, Drew Eckhardt,
Brian King, Christoph Hellwig, Alan Cox, linux-drivers,
Nicholas A. Bellinger, Linux GmbH, linux-scsi, Shaun Tancheff,
Subbu Seetharaman, Sathya Prakash, Doug Ledford,
Leonard N. Zubkoff, Ketan Mukadam, Dave Boutcher, Colin DeVilbiss,
Karan Tilak Kumar, Badari Pulavarty, Bryant G. Ly,
Douglas Gilbert, Jamie Lenehan, MPT-FusionLinux.pdl,
Richard Gooch, MPT-FusionLinux.pdl, Bas Vermeulen,
Artur Paszkiewicz, Michael Cyr, dc395x, Satish Kharat,
Suganath Prabu Subramani, James E.J. Bottomley, Luben Tuikov,
Ali Akcaagac, Kurt Garloff, Jitendra Bhivare, Brian King,
Hannes Reinecke, Erich Chen, David Chaw, Santiago Leon,
Matthew R. Ochs, Manoj N. Kumar, Sreekanth Reddy, Eric Youngdale,
Oliver Neukum, linux-kernel, Sesidhar Baddela, Alex Davis,
Torben Mathiasen, Paul Mackerras, FUJITA Tomonori, linuxppc-dev
In-Reply-To: <yq1zgyzolqx.fsf@ca-mkp.ca.oracle.com>
On Thu, 18 Mar 2021, Martin K. Petersen wrote:
>
> Lee,
>
> > This set is part of a larger effort attempting to clean-up W=1 kernel
> > builds, which are currently overwhelmingly riddled with niggly little
> > warnings.
>
> Applied to 5.13/scsi-staging, thanks! I fixed a few little things.
Thanks for your continued support Martin.
--
Lee Jones [李琼斯]
Senior Technical Lead - Developer Services
Linaro.org │ Open source software for Arm SoCs
Follow Linaro: Facebook | Twitter | Blog
^ permalink raw reply
* [PATCH] powerpc: epapr: A typo fix
From: Bhaskar Chowdhury @ 2021-03-20 21:39 UTC (permalink / raw)
To: mpe, benh, paulus, unixbhaskar, rdunlap, linuxppc-dev,
linux-kernel
s/parmeters/parameters/
Signed-off-by: Bhaskar Chowdhury <unixbhaskar@gmail.com>
---
arch/powerpc/include/asm/epapr_hcalls.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/include/asm/epapr_hcalls.h b/arch/powerpc/include/asm/epapr_hcalls.h
index c99ba08a408d..cdf3c6df5123 100644
--- a/arch/powerpc/include/asm/epapr_hcalls.h
+++ b/arch/powerpc/include/asm/epapr_hcalls.h
@@ -65,7 +65,7 @@
* but the gcc inline assembly syntax does not allow us to specify registers
* on the clobber list that are also on the input/output list. Therefore,
* the lists of clobbered registers depends on the number of register
- * parmeters ("+r" and "=r") passed to the hypercall.
+ * parameters ("+r" and "=r") passed to the hypercall.
*
* Each assembly block should use one of the HCALL_CLOBBERSx macros. As a
* general rule, 'x' is the number of parameters passed to the assembly
--
2.26.2
^ permalink raw reply related
* [PATCH] crypto: vmx: fix incorrect kernel-doc comment syntax in files
From: Aditya Srivastava @ 2021-03-20 20:25 UTC (permalink / raw)
To: leitao
Cc: rdunlap, herbert, corbet, nayna, linuxppc-dev, linux-kernel,
yashsri421, pfsmorigo, linux-crypto, lukas.bulwahn,
linux-kernel-mentees, davem, paulus
The opening comment mark '/**' is used for highlighting the beginning of
kernel-doc comments.
There are certain files in drivers/crypto/vmx, which follow this syntax,
but the content inside does not comply with kernel-doc.
Such lines were probably not meant for kernel-doc parsing, but are parsed
due to the presence of kernel-doc like comment syntax(i.e, '/**'), which
causes unexpected warnings from kernel-doc.
E.g., presence of kernel-doc like comment in the header line for
drivers/crypto/vmx/vmx.c causes this warning by kernel-doc:
"warning: expecting prototype for Routines supporting VMX instructions on the Power 8(). Prototype was for p8_init() instead"
Similarly for other files too.
Provide a simple fix by replacing such occurrences with general comment
format, i.e. '/*', to prevent kernel-doc from parsing it.
Signed-off-by: Aditya Srivastava <yashsri421@gmail.com>
---
* Applies perfectly on next-20210319
drivers/crypto/vmx/aes.c | 2 +-
drivers/crypto/vmx/aes_cbc.c | 2 +-
drivers/crypto/vmx/aes_ctr.c | 2 +-
drivers/crypto/vmx/aes_xts.c | 2 +-
drivers/crypto/vmx/ghash.c | 2 +-
drivers/crypto/vmx/vmx.c | 2 +-
6 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/drivers/crypto/vmx/aes.c b/drivers/crypto/vmx/aes.c
index d05c02baebcf..ec06189fbf99 100644
--- a/drivers/crypto/vmx/aes.c
+++ b/drivers/crypto/vmx/aes.c
@@ -1,5 +1,5 @@
// SPDX-License-Identifier: GPL-2.0-only
-/**
+/*
* AES routines supporting VMX instructions on the Power 8
*
* Copyright (C) 2015 International Business Machines Inc.
diff --git a/drivers/crypto/vmx/aes_cbc.c b/drivers/crypto/vmx/aes_cbc.c
index d88084447f1c..ed0debc7acb5 100644
--- a/drivers/crypto/vmx/aes_cbc.c
+++ b/drivers/crypto/vmx/aes_cbc.c
@@ -1,5 +1,5 @@
// SPDX-License-Identifier: GPL-2.0-only
-/**
+/*
* AES CBC routines supporting VMX instructions on the Power 8
*
* Copyright (C) 2015 International Business Machines Inc.
diff --git a/drivers/crypto/vmx/aes_ctr.c b/drivers/crypto/vmx/aes_ctr.c
index 79ba062ee1c1..9a3da8cd62f3 100644
--- a/drivers/crypto/vmx/aes_ctr.c
+++ b/drivers/crypto/vmx/aes_ctr.c
@@ -1,5 +1,5 @@
// SPDX-License-Identifier: GPL-2.0-only
-/**
+/*
* AES CTR routines supporting VMX instructions on the Power 8
*
* Copyright (C) 2015 International Business Machines Inc.
diff --git a/drivers/crypto/vmx/aes_xts.c b/drivers/crypto/vmx/aes_xts.c
index 9fee1b1532a4..dabbccb41550 100644
--- a/drivers/crypto/vmx/aes_xts.c
+++ b/drivers/crypto/vmx/aes_xts.c
@@ -1,5 +1,5 @@
// SPDX-License-Identifier: GPL-2.0-only
-/**
+/*
* AES XTS routines supporting VMX In-core instructions on Power 8
*
* Copyright (C) 2015 International Business Machines Inc.
diff --git a/drivers/crypto/vmx/ghash.c b/drivers/crypto/vmx/ghash.c
index 14807ac2e3b9..5bc5710a6de0 100644
--- a/drivers/crypto/vmx/ghash.c
+++ b/drivers/crypto/vmx/ghash.c
@@ -1,5 +1,5 @@
// SPDX-License-Identifier: GPL-2.0
-/**
+/*
* GHASH routines supporting VMX instructions on the Power 8
*
* Copyright (C) 2015, 2019 International Business Machines Inc.
diff --git a/drivers/crypto/vmx/vmx.c b/drivers/crypto/vmx/vmx.c
index a40d08e75fc0..7eb713cc87c8 100644
--- a/drivers/crypto/vmx/vmx.c
+++ b/drivers/crypto/vmx/vmx.c
@@ -1,5 +1,5 @@
// SPDX-License-Identifier: GPL-2.0-only
-/**
+/*
* Routines supporting VMX instructions on the Power 8
*
* Copyright (C) 2015 International Business Machines Inc.
--
2.17.1
^ permalink raw reply related
* Re: [PATCH 5/6] powerpc/mm/64s/hash: Add real-mode change_memory_range() for hash LPAR
From: Michael Ellerman @ 2021-03-20 13:04 UTC (permalink / raw)
To: Nicholas Piggin, linuxppc-dev; +Cc: aneesh.kumar
In-Reply-To: <1613084139.rsms9jxmax.astroid@bobo.none>
Nicholas Piggin <npiggin@gmail.com> writes:
> Excerpts from Michael Ellerman's message of February 11, 2021 11:51 pm:
...
>> diff --git a/arch/powerpc/mm/book3s64/hash_pgtable.c b/arch/powerpc/mm/book3s64/hash_pgtable.c
>> index 3663d3cdffac..01de985df2c4 100644
>> --- a/arch/powerpc/mm/book3s64/hash_pgtable.c
>> +++ b/arch/powerpc/mm/book3s64/hash_pgtable.c
>> @@ -414,6 +428,73 @@ static void change_memory_range(unsigned long start, unsigned long end,
>> mmu_kernel_ssize);
>> }
>>
>> +static int notrace chmem_secondary_loop(struct change_memory_parms *parms)
>> +{
>> + unsigned long msr, tmp, flags;
>> + int *p;
>> +
>> + p = &parms->cpu_counter.counter;
>> +
>> + local_irq_save(flags);
>> + __hard_EE_RI_disable();
>> +
>> + asm volatile (
>> + // Switch to real mode and leave interrupts off
>> + "mfmsr %[msr] ;"
>> + "li %[tmp], %[MSR_IR_DR] ;"
>> + "andc %[tmp], %[msr], %[tmp] ;"
>> + "mtmsrd %[tmp] ;"
>> +
>> + // Tell the master we are in real mode
>> + "1: "
>> + "lwarx %[tmp], 0, %[p] ;"
>> + "addic %[tmp], %[tmp], -1 ;"
>> + "stwcx. %[tmp], 0, %[p] ;"
>> + "bne- 1b ;"
>> +
>> + // Spin until the counter goes to zero
>> + "2: ;"
>> + "lwz %[tmp], 0(%[p]) ;"
>> + "cmpwi %[tmp], 0 ;"
>> + "bne- 2b ;"
>> +
>> + // Switch back to virtual mode
>> + "mtmsrd %[msr] ;"
>> +
>> + : // outputs
>> + [msr] "=&r" (msr), [tmp] "=&b" (tmp), "+m" (*p)
>> + : // inputs
>> + [p] "b" (p), [MSR_IR_DR] "i" (MSR_IR | MSR_DR)
>> + : // clobbers
>> + "cc", "xer"
>> + );
>> +
>> + local_irq_restore(flags);
>
> Hmm. __hard_EE_RI_disable won't get restored by this because it doesn't
> set the HARD_DIS flag. Also we don't want RI disabled here because
> tracing will get called first (which might take SLB or HPTE fault).
Thanks for noticing. I originally wrote hard_irq_disable() but then
thought disabling RI also would be good.
> But it's also slightly rude to ever enable EE under an irq soft mask,
> because you don't know if it had been disabled by the masked interrupt
> handler. It's not strictly a problem AFAIK because the interrupt would
> just get masked again, but if we try to maintain a good pattern would
> be good. Hmm that means we should add a check for irqs soft masked in
> __hard_irq_enable(), I'm not sure if all existing users would follow
> this rule.
>
> Might be better to call hard_irq_disable(); after the local_irq_save();
> and then clear and reset RI inside that region (could just do it at the
> same time as disabling MMU).
Thinking about it more, there's no real reason to disable RI.
We should be able to return from an interrupt in there, it's just that
if we do take one we'll probably die before we get a chance to return
because the mapping of text will be missing.
So disabling RI doesn't really gain us anything I don't think.
cheers
^ permalink raw reply
* [PATCH v7] powerpc/irq: Inline call_do_irq() and call_do_softirq()
From: Michael Ellerman @ 2021-03-20 12:22 UTC (permalink / raw)
To: linuxppc-dev
From: Christophe Leroy <christophe.leroy@csgroup.eu>
call_do_irq() and call_do_softirq() are simple enough to be
worth inlining.
Inlining them avoids an mflr/mtlr pair plus a save/reload on stack. It
also allows GCC to keep the saved ksp_limit in an nonvolatile reg.
This is inspired from S390 arch. Several other arches do more or
less the same. The way sparc arch does seems odd thought.
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
---
v2: no change.
v3: no change.
v4:
- comment reminding the purpose of the inline asm block.
- added r2 as clobbered reg
v5:
- Limiting the change to PPC32 for now.
- removed r2 from the clobbered regs list (on PPC32 r2 points to current all the time)
- Removed patch 1 and merged ksp_limit handling in here.
v6:
- Rebase on top of merge-test (ca6e327fefb2).
- Remove the ksp_limit stuff as it's doesn't exist anymore.
v7:
mpe:
- Enable for 64-bit too. This all in-kernel code calling in-kernel
code, and must use the kernel TOC.
- Use named parameters for the inline asm.
- Reformat inline asm.
- Mark as always_inline.
- Drop unused ret from call_do_softirq(), add r3 as clobbered.
---
arch/powerpc/include/asm/irq.h | 2 --
arch/powerpc/kernel/irq.c | 41 ++++++++++++++++++++++++++++++++++
arch/powerpc/kernel/misc_32.S | 25 ---------------------
arch/powerpc/kernel/misc_64.S | 22 ------------------
4 files changed, 41 insertions(+), 49 deletions(-)
diff --git a/arch/powerpc/include/asm/irq.h b/arch/powerpc/include/asm/irq.h
index f3f264e441a7..b2bd58830430 100644
--- a/arch/powerpc/include/asm/irq.h
+++ b/arch/powerpc/include/asm/irq.h
@@ -53,8 +53,6 @@ extern void *mcheckirq_ctx[NR_CPUS];
extern void *hardirq_ctx[NR_CPUS];
extern void *softirq_ctx[NR_CPUS];
-void call_do_softirq(void *sp);
-void call_do_irq(struct pt_regs *regs, void *sp);
extern void do_IRQ(struct pt_regs *regs);
extern void __init init_IRQ(void);
extern void __do_irq(struct pt_regs *regs);
diff --git a/arch/powerpc/kernel/irq.c b/arch/powerpc/kernel/irq.c
index 5b72abbff96c..260effc0a435 100644
--- a/arch/powerpc/kernel/irq.c
+++ b/arch/powerpc/kernel/irq.c
@@ -667,6 +667,47 @@ static inline void check_stack_overflow(void)
}
}
+static __always_inline void call_do_softirq(const void *sp)
+{
+ /* Temporarily switch r1 to sp, call __do_softirq() then restore r1. */
+ asm volatile (
+ PPC_STLU " %%r1, %[offset](%[sp]) ;"
+ "mr %%r1, %[sp] ;"
+ "bl %[callee] ;"
+ PPC_LL " %%r1, 0(%%r1) ;"
+ : // Outputs
+ : // Inputs
+ [sp] "b" (sp), [offset] "i" (THREAD_SIZE - STACK_FRAME_OVERHEAD),
+ [callee] "i" (__do_softirq)
+ : // Clobbers
+ "lr", "xer", "ctr", "memory", "cr0", "cr1", "cr5", "cr6",
+ "cr7", "r0", "r3", "r4", "r5", "r6", "r7", "r8", "r9", "r10",
+ "r11", "r12"
+ );
+}
+
+static __always_inline void call_do_irq(struct pt_regs *regs, void *sp)
+{
+ register unsigned long r3 asm("r3") = (unsigned long)regs;
+
+ /* Temporarily switch r1 to sp, call __do_irq() then restore r1. */
+ asm volatile (
+ PPC_STLU " %%r1, %[offset](%[sp]) ;"
+ "mr %%r1, %[sp] ;"
+ "bl %[callee] ;"
+ PPC_LL " %%r1, 0(%%r1) ;"
+ : // Outputs
+ "+r" (r3)
+ : // Inputs
+ [sp] "b" (sp), [offset] "i" (THREAD_SIZE - STACK_FRAME_OVERHEAD),
+ [callee] "i" (__do_irq)
+ : // Clobbers
+ "lr", "xer", "ctr", "memory", "cr0", "cr1", "cr5", "cr6",
+ "cr7", "r0", "r4", "r5", "r6", "r7", "r8", "r9", "r10",
+ "r11", "r12"
+ );
+}
+
void __do_irq(struct pt_regs *regs)
{
unsigned int irq;
diff --git a/arch/powerpc/kernel/misc_32.S b/arch/powerpc/kernel/misc_32.S
index acc410043b96..6a076bef2932 100644
--- a/arch/powerpc/kernel/misc_32.S
+++ b/arch/powerpc/kernel/misc_32.S
@@ -27,31 +27,6 @@
.text
-_GLOBAL(call_do_softirq)
- mflr r0
- stw r0,4(r1)
- stwu r1,THREAD_SIZE-STACK_FRAME_OVERHEAD(r3)
- mr r1,r3
- bl __do_softirq
- lwz r1,0(r1)
- lwz r0,4(r1)
- mtlr r0
- blr
-
-/*
- * void call_do_irq(struct pt_regs *regs, void *sp);
- */
-_GLOBAL(call_do_irq)
- mflr r0
- stw r0,4(r1)
- stwu r1,THREAD_SIZE-STACK_FRAME_OVERHEAD(r4)
- mr r1,r4
- bl __do_irq
- lwz r1,0(r1)
- lwz r0,4(r1)
- mtlr r0
- blr
-
/*
* This returns the high 64 bits of the product of two 64-bit numbers.
*/
diff --git a/arch/powerpc/kernel/misc_64.S b/arch/powerpc/kernel/misc_64.S
index 070465825c21..4b761a18a74d 100644
--- a/arch/powerpc/kernel/misc_64.S
+++ b/arch/powerpc/kernel/misc_64.S
@@ -27,28 +27,6 @@
.text
-_GLOBAL(call_do_softirq)
- mflr r0
- std r0,16(r1)
- stdu r1,THREAD_SIZE-STACK_FRAME_OVERHEAD(r3)
- mr r1,r3
- bl __do_softirq
- ld r1,0(r1)
- ld r0,16(r1)
- mtlr r0
- blr
-
-_GLOBAL(call_do_irq)
- mflr r0
- std r0,16(r1)
- stdu r1,THREAD_SIZE-STACK_FRAME_OVERHEAD(r4)
- mr r1,r4
- bl __do_irq
- ld r1,0(r1)
- ld r0,16(r1)
- mtlr r0
- blr
-
_GLOBAL(__bswapdi2)
EXPORT_SYMBOL(__bswapdi2)
srdi r8,r3,32
--
2.25.1
^ permalink raw reply related
* Re: [for-stable-4.19 PATCH v2 0/2] Backport patches to fix KASAN+LKDTM with recent clang on ARM64
From: Greg Kroah-Hartman @ 2021-03-20 10:57 UTC (permalink / raw)
To: Nicolas Boichat
Cc: Alexandre Chartre, Peter Zijlstra, Christopher Li,
Masahiro Yamada, Paul Mackerras, groeck, linux-arch,
clang-built-linux, linux-sparse, Naveen N. Rao, Kees Cook,
Arnd Bergmann, linux-kbuild, Nicholas Piggin, Thomas Gleixner,
Daniel Axtens, Michal Marek, linux-kernel, stable, linuxppc-dev
In-Reply-To: <20210320041626.885806-1-drinkcat@chromium.org>
On Sat, Mar 20, 2021 at 12:16:24PM +0800, Nicolas Boichat wrote:
> Backport 2 patches that are required to make KASAN+LKDTM work
> with recent clang (patch 2/2 has a complete description).
> Tested on our chromeos-4.19 branch.
> Also compile tested on x86-64 and arm64 with gcc this time
> around.
>
> Patch 1/2 adds a guard around noinstr that matches upstream,
> to prevent a build issue, and has some minor context conflicts.
> Patch 2/2 is a clean backport.
>
> These patches have been merged to 5.4 stable already. We might
> need to backport to older stable branches, but this is what I
> could test for now.
Ok, trying this again, let's see what breaks :)
thanks,
greg k-h
^ permalink raw reply
* Patch "vmlinux.lds.h: Create section for protection against instrumentation" has been added to the 4.19-stable tree
From: gregkh @ 2021-03-20 10:56 UTC (permalink / raw)
To: alexandre.chartre, arnd, benh, dja, drinkcat, gregkh, groeck,
linuxppc-dev, michal.lkml, mpe, naveen.n.rao, npiggin, paulus,
peterz, sparse, tglx, yamada.masahiro
Cc: stable-commits
In-Reply-To: <20210320121614.for-stable-4.19.v2.1.I222f801866f71be9f7d85e5b10665cd4506d78ec@changeid>
This is a note to let you know that I've just added the patch titled
vmlinux.lds.h: Create section for protection against instrumentation
to the 4.19-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
vmlinux.lds.h-create-section-for-protection-against-instrumentation.patch
and it can be found in the queue-4.19 subdirectory.
If you, or anyone else, feels it should not be added to the stable tree,
please let <stable@vger.kernel.org> know about it.
From foo@baz Sat Mar 20 11:54:47 AM CET 2021
From: Nicolas Boichat <drinkcat@chromium.org>
Date: Sat, 20 Mar 2021 12:16:25 +0800
Subject: vmlinux.lds.h: Create section for protection against instrumentation
To: stable@vger.kernel.org
Cc: groeck@chromium.org, Thomas Gleixner <tglx@linutronix.de>, Alexandre Chartre <alexandre.chartre@oracle.com>, Peter Zijlstra <peterz@infradead.org>, Nicolas Boichat <drinkcat@chromium.org>, Arnd Bergmann <arnd@arndb.de>, Benjamin Herrenschmidt <benh@kernel.crashing.org>, Christopher Li <sparse@chrisli.org>, Daniel Axtens <dja@axtens.net>, Greg Kroah-Hartman <gregkh@linuxfoundation.org>, Masahiro Yamada <yamada.masahiro@socionext.com>, Michael Ellerman <mpe@ellerman.id.au>, Michal Marek <michal.lkml@markovi.net>, "Naveen N. Rao" <naveen.n.rao@linux.vnet.ibm.com>, Nicholas Piggin <npiggin@gmail.com>, Paul Mackerras <paulus@samba.org>, linux-arch@vger.kernel.org, linux-kbuild@vger.kernel.org, linux-kernel@vger.kernel.org, linux-sparse@vger.kernel.org, linuxppc-dev@lists.ozlabs.org
Message-ID: <20210320121614.for-stable-4.19.v2.1.I222f801866f71be9f7d85e5b10665cd4506d78ec@changeid>
From: Nicolas Boichat <drinkcat@chromium.org>
From: Thomas Gleixner <tglx@linutronix.de>
commit 6553896666433e7efec589838b400a2a652b3ffa upstream.
Some code pathes, especially the low level entry code, must be protected
against instrumentation for various reasons:
- Low level entry code can be a fragile beast, especially on x86.
- With NO_HZ_FULL RCU state needs to be established before using it.
Having a dedicated section for such code allows to validate with tooling
that no unsafe functions are invoked.
Add the .noinstr.text section and the noinstr attribute to mark
functions. noinstr implies notrace. Kprobes will gain a section check
later.
Provide also a set of markers: instrumentation_begin()/end()
These are used to mark code inside a noinstr function which calls
into regular instrumentable text section as safe.
The instrumentation markers are only active when CONFIG_DEBUG_ENTRY is
enabled as the end marker emits a NOP to prevent the compiler from merging
the annotation points. This means the objtool verification requires a
kernel compiled with this option.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Alexandre Chartre <alexandre.chartre@oracle.com>
Acked-by: Peter Zijlstra <peterz@infradead.org>
Link: https://lkml.kernel.org/r/20200505134100.075416272@linutronix.de
[Nicolas:
Guard noinstr macro in include/linux/compiler_types.h in __KERNEL__
&& !__ASSEMBLY__, otherwise noinstr is expanded in the linker
script construct.
Upstream does not have this problem as many macros were moved by
commit 71391bdd2e9a ("include/linux/compiler_types.h: don't pollute
userspace with macro definitions"). We take the minimal approach here
and just guard the new macro.
Minor context conflicts in:
arch/powerpc/kernel/vmlinux.lds.S
include/asm-generic/vmlinux.lds.h
include/linux/compiler.h]
Signed-off-by: Nicolas Boichat <drinkcat@chromium.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
Technically guarding with !__ASSEMBLY__ should be enough, but
there seems to be no reason to expose this new macro when
!__KERNEL__, so let's just match what upstream does.
Changes in v2:
- Guard noinstr macro by __KERNEL__ && !__ASSEMBLY__ to prevent
expansion in linker script and match upstream.
arch/powerpc/kernel/vmlinux.lds.S | 1
include/asm-generic/sections.h | 3 ++
include/asm-generic/vmlinux.lds.h | 10 +++++++
include/linux/compiler.h | 54 ++++++++++++++++++++++++++++++++++++++
include/linux/compiler_types.h | 6 ++++
scripts/mod/modpost.c | 2 -
6 files changed, 75 insertions(+), 1 deletion(-)
--- a/arch/powerpc/kernel/vmlinux.lds.S
+++ b/arch/powerpc/kernel/vmlinux.lds.S
@@ -99,6 +99,7 @@ SECTIONS
#endif
/* careful! __ftr_alt_* sections need to be close to .text */
*(.text.hot TEXT_MAIN .text.fixup .text.unlikely .fixup __ftr_alt_* .ref.text);
+ NOINSTR_TEXT
SCHED_TEXT
CPUIDLE_TEXT
LOCK_TEXT
--- a/include/asm-generic/sections.h
+++ b/include/asm-generic/sections.h
@@ -53,6 +53,9 @@ extern char __ctors_start[], __ctors_end
/* Start and end of .opd section - used for function descriptors. */
extern char __start_opd[], __end_opd[];
+/* Start and end of instrumentation protected text section */
+extern char __noinstr_text_start[], __noinstr_text_end[];
+
extern __visible const void __nosave_begin, __nosave_end;
/* Function descriptor handling (if any). Override in asm/sections.h */
--- a/include/asm-generic/vmlinux.lds.h
+++ b/include/asm-generic/vmlinux.lds.h
@@ -483,6 +483,15 @@
}
/*
+ * Non-instrumentable text section
+ */
+#define NOINSTR_TEXT \
+ ALIGN_FUNCTION(); \
+ __noinstr_text_start = .; \
+ *(.noinstr.text) \
+ __noinstr_text_end = .;
+
+/*
* .text section. Map to function alignment to avoid address changes
* during second ld run in second ld pass when generating System.map
*
@@ -496,6 +505,7 @@
*(TEXT_MAIN .text.fixup) \
*(.text.unlikely .text.unlikely.*) \
*(.text.unknown .text.unknown.*) \
+ NOINSTR_TEXT \
*(.text..refcount) \
*(.ref.text) \
MEM_KEEP(init.text*) \
--- a/include/linux/compiler.h
+++ b/include/linux/compiler.h
@@ -129,11 +129,65 @@ void ftrace_likely_update(struct ftrace_
".pushsection .discard.unreachable\n\t" \
".long 999b - .\n\t" \
".popsection\n\t"
+
+#ifdef CONFIG_DEBUG_ENTRY
+/* Begin/end of an instrumentation safe region */
+#define instrumentation_begin() ({ \
+ asm volatile("%c0:\n\t" \
+ ".pushsection .discard.instr_begin\n\t" \
+ ".long %c0b - .\n\t" \
+ ".popsection\n\t" : : "i" (__COUNTER__)); \
+})
+
+/*
+ * Because instrumentation_{begin,end}() can nest, objtool validation considers
+ * _begin() a +1 and _end() a -1 and computes a sum over the instructions.
+ * When the value is greater than 0, we consider instrumentation allowed.
+ *
+ * There is a problem with code like:
+ *
+ * noinstr void foo()
+ * {
+ * instrumentation_begin();
+ * ...
+ * if (cond) {
+ * instrumentation_begin();
+ * ...
+ * instrumentation_end();
+ * }
+ * bar();
+ * instrumentation_end();
+ * }
+ *
+ * If instrumentation_end() would be an empty label, like all the other
+ * annotations, the inner _end(), which is at the end of a conditional block,
+ * would land on the instruction after the block.
+ *
+ * If we then consider the sum of the !cond path, we'll see that the call to
+ * bar() is with a 0-value, even though, we meant it to happen with a positive
+ * value.
+ *
+ * To avoid this, have _end() be a NOP instruction, this ensures it will be
+ * part of the condition block and does not escape.
+ */
+#define instrumentation_end() ({ \
+ asm volatile("%c0: nop\n\t" \
+ ".pushsection .discard.instr_end\n\t" \
+ ".long %c0b - .\n\t" \
+ ".popsection\n\t" : : "i" (__COUNTER__)); \
+})
+#endif /* CONFIG_DEBUG_ENTRY */
+
#else
#define annotate_reachable()
#define annotate_unreachable()
#endif
+#ifndef instrumentation_begin
+#define instrumentation_begin() do { } while(0)
+#define instrumentation_end() do { } while(0)
+#endif
+
#ifndef ASM_UNREACHABLE
# define ASM_UNREACHABLE
#endif
--- a/include/linux/compiler_types.h
+++ b/include/linux/compiler_types.h
@@ -234,6 +234,12 @@ struct ftrace_likely_data {
#define notrace __attribute__((no_instrument_function))
#endif
+#if defined(__KERNEL__) && !defined(__ASSEMBLY__)
+/* Section for code which can't be instrumented at all */
+#define noinstr \
+ noinline notrace __attribute((__section__(".noinstr.text")))
+#endif
+
/*
* it doesn't make sense on ARM (currently the only user of __naked)
* to trace naked functions because then mcount is called without
--- a/scripts/mod/modpost.c
+++ b/scripts/mod/modpost.c
@@ -895,7 +895,7 @@ static void check_section(const char *mo
#define DATA_SECTIONS ".data", ".data.rel"
#define TEXT_SECTIONS ".text", ".text.unlikely", ".sched.text", \
- ".kprobes.text", ".cpuidle.text"
+ ".kprobes.text", ".cpuidle.text", ".noinstr.text"
#define OTHER_TEXT_SECTIONS ".ref.text", ".head.text", ".spinlock.text", \
".fixup", ".entry.text", ".exception.text", ".text.*", \
".coldtext"
Patches currently in stable-queue which might be from drinkcat@chromium.org are
queue-4.19/vmlinux.lds.h-create-section-for-protection-against-instrumentation.patch
queue-4.19/lkdtm-don-t-move-ctors-to-.rodata.patch
^ permalink raw reply
* Re: [PATCH v3 14/41] KVM: PPC: Book3S 64: move bad_host_intr check to HV handler
From: Alexey Kardashevskiy @ 2021-03-20 9:07 UTC (permalink / raw)
To: Nicholas Piggin, kvm-ppc; +Cc: linuxppc-dev
In-Reply-To: <20210305150638.2675513-15-npiggin@gmail.com>
On 06/03/2021 02:06, Nicholas Piggin wrote:
> This is not used by PR KVM.
>
> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Reviewed-by: Alexey Kardashevskiy <aik@ozlabs.ru>
a small tote - it probably makes sense to move this before 09/41 as this
one removes what 09/41 added to book3s_64_entry.S. Thanks,
> ---
> arch/powerpc/kvm/book3s_64_entry.S | 3 ---
> arch/powerpc/kvm/book3s_hv_rmhandlers.S | 4 +++-
> arch/powerpc/kvm/book3s_segment.S | 7 +++++++
> 3 files changed, 10 insertions(+), 4 deletions(-)
>
> diff --git a/arch/powerpc/kvm/book3s_64_entry.S b/arch/powerpc/kvm/book3s_64_entry.S
> index d06e81842368..7a6b060ceed8 100644
> --- a/arch/powerpc/kvm/book3s_64_entry.S
> +++ b/arch/powerpc/kvm/book3s_64_entry.S
> @@ -78,11 +78,8 @@ do_kvm_interrupt:
> beq- .Lmaybe_skip
> .Lno_skip:
> #ifdef CONFIG_KVM_BOOK3S_HV_POSSIBLE
> - cmpwi r9,KVM_GUEST_MODE_HOST_HV
> - beq kvmppc_bad_host_intr
> #ifdef CONFIG_KVM_BOOK3S_PR_POSSIBLE
> cmpwi r9,KVM_GUEST_MODE_GUEST
> - ld r9,HSTATE_SCRATCH2(r13)
> beq kvmppc_interrupt_pr
> #endif
> b kvmppc_interrupt_hv
> diff --git a/arch/powerpc/kvm/book3s_hv_rmhandlers.S b/arch/powerpc/kvm/book3s_hv_rmhandlers.S
> index f976efb7e4a9..75405ef53238 100644
> --- a/arch/powerpc/kvm/book3s_hv_rmhandlers.S
> +++ b/arch/powerpc/kvm/book3s_hv_rmhandlers.S
> @@ -1265,6 +1265,7 @@ hdec_soon:
> kvmppc_interrupt_hv:
> /*
> * Register contents:
> + * R9 = HSTATE_IN_GUEST
> * R12 = (guest CR << 32) | interrupt vector
> * R13 = PACA
> * guest R12 saved in shadow VCPU SCRATCH0
> @@ -1272,6 +1273,8 @@ kvmppc_interrupt_hv:
> * guest R9 saved in HSTATE_SCRATCH2
> */
> /* We're now back in the host but in guest MMU context */
> + cmpwi r9,KVM_GUEST_MODE_HOST_HV
> + beq kvmppc_bad_host_intr
> li r9, KVM_GUEST_MODE_HOST_HV
> stb r9, HSTATE_IN_GUEST(r13)
>
> @@ -3272,7 +3275,6 @@ END_FTR_SECTION_IFCLR(CPU_FTR_P9_TM_HV_ASSIST)
> * cfar is saved in HSTATE_CFAR(r13)
> * ppr is saved in HSTATE_PPR(r13)
> */
> -.global kvmppc_bad_host_intr
> kvmppc_bad_host_intr:
> /*
> * Switch to the emergency stack, but start half-way down in
> diff --git a/arch/powerpc/kvm/book3s_segment.S b/arch/powerpc/kvm/book3s_segment.S
> index 1f492aa4c8d6..ef1d88b869bf 100644
> --- a/arch/powerpc/kvm/book3s_segment.S
> +++ b/arch/powerpc/kvm/book3s_segment.S
> @@ -167,8 +167,15 @@ kvmppc_interrupt_pr:
> * R12 = (guest CR << 32) | exit handler id
> * R13 = PACA
> * HSTATE.SCRATCH0 = guest R12
> + *
> + * If HV is possible, additionally:
> + * R9 = HSTATE_IN_GUEST
> + * HSTATE.SCRATCH2 = guest R9
> */
> #ifdef CONFIG_PPC64
> +#ifdef CONFIG_KVM_BOOK3S_HV_POSSIBLE
> + ld r9,HSTATE_SCRATCH2(r13)
> +#endif
> /* Match 32-bit entry */
> rotldi r12, r12, 32 /* Flip R12 halves for stw */
> stw r12, HSTATE_SCRATCH1(r13) /* CR is now in the low half */
>
--
Alexey
^ permalink raw reply
* Re: [PATCH v3 13/41] KVM: PPC: Book3S 64: Move interrupt early register setup to KVM
From: Alexey Kardashevskiy @ 2021-03-20 7:19 UTC (permalink / raw)
To: Nicholas Piggin, kvm-ppc; +Cc: linuxppc-dev
In-Reply-To: <20210305150638.2675513-14-npiggin@gmail.com>
On 06/03/2021 02:06, Nicholas Piggin wrote:
> Like the earlier patch for hcalls, KVM interrupt entry requires a
> different calling convention than the Linux interrupt handlers
> set up. Move the code that converts from one to the other into KVM.
>
> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
> ---
> arch/powerpc/kernel/exceptions-64s.S | 131 +++++----------------------
> arch/powerpc/kvm/book3s_64_entry.S | 34 ++++++-
> 2 files changed, 55 insertions(+), 110 deletions(-)
>
> diff --git a/arch/powerpc/kernel/exceptions-64s.S b/arch/powerpc/kernel/exceptions-64s.S
> index b7092ba87da8..b4eab5084964 100644
> --- a/arch/powerpc/kernel/exceptions-64s.S
> +++ b/arch/powerpc/kernel/exceptions-64s.S
> @@ -187,7 +187,6 @@ do_define_int n
> .endif
> .endm
>
> -#ifdef CONFIG_KVM_BOOK3S_64_HANDLER
> /*
> * All interrupts which set HSRR registers, as well as SRESET and MCE and
> * syscall when invoked with "sc 1" switch to MSR[HV]=1 (HVMODE) to be taken,
> @@ -220,54 +219,25 @@ do_define_int n
> * to KVM to handle.
> */
>
> -.macro KVMTEST name
> +.macro KVMTEST name handler
> +#ifdef CONFIG_KVM_BOOK3S_64_HANDLER
> lbz r10,HSTATE_IN_GUEST(r13)
> cmpwi r10,0
> - bne \name\()_kvm
> -.endm
> -
> -.macro GEN_KVM name
> - .balign IFETCH_ALIGN_BYTES
> -\name\()_kvm:
> -
> -BEGIN_FTR_SECTION
> - ld r10,IAREA+EX_CFAR(r13)
> - std r10,HSTATE_CFAR(r13)
> -END_FTR_SECTION_IFSET(CPU_FTR_CFAR)
> -
> - ld r10,IAREA+EX_CTR(r13)
> - mtctr r10
> -BEGIN_FTR_SECTION
> - ld r10,IAREA+EX_PPR(r13)
> - std r10,HSTATE_PPR(r13)
> -END_FTR_SECTION_IFSET(CPU_FTR_HAS_PPR)
> - ld r11,IAREA+EX_R11(r13)
> - ld r12,IAREA+EX_R12(r13)
> - std r12,HSTATE_SCRATCH0(r13)
> - sldi r12,r9,32
> - ld r9,IAREA+EX_R9(r13)
> - ld r10,IAREA+EX_R10(r13)
> /* HSRR variants have the 0x2 bit added to their trap number */
> .if IHSRR_IF_HVMODE
> BEGIN_FTR_SECTION
> - ori r12,r12,(IVEC + 0x2)
> + li r10,(IVEC + 0x2)
> FTR_SECTION_ELSE
> - ori r12,r12,(IVEC)
> + li r10,(IVEC)
> ALT_FTR_SECTION_END_IFSET(CPU_FTR_HVMODE | CPU_FTR_ARCH_206)
> .elseif IHSRR
> - ori r12,r12,(IVEC+ 0x2)
> + li r10,(IVEC + 0x2)
> .else
> - ori r12,r12,(IVEC)
> + li r10,(IVEC)
> .endif
> - b kvmppc_interrupt
> -.endm
> -
> -#else
> -.macro KVMTEST name
> -.endm
> -.macro GEN_KVM name
> -.endm
> + bne \handler
> #endif
> +.endm
>
> /*
> * This is the BOOK3S interrupt entry code macro.
> @@ -409,7 +379,7 @@ END_FTR_SECTION_IFSET(CPU_FTR_CFAR)
> DEFINE_FIXED_SYMBOL(\name\()_common_real)
> \name\()_common_real:
> .if IKVM_REAL
> - KVMTEST \name
> + KVMTEST \name kvm_interrupt
> .endif
>
> ld r10,PACAKMSR(r13) /* get MSR value for kernel */
> @@ -432,7 +402,7 @@ DEFINE_FIXED_SYMBOL(\name\()_common_real)
> DEFINE_FIXED_SYMBOL(\name\()_common_virt)
> \name\()_common_virt:
> .if IKVM_VIRT
> - KVMTEST \name
> + KVMTEST \name kvm_interrupt
> 1:
> .endif
> .endif /* IVIRT */
> @@ -446,7 +416,7 @@ DEFINE_FIXED_SYMBOL(\name\()_common_virt)
> DEFINE_FIXED_SYMBOL(\name\()_common_real)
> \name\()_common_real:
> .if IKVM_REAL
> - KVMTEST \name
> + KVMTEST \name kvm_interrupt
> .endif
> .endm
>
> @@ -967,8 +937,6 @@ EXC_COMMON_BEGIN(system_reset_common)
> EXCEPTION_RESTORE_REGS
> RFI_TO_USER_OR_KERNEL
>
> - GEN_KVM system_reset
> -
>
> /**
> * Interrupt 0x200 - Machine Check Interrupt (MCE).
> @@ -1132,7 +1100,7 @@ END_FTR_SECTION_IFSET(CPU_FTR_HVMODE | CPU_FTR_ARCH_206)
> /*
> * Check if we are coming from guest. If yes, then run the normal
> * exception handler which will take the
> - * machine_check_kvm->kvmppc_interrupt branch to deliver the MC event
> + * machine_check_kvm->kvm_interrupt branch to deliver the MC event
> * to guest.
> */
> lbz r11,HSTATE_IN_GUEST(r13)
> @@ -1203,8 +1171,6 @@ EXC_COMMON_BEGIN(machine_check_common)
> bl machine_check_exception
> b interrupt_return
>
> - GEN_KVM machine_check
> -
>
> #ifdef CONFIG_PPC_P7_NAP
> /*
> @@ -1339,8 +1305,6 @@ ALT_MMU_FTR_SECTION_END_IFCLR(MMU_FTR_TYPE_RADIX)
> REST_NVGPRS(r1)
> b interrupt_return
>
> - GEN_KVM data_access
> -
>
> /**
> * Interrupt 0x380 - Data Segment Interrupt (DSLB).
> @@ -1390,8 +1354,6 @@ ALT_MMU_FTR_SECTION_END_IFCLR(MMU_FTR_TYPE_RADIX)
> bl do_bad_slb_fault
> b interrupt_return
>
> - GEN_KVM data_access_slb
> -
>
> /**
> * Interrupt 0x400 - Instruction Storage Interrupt (ISI).
> @@ -1428,8 +1390,6 @@ MMU_FTR_SECTION_ELSE
> ALT_MMU_FTR_SECTION_END_IFCLR(MMU_FTR_TYPE_RADIX)
> b interrupt_return
>
> - GEN_KVM instruction_access
> -
>
> /**
> * Interrupt 0x480 - Instruction Segment Interrupt (ISLB).
> @@ -1474,8 +1434,6 @@ ALT_MMU_FTR_SECTION_END_IFCLR(MMU_FTR_TYPE_RADIX)
> bl do_bad_slb_fault
> b interrupt_return
>
> - GEN_KVM instruction_access_slb
> -
>
> /**
> * Interrupt 0x500 - External Interrupt.
> @@ -1521,8 +1479,6 @@ EXC_COMMON_BEGIN(hardware_interrupt_common)
> bl do_IRQ
> b interrupt_return
>
> - GEN_KVM hardware_interrupt
> -
>
> /**
> * Interrupt 0x600 - Alignment Interrupt
> @@ -1550,8 +1506,6 @@ EXC_COMMON_BEGIN(alignment_common)
> REST_NVGPRS(r1) /* instruction emulation may change GPRs */
> b interrupt_return
>
> - GEN_KVM alignment
> -
>
> /**
> * Interrupt 0x700 - Program Interrupt (program check).
> @@ -1659,8 +1613,6 @@ EXC_COMMON_BEGIN(program_check_common)
> REST_NVGPRS(r1) /* instruction emulation may change GPRs */
> b interrupt_return
>
> - GEN_KVM program_check
> -
>
> /*
> * Interrupt 0x800 - Floating-Point Unavailable Interrupt.
> @@ -1710,8 +1662,6 @@ END_FTR_SECTION_IFSET(CPU_FTR_TM)
> b interrupt_return
> #endif
>
> - GEN_KVM fp_unavailable
> -
>
> /**
> * Interrupt 0x900 - Decrementer Interrupt.
> @@ -1751,8 +1701,6 @@ EXC_COMMON_BEGIN(decrementer_common)
> bl timer_interrupt
> b interrupt_return
>
> - GEN_KVM decrementer
> -
>
> /**
> * Interrupt 0x980 - Hypervisor Decrementer Interrupt.
> @@ -1798,8 +1746,6 @@ EXC_COMMON_BEGIN(hdecrementer_common)
> ld r13,PACA_EXGEN+EX_R13(r13)
> HRFI_TO_KERNEL
>
> - GEN_KVM hdecrementer
> -
>
> /**
> * Interrupt 0xa00 - Directed Privileged Doorbell Interrupt.
> @@ -1840,8 +1786,6 @@ EXC_COMMON_BEGIN(doorbell_super_common)
> #endif
> b interrupt_return
>
> - GEN_KVM doorbell_super
> -
>
> EXC_REAL_NONE(0xb00, 0x100)
> EXC_VIRT_NONE(0x4b00, 0x100)
> @@ -1891,7 +1835,7 @@ INT_DEFINE_END(system_call)
> GET_PACA(r13)
> std r10,PACA_EXGEN+EX_R10(r13)
> INTERRUPT_TO_KERNEL
> - KVMTEST system_call /* uses r10, branch to system_call_kvm */
> + KVMTEST system_call kvm_hcall /* uses r10, branch to kvm_hcall */
> mfctr r9
> #else
> mr r9,r13
> @@ -1947,7 +1891,7 @@ EXC_VIRT_BEGIN(system_call, 0x4c00, 0x100)
> EXC_VIRT_END(system_call, 0x4c00, 0x100)
>
> #ifdef CONFIG_KVM_BOOK3S_64_HANDLER
> -TRAMP_REAL_BEGIN(system_call_kvm)
> +TRAMP_REAL_BEGIN(kvm_hcall)
> mfctr r10
> SET_SCRATCH0(r10) /* Save r13 in SCRATCH0 */
> #ifdef CONFIG_RELOCATABLE
> @@ -1987,8 +1931,6 @@ EXC_COMMON_BEGIN(single_step_common)
> bl single_step_exception
> b interrupt_return
>
> - GEN_KVM single_step
> -
>
> /**
> * Interrupt 0xe00 - Hypervisor Data Storage Interrupt (HDSI).
> @@ -2027,8 +1969,6 @@ MMU_FTR_SECTION_ELSE
> ALT_MMU_FTR_SECTION_END_IFSET(MMU_FTR_TYPE_RADIX)
> b interrupt_return
>
> - GEN_KVM h_data_storage
> -
>
> /**
> * Interrupt 0xe20 - Hypervisor Instruction Storage Interrupt (HISI).
> @@ -2054,8 +1994,6 @@ EXC_COMMON_BEGIN(h_instr_storage_common)
> bl unknown_exception
> b interrupt_return
>
> - GEN_KVM h_instr_storage
> -
>
> /**
> * Interrupt 0xe40 - Hypervisor Emulation Assistance Interrupt.
> @@ -2080,8 +2018,6 @@ EXC_COMMON_BEGIN(emulation_assist_common)
> REST_NVGPRS(r1) /* instruction emulation may change GPRs */
> b interrupt_return
>
> - GEN_KVM emulation_assist
> -
>
> /**
> * Interrupt 0xe60 - Hypervisor Maintenance Interrupt (HMI).
> @@ -2153,8 +2089,6 @@ EXC_COMMON_BEGIN(hmi_exception_early_common)
> EXCEPTION_RESTORE_REGS hsrr=1
> GEN_INT_ENTRY hmi_exception, virt=0
>
> - GEN_KVM hmi_exception_early
> -
> EXC_COMMON_BEGIN(hmi_exception_common)
> GEN_COMMON hmi_exception
> FINISH_NAP
> @@ -2162,8 +2096,6 @@ EXC_COMMON_BEGIN(hmi_exception_common)
> bl handle_hmi_exception
> b interrupt_return
>
> - GEN_KVM hmi_exception
> -
>
> /**
> * Interrupt 0xe80 - Directed Hypervisor Doorbell Interrupt.
> @@ -2195,8 +2127,6 @@ EXC_COMMON_BEGIN(h_doorbell_common)
> #endif
> b interrupt_return
>
> - GEN_KVM h_doorbell
> -
>
> /**
> * Interrupt 0xea0 - Hypervisor Virtualization Interrupt.
> @@ -2224,8 +2154,6 @@ EXC_COMMON_BEGIN(h_virt_irq_common)
> bl do_IRQ
> b interrupt_return
>
> - GEN_KVM h_virt_irq
> -
>
> EXC_REAL_NONE(0xec0, 0x20)
> EXC_VIRT_NONE(0x4ec0, 0x20)
> @@ -2270,8 +2198,6 @@ EXC_COMMON_BEGIN(performance_monitor_common)
> bl performance_monitor_exception
> b interrupt_return
>
> - GEN_KVM performance_monitor
> -
>
> /**
> * Interrupt 0xf20 - Vector Unavailable Interrupt.
> @@ -2321,8 +2247,6 @@ END_FTR_SECTION_IFSET(CPU_FTR_ALTIVEC)
> bl altivec_unavailable_exception
> b interrupt_return
>
> - GEN_KVM altivec_unavailable
> -
>
> /**
> * Interrupt 0xf40 - VSX Unavailable Interrupt.
> @@ -2371,8 +2295,6 @@ END_FTR_SECTION_IFSET(CPU_FTR_VSX)
> bl vsx_unavailable_exception
> b interrupt_return
>
> - GEN_KVM vsx_unavailable
> -
>
> /**
> * Interrupt 0xf60 - Facility Unavailable Interrupt.
> @@ -2401,8 +2323,6 @@ EXC_COMMON_BEGIN(facility_unavailable_common)
> REST_NVGPRS(r1) /* instruction emulation may change GPRs */
> b interrupt_return
>
> - GEN_KVM facility_unavailable
> -
>
> /**
> * Interrupt 0xf60 - Hypervisor Facility Unavailable Interrupt.
> @@ -2431,8 +2351,6 @@ EXC_COMMON_BEGIN(h_facility_unavailable_common)
> REST_NVGPRS(r1) /* XXX Shouldn't be necessary in practice */
> b interrupt_return
>
> - GEN_KVM h_facility_unavailable
> -
>
> EXC_REAL_NONE(0xfa0, 0x20)
> EXC_VIRT_NONE(0x4fa0, 0x20)
> @@ -2462,8 +2380,6 @@ EXC_COMMON_BEGIN(cbe_system_error_common)
> bl cbe_system_error_exception
> b interrupt_return
>
> - GEN_KVM cbe_system_error
> -
> #else /* CONFIG_CBE_RAS */
> EXC_REAL_NONE(0x1200, 0x100)
> EXC_VIRT_NONE(0x5200, 0x100)
> @@ -2489,8 +2405,6 @@ EXC_COMMON_BEGIN(instruction_breakpoint_common)
> bl instruction_breakpoint_exception
> b interrupt_return
>
> - GEN_KVM instruction_breakpoint
> -
>
> EXC_REAL_NONE(0x1400, 0x100)
> EXC_VIRT_NONE(0x5400, 0x100)
> @@ -2611,8 +2525,6 @@ EXC_COMMON_BEGIN(denorm_exception_common)
> bl unknown_exception
> b interrupt_return
>
> - GEN_KVM denorm_exception
> -
>
> #ifdef CONFIG_CBE_RAS
> INT_DEFINE_BEGIN(cbe_maintenance)
> @@ -2630,8 +2542,6 @@ EXC_COMMON_BEGIN(cbe_maintenance_common)
> bl cbe_maintenance_exception
> b interrupt_return
>
> - GEN_KVM cbe_maintenance
> -
> #else /* CONFIG_CBE_RAS */
> EXC_REAL_NONE(0x1600, 0x100)
> EXC_VIRT_NONE(0x5600, 0x100)
> @@ -2662,8 +2572,6 @@ EXC_COMMON_BEGIN(altivec_assist_common)
> #endif
> b interrupt_return
>
> - GEN_KVM altivec_assist
> -
>
> #ifdef CONFIG_CBE_RAS
> INT_DEFINE_BEGIN(cbe_thermal)
> @@ -2681,8 +2589,6 @@ EXC_COMMON_BEGIN(cbe_thermal_common)
> bl cbe_thermal_exception
> b interrupt_return
>
> - GEN_KVM cbe_thermal
> -
> #else /* CONFIG_CBE_RAS */
> EXC_REAL_NONE(0x1800, 0x100)
> EXC_VIRT_NONE(0x5800, 0x100)
> @@ -2935,6 +2841,15 @@ TRAMP_REAL_BEGIN(rfscv_flush_fallback)
>
> USE_TEXT_SECTION()
>
> +#ifdef CONFIG_KVM_BOOK3S_64_HANDLER
> +kvm_interrupt:
> + /*
> + * The conditional branch in KVMTEST can't reach all the way,
> + * make a stub.
> + */
> + b kvmppc_interrupt
> +#endif
> +
> _GLOBAL(do_uaccess_flush)
> UACCESS_FLUSH_FIXUP_SECTION
> nop
> diff --git a/arch/powerpc/kvm/book3s_64_entry.S b/arch/powerpc/kvm/book3s_64_entry.S
> index a7b6edd18bc8..d06e81842368 100644
> --- a/arch/powerpc/kvm/book3s_64_entry.S
> +++ b/arch/powerpc/kvm/book3s_64_entry.S
> @@ -31,15 +31,45 @@ END_FTR_SECTION_IFSET(CPU_FTR_HAS_PPR)
> sldi r12,r10,32
> ori r12,r12,0xc00
> ld r10,PACA_EXGEN+EX_R10(r13)
> + b do_kvm_interrupt
>
> .global kvmppc_interrupt
> .balign IFETCH_ALIGN_BYTES
> kvmppc_interrupt:
> + li r11,PACA_EXGEN
> + cmpdi r10,0x200
> + bgt+ 1f
> + li r11,PACA_EXMC
> + beq 1f
> + li r11,PACA_EXNMI
> +1: add r11,r11,r13
> +
> +BEGIN_FTR_SECTION
> + ld r12,EX_CFAR(r11)
r11 and r12 are not saved in EX_R11/12 as mentioned on slack unless I am
missing something.
> + std r12,HSTATE_CFAR(r13)
> +END_FTR_SECTION_IFSET(CPU_FTR_CFAR)
> + ld r12,EX_CTR(r11)
> + mtctr r12
> +BEGIN_FTR_SECTION
> + ld r12,EX_PPR(r11)
> + std r12,HSTATE_PPR(r13)
> +END_FTR_SECTION_IFSET(CPU_FTR_HAS_PPR)
> + ld r12,EX_R12(r11)
> + std r12,HSTATE_SCRATCH0(r13)
> + sldi r12,r9,32
> + or r12,r12,r10
> + ld r9,EX_R9(r11)
> + ld r10,EX_R10(r11)
> + ld r11,EX_R11(r11)
> +
> +do_kvm_interrupt:
> /*
> - * Register contents:
> + * Hcalls and other interrupts come here after normalising register
> + * contents and save locations:
> + *
> * R12 = (guest CR << 32) | interrupt vector
> * R13 = PACA
> - * guest R12 saved in shadow VCPU SCRATCH0
> + * guest R12 saved in shadow HSTATE_SCRATCH0
> * guest R13 saved in SPRN_SCRATCH0
> */
> std r9,HSTATE_SCRATCH2(r13)
>
--
Alexey
^ permalink raw reply
* Re: [PATCH v11 6/6] powerpc: Book3S 64-bit outline-only KASAN support
From: Balbir Singh @ 2021-03-20 6:02 UTC (permalink / raw)
To: Daniel Axtens
Cc: aneesh.kumar, linux-kernel, linux-mm, kasan-dev, linuxppc-dev
In-Reply-To: <20210319144058.772525-7-dja@axtens.net>
On Sat, Mar 20, 2021 at 01:40:58AM +1100, Daniel Axtens wrote:
> Implement a limited form of KASAN for Book3S 64-bit machines running under
> the Radix MMU, supporting only outline mode.
>
Could you highlight the changes from
https://patchwork.ozlabs.org/project/linuxppc-dev/patch/20170729140901.5887-1-bsingharora@gmail.com/?
Feel free to use my signed-off-by if you need to and add/update copyright
headers if appropriate.
> - Enable the compiler instrumentation to check addresses and maintain the
> shadow region. (This is the guts of KASAN which we can easily reuse.)
>
> - Require kasan-vmalloc support to handle modules and anything else in
> vmalloc space.
>
> - KASAN needs to be able to validate all pointer accesses, but we can't
> instrument all kernel addresses - only linear map and vmalloc. On boot,
> set up a single page of read-only shadow that marks all iomap and
> vmemmap accesses as valid.
>
> - Make our stack-walking code KASAN-safe by using READ_ONCE_NOCHECK -
> generic code, arm64, s390 and x86 all do this for similar sorts of
> reasons: when unwinding a stack, we might touch memory that KASAN has
> marked as being out-of-bounds. In our case we often get this when
> checking for an exception frame because we're checking an arbitrary
> offset into the stack frame.
>
> See commit 20955746320e ("s390/kasan: avoid false positives during stack
> unwind"), commit bcaf669b4bdb ("arm64: disable kasan when accessing
> frame->fp in unwind_frame"), commit 91e08ab0c851 ("x86/dumpstack:
> Prevent KASAN false positive warnings") and commit 6e22c8366416
> ("tracing, kasan: Silence Kasan warning in check_stack of stack_tracer")
>
> - Document KASAN in both generic and powerpc docs.
>
> Background
> ----------
>
> 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 with translations off ("real mode") during boot,
> including a lot of generic device-tree parsing code which is used to
> determine MMU features.
>
> [ppc64 mm note: The kernel installs a linear mapping at effective
> address c000...-c008.... 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.]
>
> - Some code - most notably a lot of KVM code - also runs with translations
> off after boot.
>
> - Therefore any offset has to point to memory that is valid with
> translations on or off.
>
> One approach is just to give up on inline instrumentation. This way
> boot-time checks can be delayed until after the MMU is set is up, and we
> can just not instrument any code that runs with translations off after
> booting. Take this approach for now and require outline instrumentation.
>
> Previous attempts allowed inline instrumentation. However, they came with
> some unfortunate restrictions: only physically contiguous memory could be
> used and it had to be specified at compile time. Maybe we can do better in
> the future.
>
> Cc: Balbir Singh <bsingharora@gmail.com> # ppc64 out-of-line radix version
> Cc: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com> # ppc64 hash version
> Cc: Christophe Leroy <christophe.leroy@csgroup.eu> # ppc32 version
> Signed-off-by: Daniel Axtens <dja@axtens.net>
> ---
> Documentation/dev-tools/kasan.rst | 11 +--
> Documentation/powerpc/kasan.txt | 48 +++++++++-
> arch/powerpc/Kconfig | 4 +-
> arch/powerpc/Kconfig.debug | 3 +-
> arch/powerpc/include/asm/book3s/64/hash.h | 4 +
> arch/powerpc/include/asm/book3s/64/pgtable.h | 4 +
> arch/powerpc/include/asm/book3s/64/radix.h | 13 ++-
> arch/powerpc/include/asm/kasan.h | 22 +++++
> arch/powerpc/kernel/Makefile | 11 +++
> arch/powerpc/kernel/process.c | 16 ++--
> arch/powerpc/kvm/Makefile | 5 ++
> arch/powerpc/mm/book3s64/Makefile | 9 ++
> arch/powerpc/mm/kasan/Makefile | 1 +
> arch/powerpc/mm/kasan/init_book3s_64.c | 95 ++++++++++++++++++++
> arch/powerpc/mm/ptdump/ptdump.c | 20 ++++-
> arch/powerpc/platforms/Kconfig.cputype | 1 +
> arch/powerpc/platforms/powernv/Makefile | 6 ++
> arch/powerpc/platforms/pseries/Makefile | 3 +
> 18 files changed, 257 insertions(+), 19 deletions(-)
> create mode 100644 arch/powerpc/mm/kasan/init_book3s_64.c
>
> diff --git a/Documentation/dev-tools/kasan.rst b/Documentation/dev-tools/kasan.rst
> index 2cfd5d9068c0..8024b55c7aa8 100644
> --- a/Documentation/dev-tools/kasan.rst
> +++ b/Documentation/dev-tools/kasan.rst
> @@ -36,8 +36,9 @@ Both software KASAN modes work with SLUB and SLAB memory allocators,
> while the hardware tag-based KASAN currently only supports SLUB.
>
> Currently, generic KASAN is supported for the x86_64, arm, arm64, xtensa, s390,
> -and riscv architectures. It is also supported on 32-bit powerpc kernels.
> -Tag-based KASAN modes are supported only for arm64.
> +and riscv architectures. It is also supported on powerpc for 32-bit kernels and
> +for 64-bit kernels running under the Radix MMU. Tag-based KASAN modes are
> +supported only for arm64.
>
> Usage
> -----
> @@ -335,10 +336,10 @@ CONFIG_KASAN_VMALLOC
>
> With ``CONFIG_KASAN_VMALLOC``, KASAN can cover vmalloc space at the
> cost of greater memory usage. Currently, this is supported on x86,
> -riscv, s390, and 32-bit powerpc.
> +riscv, s390, and powerpc.
>
> -It is optional, except on 32-bit powerpc kernels with module support,
> -where it is required.
> +It is optional, except on 64-bit powerpc kernels, and on 32-bit
> +powerpc kernels with module support, where it is required.
>
> This works by hooking into vmalloc and vmap and dynamically
> allocating real shadow memory to back the mappings.
> diff --git a/Documentation/powerpc/kasan.txt b/Documentation/powerpc/kasan.txt
> index 26bb0e8bb18c..f032b4eaf205 100644
> --- a/Documentation/powerpc/kasan.txt
> +++ b/Documentation/powerpc/kasan.txt
> @@ -1,4 +1,4 @@
> -KASAN is supported on powerpc on 32-bit only.
> +KASAN is supported on powerpc on 32-bit and Radix 64-bit only.
>
> 32 bit support
> ==============
> @@ -10,3 +10,49 @@ fixmap area and occupies one eighth of the total kernel virtual memory space.
>
> Instrumentation of the vmalloc area is optional, unless built with modules,
> in which case it is required.
> +
> +64 bit support
> +==============
> +
> +Currently, only the radix MMU is supported. There have been versions for hash
> +and Book3E processors floating around on the mailing list, but nothing has been
> +merged.
> +
> +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 with translations off ("real mode") during boot, including a
> + lot of generic device-tree parsing code which is used to determine MMU
> + features.
> +
> + - Some code - most notably a lot of KVM code - also runs with translations off
> + after boot.
> +
> + - Therefore any offset has to point to memory that is valid with
> + translations on or off.
> +
> +One approach is just to give up on inline instrumentation. This way boot-time
> +checks can be delayed until after the MMU is set is up, and we can just not
> +instrument any code that runs with translations off after booting. This is the
> +current approach.
> +
> +To avoid this limitiation, the KASAN shadow would have to be placed inside the
> +linear mapping, using the same high-bits trick we use for the rest of the linear
> +mapping. This is tricky:
> +
> + - We'd like to place it near the start of physical memory. In theory we can do
> + this at run-time based on how much physical memory we have, but this requires
> + being able to arbitrarily relocate the kernel, which is basically the tricky
> + part of KASLR. Not being game to implement both tricky things at once, this
> + is hopefully something we can revisit once we get KASLR for Book3S.
> +
> + - Alternatively, we can place the shadow at the _end_ of memory, but this
> + requires knowing how much contiguous physical memory a system has _at compile
> + time_. This is a big hammer, and has some unfortunate consequences: inablity
> + to handle discontiguous physical memory, total failure to boot on machines
> + with less memory than specified, and that machines with more memory than
> + specified can't use it. This was deemed unacceptable.
> diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
> index 4232d3f539c8..04aa817d1c5a 100644
> --- a/arch/powerpc/Kconfig
> +++ b/arch/powerpc/Kconfig
> @@ -118,6 +118,7 @@ config PPC
> # Please keep this list sorted alphabetically.
> #
> select ARCH_32BIT_OFF_T if PPC32
> + select ARCH_DISABLE_KASAN_INLINE if PPC_RADIX_MMU
> select ARCH_HAS_DEBUG_VIRTUAL
> select ARCH_HAS_DEVMEM_IS_ALLOWED
> select ARCH_HAS_ELF_RANDOMIZE
> @@ -183,7 +184,8 @@ config PPC
> select HAVE_ARCH_HUGE_VMAP if PPC_BOOK3S_64 && PPC_RADIX_MMU
> select HAVE_ARCH_JUMP_LABEL
> select HAVE_ARCH_KASAN if PPC32 && PPC_PAGE_SHIFT <= 14
> - select HAVE_ARCH_KASAN_VMALLOC if PPC32 && PPC_PAGE_SHIFT <= 14
> + select HAVE_ARCH_KASAN if PPC_RADIX_MMU
> + select HAVE_ARCH_KASAN_VMALLOC if HAVE_ARCH_KASAN
> select HAVE_ARCH_KGDB
> select HAVE_ARCH_MMAP_RND_BITS
> select HAVE_ARCH_MMAP_RND_COMPAT_BITS if COMPAT
> diff --git a/arch/powerpc/Kconfig.debug b/arch/powerpc/Kconfig.debug
> index ae084357994e..195f7845f41a 100644
> --- a/arch/powerpc/Kconfig.debug
> +++ b/arch/powerpc/Kconfig.debug
> @@ -398,4 +398,5 @@ config PPC_FAST_ENDIAN_SWITCH
> config KASAN_SHADOW_OFFSET
> hex
> depends on KASAN
> - default 0xe0000000
> + default 0xe0000000 if PPC32
> + default 0xa80e000000000000 if PPC64
> diff --git a/arch/powerpc/include/asm/book3s/64/hash.h b/arch/powerpc/include/asm/book3s/64/hash.h
> index d959b0195ad9..222669864ff6 100644
> --- a/arch/powerpc/include/asm/book3s/64/hash.h
> +++ b/arch/powerpc/include/asm/book3s/64/hash.h
> @@ -18,6 +18,10 @@
> #include <asm/book3s/64/hash-4k.h>
> #endif
>
> +#define H_PTRS_PER_PTE (1 << H_PTE_INDEX_SIZE)
> +#define H_PTRS_PER_PMD (1 << H_PMD_INDEX_SIZE)
> +#define H_PTRS_PER_PUD (1 << H_PUD_INDEX_SIZE)
> +
> /* Bits to set in a PMD/PUD/PGD entry valid bit*/
> #define HASH_PMD_VAL_BITS (0x8000000000000000UL)
> #define HASH_PUD_VAL_BITS (0x8000000000000000UL)
> diff --git a/arch/powerpc/include/asm/book3s/64/pgtable.h b/arch/powerpc/include/asm/book3s/64/pgtable.h
> index 058601efbc8a..7598a5b055bd 100644
> --- a/arch/powerpc/include/asm/book3s/64/pgtable.h
> +++ b/arch/powerpc/include/asm/book3s/64/pgtable.h
> @@ -230,6 +230,10 @@ extern unsigned long __pmd_frag_size_shift;
> #define PTRS_PER_PUD (1 << PUD_INDEX_SIZE)
> #define PTRS_PER_PGD (1 << PGD_INDEX_SIZE)
>
> +#define MAX_PTRS_PER_PTE ((H_PTRS_PER_PTE > R_PTRS_PER_PTE) ? H_PTRS_PER_PTE : R_PTRS_PER_PTE)
> +#define MAX_PTRS_PER_PMD ((H_PTRS_PER_PMD > R_PTRS_PER_PMD) ? H_PTRS_PER_PMD : R_PTRS_PER_PMD)
> +#define MAX_PTRS_PER_PUD ((H_PTRS_PER_PUD > R_PTRS_PER_PUD) ? H_PTRS_PER_PUD : R_PTRS_PER_PUD)
> +
> /* PMD_SHIFT determines what a second-level page table entry can map */
> #define PMD_SHIFT (PAGE_SHIFT + PTE_INDEX_SIZE)
> #define PMD_SIZE (1UL << PMD_SHIFT)
> diff --git a/arch/powerpc/include/asm/book3s/64/radix.h b/arch/powerpc/include/asm/book3s/64/radix.h
> index c7813dc628fc..b3492b80f858 100644
> --- a/arch/powerpc/include/asm/book3s/64/radix.h
> +++ b/arch/powerpc/include/asm/book3s/64/radix.h
> @@ -35,6 +35,11 @@
> #define RADIX_PMD_SHIFT (PAGE_SHIFT + RADIX_PTE_INDEX_SIZE)
> #define RADIX_PUD_SHIFT (RADIX_PMD_SHIFT + RADIX_PMD_INDEX_SIZE)
> #define RADIX_PGD_SHIFT (RADIX_PUD_SHIFT + RADIX_PUD_INDEX_SIZE)
> +
> +#define R_PTRS_PER_PTE (1 << RADIX_PTE_INDEX_SIZE)
> +#define R_PTRS_PER_PMD (1 << RADIX_PMD_INDEX_SIZE)
> +#define R_PTRS_PER_PUD (1 << RADIX_PUD_INDEX_SIZE)
> +
> /*
> * Size of EA range mapped by our pagetables.
> */
> @@ -68,11 +73,11 @@
> *
> *
> * 3rd quadrant expanded:
> - * +------------------------------+
> + * +------------------------------+ Highest address (0xc010000000000000)
> + * +------------------------------+ KASAN shadow end (0xc00fc00000000000)
> * | |
> * | |
> - * | |
> - * +------------------------------+ Kernel vmemmap end (0xc010000000000000)
> + * +------------------------------+ Kernel vmemmap end/shadow start (0xc00e000000000000)
> * | |
> * | 512TB |
> * | |
> @@ -126,6 +131,8 @@
> #define RADIX_VMEMMAP_SIZE RADIX_KERN_MAP_SIZE
> #define RADIX_VMEMMAP_END (RADIX_VMEMMAP_START + RADIX_VMEMMAP_SIZE)
>
> +/* For the sizes of the shadow area, see kasan.h */
> +
> #ifndef __ASSEMBLY__
> #define RADIX_PTE_TABLE_SIZE (sizeof(pte_t) << RADIX_PTE_INDEX_SIZE)
> #define RADIX_PMD_TABLE_SIZE (sizeof(pmd_t) << RADIX_PMD_INDEX_SIZE)
> diff --git a/arch/powerpc/include/asm/kasan.h b/arch/powerpc/include/asm/kasan.h
> index 7355ed05e65e..df946165812d 100644
> --- a/arch/powerpc/include/asm/kasan.h
> +++ b/arch/powerpc/include/asm/kasan.h
> @@ -30,9 +30,31 @@
>
> #define KASAN_SHADOW_OFFSET ASM_CONST(CONFIG_KASAN_SHADOW_OFFSET)
>
> +#ifdef CONFIG_PPC32
> #define KASAN_SHADOW_END (-(-KASAN_SHADOW_START >> KASAN_SHADOW_SCALE_SHIFT))
> +#endif
>
> #ifdef CONFIG_KASAN
> +#ifdef CONFIG_PPC_BOOK3S_64
> +/*
> + * The shadow ends before the highest accessible address
> + * because we don't need a shadow for the shadow. Instead:
> + * c00e000000000000 << 3 + a80e000000000000000 = c00fc00000000000
The comment has one extra 0 in a80e.., I did the math and had to use
the data from the defines :)
> + */
> +#define KASAN_SHADOW_END 0xc00fc00000000000UL
> +
> +DECLARE_STATIC_KEY_FALSE(powerpc_kasan_enabled_key);
> +
> +static __always_inline bool kasan_arch_is_ready(void)
> +{
> + if (static_branch_likely(&powerpc_kasan_enabled_key))
> + return true;
> + return false;
> +}
> +
> +#define kasan_arch_is_ready kasan_arch_is_ready
> +#endif
> +
> void kasan_early_init(void);
> void kasan_mmu_init(void);
> void kasan_init(void);
> diff --git a/arch/powerpc/kernel/Makefile b/arch/powerpc/kernel/Makefile
> index 6084fa499aa3..163755b1cef4 100644
> --- a/arch/powerpc/kernel/Makefile
> +++ b/arch/powerpc/kernel/Makefile
> @@ -32,6 +32,17 @@ KASAN_SANITIZE_early_32.o := n
> KASAN_SANITIZE_cputable.o := n
> KASAN_SANITIZE_prom_init.o := n
> KASAN_SANITIZE_btext.o := n
> +KASAN_SANITIZE_paca.o := n
> +KASAN_SANITIZE_setup_64.o := n
> +KASAN_SANITIZE_mce.o := n
> +KASAN_SANITIZE_mce_power.o := n
> +
> +# we have to be particularly careful in ppc64 to exclude code that
> +# runs with translations off, as we cannot access the shadow with
> +# translations off. However, ppc32 can sanitize this.
> +ifdef CONFIG_PPC64
> +KASAN_SANITIZE_traps.o := n
> +endif
>
> ifdef CONFIG_KASAN
> CFLAGS_early_32.o += -DDISABLE_BRANCH_PROFILING
> diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/kernel/process.c
> index 3231c2df9e26..d4ae21b9e9b7 100644
> --- a/arch/powerpc/kernel/process.c
> +++ b/arch/powerpc/kernel/process.c
> @@ -2160,8 +2160,8 @@ void show_stack(struct task_struct *tsk, unsigned long *stack,
> break;
>
> stack = (unsigned long *) sp;
> - newsp = stack[0];
> - ip = stack[STACK_FRAME_LR_SAVE];
> + newsp = READ_ONCE_NOCHECK(stack[0]);
> + ip = READ_ONCE_NOCHECK(stack[STACK_FRAME_LR_SAVE]);
> if (!firstframe || ip != lr) {
> printk("%s["REG"] ["REG"] %pS",
> loglvl, sp, ip, (void *)ip);
> @@ -2179,17 +2179,19 @@ void show_stack(struct task_struct *tsk, unsigned long *stack,
> * See if this is an exception frame.
> * We look for the "regshere" marker in the current frame.
> */
> - if (validate_sp(sp, tsk, STACK_FRAME_WITH_PT_REGS)
> - && stack[STACK_FRAME_MARKER] == STACK_FRAME_REGS_MARKER) {
> + if (validate_sp(sp, tsk, STACK_FRAME_WITH_PT_REGS) &&
> + (READ_ONCE_NOCHECK(stack[STACK_FRAME_MARKER]) ==
> + STACK_FRAME_REGS_MARKER)) {
> struct pt_regs *regs = (struct pt_regs *)
> (sp + STACK_FRAME_OVERHEAD);
>
> - lr = regs->link;
> + lr = READ_ONCE_NOCHECK(regs->link);
> printk("%s--- interrupt: %lx at %pS\n",
> - loglvl, regs->trap, (void *)regs->nip);
> + loglvl, READ_ONCE_NOCHECK(regs->trap),
> + (void *)READ_ONCE_NOCHECK(regs->nip));
> __show_regs(regs);
> printk("%s--- interrupt: %lx\n",
> - loglvl, regs->trap);
> + loglvl, READ_ONCE_NOCHECK(regs->trap));
>
> firstframe = 1;
> }
> diff --git a/arch/powerpc/kvm/Makefile b/arch/powerpc/kvm/Makefile
> index 2bfeaa13befb..7f1592dacbeb 100644
> --- a/arch/powerpc/kvm/Makefile
> +++ b/arch/powerpc/kvm/Makefile
> @@ -136,3 +136,8 @@ obj-$(CONFIG_KVM_BOOK3S_64_PR) += kvm-pr.o
> obj-$(CONFIG_KVM_BOOK3S_64_HV) += kvm-hv.o
>
> obj-y += $(kvm-book3s_64-builtin-objs-y)
> +
> +# KVM does a lot in real-mode, and 64-bit Book3S KASAN doesn't support that
> +ifdef CONFIG_PPC_BOOK3S_64
> +KASAN_SANITIZE := n
> +endif
> diff --git a/arch/powerpc/mm/book3s64/Makefile b/arch/powerpc/mm/book3s64/Makefile
> index 1b56d3af47d4..a7d8a68bd2c5 100644
> --- a/arch/powerpc/mm/book3s64/Makefile
> +++ b/arch/powerpc/mm/book3s64/Makefile
> @@ -21,3 +21,12 @@ obj-$(CONFIG_PPC_PKEY) += pkeys.o
>
> # Instrumenting the SLB fault path can lead to duplicate SLB entries
> KCOV_INSTRUMENT_slb.o := n
> +
> +# Parts of these can run in real mode and therefore are
> +# not safe with the current outline KASAN implementation
> +KASAN_SANITIZE_mmu_context.o := n
> +KASAN_SANITIZE_pgtable.o := n
> +KASAN_SANITIZE_radix_pgtable.o := n
> +KASAN_SANITIZE_radix_tlb.o := n
> +KASAN_SANITIZE_slb.o := n
> +KASAN_SANITIZE_pkeys.o := n
> diff --git a/arch/powerpc/mm/kasan/Makefile b/arch/powerpc/mm/kasan/Makefile
> index 42fb628a44fd..07eef87abd6c 100644
> --- a/arch/powerpc/mm/kasan/Makefile
> +++ b/arch/powerpc/mm/kasan/Makefile
> @@ -5,3 +5,4 @@ KASAN_SANITIZE := n
> obj-$(CONFIG_PPC32) += init_32.o
> obj-$(CONFIG_PPC_8xx) += 8xx.o
> obj-$(CONFIG_PPC_BOOK3S_32) += book3s_32.o
> +obj-$(CONFIG_PPC_BOOK3S_64) += init_book3s_64.o
> diff --git a/arch/powerpc/mm/kasan/init_book3s_64.c b/arch/powerpc/mm/kasan/init_book3s_64.c
> new file mode 100644
> index 000000000000..ca913ed951a2
> --- /dev/null
> +++ b/arch/powerpc/mm/kasan/init_book3s_64.c
> @@ -0,0 +1,95 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/*
> + * KASAN for 64-bit Book3S powerpc
> + *
> + * Copyright (C) 2019-2020 IBM Corporation
> + * Author: Daniel Axtens <dja@axtens.net>
> + */
> +
> +#define DISABLE_BRANCH_PROFILING
> +
> +#include <linux/kasan.h>
> +#include <linux/printk.h>
> +#include <linux/sched/task.h>
> +#include <linux/memblock.h>
> +#include <asm/pgalloc.h>
> +
> +DEFINE_STATIC_KEY_FALSE(powerpc_kasan_enabled_key);
> +
> +static void __init kasan_init_phys_region(void *start, void *end)
> +{
> + unsigned long k_start, k_end, k_cur;
> + void *va;
> +
> + if (start >= end)
> + return;
> +
> + k_start = ALIGN_DOWN((unsigned long)kasan_mem_to_shadow(start), PAGE_SIZE);
> + k_end = ALIGN((unsigned long)kasan_mem_to_shadow(end), PAGE_SIZE);
> +
> + va = memblock_alloc(k_end - k_start, PAGE_SIZE);
> + for (k_cur = k_start; k_cur < k_end; k_cur += PAGE_SIZE, va += PAGE_SIZE)
> + map_kernel_page(k_cur, __pa(va), PAGE_KERNEL);
> +}
> +
> +void __init kasan_init(void)
> +{
> + /*
> + * We want to do the following things:
> + * 1) Map real memory into the shadow for all physical memblocks
> + * This takes us from c000... to c008...
> + * 2) Leave a hole over the shadow of vmalloc space. KASAN_VMALLOC
> + * will manage this for us.
> + * This takes us from c008... to c00a...
> + * 3) Map the 'early shadow'/zero page over iomap and vmemmap space.
> + * This takes us up to where we start at c00e...
> + */
> +
assuming we have
#define VMEMMAP_END R_VMEMMAP_END
and ditto for hash we probably need
BUILD_BUG_ON(VMEMMAP_END + KASAN_SHADOW_OFFSET != KASAN_SHADOW_END);
Looks good otherwise, I've not been able to test it yet
Balbir Singh.
^ permalink raw reply
* [for-stable-4.19 PATCH v2 1/2] vmlinux.lds.h: Create section for protection against instrumentation
From: Nicolas Boichat @ 2021-03-20 4:16 UTC (permalink / raw)
To: stable
Cc: linux-arch, Nicolas Boichat, Alexandre Chartre, Arnd Bergmann,
linux-kbuild, Peter Zijlstra, Christopher Li, linux-kernel,
Nicholas Piggin, Masahiro Yamada, linux-sparse, Michal Marek,
Paul Mackerras, Greg Kroah-Hartman, groeck, Thomas Gleixner,
linuxppc-dev, Naveen N. Rao, Daniel Axtens
In-Reply-To: <20210320041626.885806-1-drinkcat@chromium.org>
From: Thomas Gleixner <tglx@linutronix.de>
commit 6553896666433e7efec589838b400a2a652b3ffa upstream.
Some code pathes, especially the low level entry code, must be protected
against instrumentation for various reasons:
- Low level entry code can be a fragile beast, especially on x86.
- With NO_HZ_FULL RCU state needs to be established before using it.
Having a dedicated section for such code allows to validate with tooling
that no unsafe functions are invoked.
Add the .noinstr.text section and the noinstr attribute to mark
functions. noinstr implies notrace. Kprobes will gain a section check
later.
Provide also a set of markers: instrumentation_begin()/end()
These are used to mark code inside a noinstr function which calls
into regular instrumentable text section as safe.
The instrumentation markers are only active when CONFIG_DEBUG_ENTRY is
enabled as the end marker emits a NOP to prevent the compiler from merging
the annotation points. This means the objtool verification requires a
kernel compiled with this option.
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Reviewed-by: Alexandre Chartre <alexandre.chartre@oracle.com>
Acked-by: Peter Zijlstra <peterz@infradead.org>
Link: https://lkml.kernel.org/r/20200505134100.075416272@linutronix.de
[Nicolas:
Guard noinstr macro in include/linux/compiler_types.h in __KERNEL__
&& !__ASSEMBLY__, otherwise noinstr is expanded in the linker
script construct.
Upstream does not have this problem as many macros were moved by
commit 71391bdd2e9a ("include/linux/compiler_types.h: don't pollute
userspace with macro definitions"). We take the minimal approach here
and just guard the new macro.
Minor context conflicts in:
arch/powerpc/kernel/vmlinux.lds.S
include/asm-generic/vmlinux.lds.h
include/linux/compiler.h]
Signed-off-by: Nicolas Boichat <drinkcat@chromium.org>
---
Technically guarding with !__ASSEMBLY__ should be enough, but
there seems to be no reason to expose this new macro when
!__KERNEL__, so let's just match what upstream does.
Changes in v2:
- Guard noinstr macro by __KERNEL__ && !__ASSEMBLY__ to prevent
expansion in linker script and match upstream.
arch/powerpc/kernel/vmlinux.lds.S | 1 +
include/asm-generic/sections.h | 3 ++
include/asm-generic/vmlinux.lds.h | 10 ++++++
include/linux/compiler.h | 54 +++++++++++++++++++++++++++++++
include/linux/compiler_types.h | 6 ++++
scripts/mod/modpost.c | 2 +-
6 files changed, 75 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/kernel/vmlinux.lds.S b/arch/powerpc/kernel/vmlinux.lds.S
index 695432965f20..9b346f3d2814 100644
--- a/arch/powerpc/kernel/vmlinux.lds.S
+++ b/arch/powerpc/kernel/vmlinux.lds.S
@@ -99,6 +99,7 @@ SECTIONS
#endif
/* careful! __ftr_alt_* sections need to be close to .text */
*(.text.hot TEXT_MAIN .text.fixup .text.unlikely .fixup __ftr_alt_* .ref.text);
+ NOINSTR_TEXT
SCHED_TEXT
CPUIDLE_TEXT
LOCK_TEXT
diff --git a/include/asm-generic/sections.h b/include/asm-generic/sections.h
index 849cd8eb5ca0..ea5987bb0b84 100644
--- a/include/asm-generic/sections.h
+++ b/include/asm-generic/sections.h
@@ -53,6 +53,9 @@ extern char __ctors_start[], __ctors_end[];
/* Start and end of .opd section - used for function descriptors. */
extern char __start_opd[], __end_opd[];
+/* Start and end of instrumentation protected text section */
+extern char __noinstr_text_start[], __noinstr_text_end[];
+
extern __visible const void __nosave_begin, __nosave_end;
/* Function descriptor handling (if any). Override in asm/sections.h */
diff --git a/include/asm-generic/vmlinux.lds.h b/include/asm-generic/vmlinux.lds.h
index 2d632a74cc5e..88484ee023ca 100644
--- a/include/asm-generic/vmlinux.lds.h
+++ b/include/asm-generic/vmlinux.lds.h
@@ -482,6 +482,15 @@
__security_initcall_end = .; \
}
+/*
+ * Non-instrumentable text section
+ */
+#define NOINSTR_TEXT \
+ ALIGN_FUNCTION(); \
+ __noinstr_text_start = .; \
+ *(.noinstr.text) \
+ __noinstr_text_end = .;
+
/*
* .text section. Map to function alignment to avoid address changes
* during second ld run in second ld pass when generating System.map
@@ -496,6 +505,7 @@
*(TEXT_MAIN .text.fixup) \
*(.text.unlikely .text.unlikely.*) \
*(.text.unknown .text.unknown.*) \
+ NOINSTR_TEXT \
*(.text..refcount) \
*(.ref.text) \
MEM_KEEP(init.text*) \
diff --git a/include/linux/compiler.h b/include/linux/compiler.h
index 6b6505e3b2c7..6a53300cbd1e 100644
--- a/include/linux/compiler.h
+++ b/include/linux/compiler.h
@@ -129,11 +129,65 @@ void ftrace_likely_update(struct ftrace_likely_data *f, int val,
".pushsection .discard.unreachable\n\t" \
".long 999b - .\n\t" \
".popsection\n\t"
+
+#ifdef CONFIG_DEBUG_ENTRY
+/* Begin/end of an instrumentation safe region */
+#define instrumentation_begin() ({ \
+ asm volatile("%c0:\n\t" \
+ ".pushsection .discard.instr_begin\n\t" \
+ ".long %c0b - .\n\t" \
+ ".popsection\n\t" : : "i" (__COUNTER__)); \
+})
+
+/*
+ * Because instrumentation_{begin,end}() can nest, objtool validation considers
+ * _begin() a +1 and _end() a -1 and computes a sum over the instructions.
+ * When the value is greater than 0, we consider instrumentation allowed.
+ *
+ * There is a problem with code like:
+ *
+ * noinstr void foo()
+ * {
+ * instrumentation_begin();
+ * ...
+ * if (cond) {
+ * instrumentation_begin();
+ * ...
+ * instrumentation_end();
+ * }
+ * bar();
+ * instrumentation_end();
+ * }
+ *
+ * If instrumentation_end() would be an empty label, like all the other
+ * annotations, the inner _end(), which is at the end of a conditional block,
+ * would land on the instruction after the block.
+ *
+ * If we then consider the sum of the !cond path, we'll see that the call to
+ * bar() is with a 0-value, even though, we meant it to happen with a positive
+ * value.
+ *
+ * To avoid this, have _end() be a NOP instruction, this ensures it will be
+ * part of the condition block and does not escape.
+ */
+#define instrumentation_end() ({ \
+ asm volatile("%c0: nop\n\t" \
+ ".pushsection .discard.instr_end\n\t" \
+ ".long %c0b - .\n\t" \
+ ".popsection\n\t" : : "i" (__COUNTER__)); \
+})
+#endif /* CONFIG_DEBUG_ENTRY */
+
#else
#define annotate_reachable()
#define annotate_unreachable()
#endif
+#ifndef instrumentation_begin
+#define instrumentation_begin() do { } while(0)
+#define instrumentation_end() do { } while(0)
+#endif
+
#ifndef ASM_UNREACHABLE
# define ASM_UNREACHABLE
#endif
diff --git a/include/linux/compiler_types.h b/include/linux/compiler_types.h
index 2b8ed70c4c77..c01100318b25 100644
--- a/include/linux/compiler_types.h
+++ b/include/linux/compiler_types.h
@@ -234,6 +234,12 @@ struct ftrace_likely_data {
#define notrace __attribute__((no_instrument_function))
#endif
+#if defined(__KERNEL__) && !defined(__ASSEMBLY__)
+/* Section for code which can't be instrumented at all */
+#define noinstr \
+ noinline notrace __attribute((__section__(".noinstr.text")))
+#endif
+
/*
* it doesn't make sense on ARM (currently the only user of __naked)
* to trace naked functions because then mcount is called without
diff --git a/scripts/mod/modpost.c b/scripts/mod/modpost.c
index 91a80036c05d..7c693bd775c1 100644
--- a/scripts/mod/modpost.c
+++ b/scripts/mod/modpost.c
@@ -895,7 +895,7 @@ static void check_section(const char *modname, struct elf_info *elf,
#define DATA_SECTIONS ".data", ".data.rel"
#define TEXT_SECTIONS ".text", ".text.unlikely", ".sched.text", \
- ".kprobes.text", ".cpuidle.text"
+ ".kprobes.text", ".cpuidle.text", ".noinstr.text"
#define OTHER_TEXT_SECTIONS ".ref.text", ".head.text", ".spinlock.text", \
".fixup", ".entry.text", ".exception.text", ".text.*", \
".coldtext"
--
2.31.0.rc2.261.g7f71774620-goog
^ permalink raw reply related
* [for-stable-4.19 PATCH v2 0/2] Backport patches to fix KASAN+LKDTM with recent clang on ARM64
From: Nicolas Boichat @ 2021-03-20 4:16 UTC (permalink / raw)
To: stable
Cc: Alexandre Chartre, Peter Zijlstra, Christopher Li,
Masahiro Yamada, Paul Mackerras, groeck, linux-arch,
Nicolas Boichat, clang-built-linux, linux-sparse, Naveen N. Rao,
Kees Cook, Arnd Bergmann, linux-kbuild, Nicholas Piggin,
Thomas Gleixner, Daniel Axtens, Michal Marek, Greg Kroah-Hartman,
linux-kernel, linuxppc-dev
Backport 2 patches that are required to make KASAN+LKDTM work
with recent clang (patch 2/2 has a complete description).
Tested on our chromeos-4.19 branch.
Also compile tested on x86-64 and arm64 with gcc this time
around.
Patch 1/2 adds a guard around noinstr that matches upstream,
to prevent a build issue, and has some minor context conflicts.
Patch 2/2 is a clean backport.
These patches have been merged to 5.4 stable already. We might
need to backport to older stable branches, but this is what I
could test for now.
Changes in v2:
- Guard noinstr macro by __KERNEL__ && !__ASSEMBLY__ to prevent
expansion in linker script and match upstream.
Mark Rutland (1):
lkdtm: don't move ctors to .rodata
Thomas Gleixner (1):
vmlinux.lds.h: Create section for protection against instrumentation
arch/powerpc/kernel/vmlinux.lds.S | 1 +
drivers/misc/lkdtm/Makefile | 2 +-
drivers/misc/lkdtm/rodata.c | 2 +-
include/asm-generic/sections.h | 3 ++
include/asm-generic/vmlinux.lds.h | 10 ++++++
include/linux/compiler.h | 54 +++++++++++++++++++++++++++++++
include/linux/compiler_types.h | 6 ++++
scripts/mod/modpost.c | 2 +-
8 files changed, 77 insertions(+), 3 deletions(-)
--
2.31.0.rc2.261.g7f71774620-goog
^ permalink raw reply
* Re: [PATCH 10/10] ide: remove the legacy ide driver
From: Maciej W. Rozycki @ 2021-03-20 4:04 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Jens Axboe, Thomas Bogendoerfer, linux-doc, Russell King,
linux-kernel, linux-ide, linux-m68k, Ivan Kokshaysky, linux-alpha,
Geert Uytterhoeven, Matt Turner, linux-mips, linuxppc-dev,
David S. Miller, linux-arm-kernel, Richard Henderson
In-Reply-To: <alpine.DEB.2.21.2103200425360.21463@angie.orcam.me.uk>
On Sat, 20 Mar 2021, Maciej W. Rozycki wrote:
> > been scheduled for removal for a while. Finally kill it off so that we
> > can start cleaning up various bits of cruft it forced on the block layer.
>
> You need to adjust Documentation/admin-guide/kernel-parameters.txt too,
> i.e. remove all the `ide*' options, possibly more (I haven't checked in
> detail).
And also Documentation/ide/ide.rst. Also do we have all the necessary
`hdparm' features supported in libata nowadays for PATA devices?
Maciej
^ permalink raw reply
* Re: [PATCH 10/10] ide: remove the legacy ide driver
From: Maciej W. Rozycki @ 2021-03-20 3:44 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Jens Axboe, Thomas Bogendoerfer, linux-doc, Russell King,
linux-kernel, linux-ide, linux-m68k, Ivan Kokshaysky, linux-alpha,
Geert Uytterhoeven, Matt Turner, linux-mips, linuxppc-dev,
David S. Miller, linux-arm-kernel, Richard Henderson
In-Reply-To: <20210318045706.200458-11-hch@lst.de>
On Thu, 18 Mar 2021, Christoph Hellwig wrote:
> The legay ide driver has been replace with libata startin in 2003 and has
s/legay/legacy/;s/replace/replaced/;s/startin/startin/ (though I'd say
"back in" instead in the latter case).
> been scheduled for removal for a while. Finally kill it off so that we
> can start cleaning up various bits of cruft it forced on the block layer.
You need to adjust Documentation/admin-guide/kernel-parameters.txt too,
i.e. remove all the `ide*' options, possibly more (I haven't checked in
detail).
Maciej
^ permalink raw reply
* Re: [PATCH v11 1/6] kasan: allow an architecture to disable inline instrumentation
From: Balbir Singh @ 2021-03-20 1:46 UTC (permalink / raw)
To: Daniel Axtens
Cc: aneesh.kumar, linux-kernel, linux-mm, kasan-dev, linuxppc-dev
In-Reply-To: <20210319144058.772525-2-dja@axtens.net>
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.
^ permalink raw reply
* Re: [PATCH v11 0/6] KASAN for powerpc64 radix
From: Balbir Singh @ 2021-03-20 1:40 UTC (permalink / raw)
To: Daniel Axtens
Cc: aneesh.kumar, linux-kernel, linux-mm, kasan-dev, linuxppc-dev
In-Reply-To: <20210319144058.772525-1-dja@axtens.net>
On Sat, Mar 20, 2021 at 01:40:52AM +1100, Daniel Axtens wrote:
> Building on the work of Christophe, Aneesh and Balbir, I've ported
> KASAN to 64-bit Book3S kernels running on the Radix MMU.
>
> v11 applies to next-20210317. I had hoped to have it apply to
> powerpc/next but once again there are changes in the kasan core that
> clash. Also, thanks to mpe for fixing a build break with KASAN off.
>
> I'm not sure how best to progress this towards actually being merged
> when it has impacts across subsystems. I'd appreciate any input. Maybe
> the first four patches could go in via the kasan tree, that should
> make things easier for powerpc in a future cycle?
>
> v10 rebases on top of next-20210125, fixing things up to work on top
> of the latest changes, and fixing some review comments from
> Christophe. I have tested host and guest with 64k pages for this spin.
>
> There is now only 1 failing KUnit test: 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.)
>
> (The previously failing stack tests are now skipped due to more
> accurate configuration settings.)
>
> Details from v9: 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.
>
The last time I checked, the changes for real mode, made the code hard to
review/maintain. I am happy to see that we've decided to leave that off
the table for now, reviewing the series
Balbir Singh.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox