* Re: [PATCH] powerpc64/idle: Fix SP offsets when saving GPRs
From: Nicholas Piggin @ 2021-02-04 9:05 UTC (permalink / raw)
To: Christopher M. Riedl, linuxppc-dev, Michael Ellerman
In-Reply-To: <C90JVYFOGWU0.1C2DRATSDH0FM@geist>
Excerpts from Christopher M. Riedl's message of February 4, 2021 4:59 pm:
> On Sat Jan 30, 2021 at 7:44 AM CST, Nicholas Piggin wrote:
>> Excerpts from Michael Ellerman's message of January 30, 2021 9:32 pm:
>> > "Christopher M. Riedl" <cmr@codefail.de> writes:
>> >> The idle entry/exit code saves/restores GPRs in the stack "red zone"
>> >> (Protected Zone according to PowerPC64 ELF ABI v2). However, the offset
>> >> used for the first GPR is incorrect and overwrites the back chain - the
>> >> Protected Zone actually starts below the current SP. In practice this is
>> >> probably not an issue, but it's still incorrect so fix it.
>> >
>> > Nice catch.
>> >
>> > Corrupting the back chain means you can't backtrace from there, which
>> > could be confusing for debugging one day.
>>
>> Yeah, we seem to have got away without noticing because the CPU will
>> wake up and return out of here before it tries to unwind the stack,
>> but if you tried to walk it by hand if the CPU got stuck in idle or
>> something, then we'd get confused.
>>
>> > It does make me wonder why we don't just create a stack frame and use
>> > the normal macros? It would use a bit more stack space, but we shouldn't
>> > be short of stack space when going idle.
>> >
>> > Nick, was there a particular reason for using the red zone?
>>
>> I don't recall a particular reason, I think a normal stack frame is
>> probably a good idea.
>
> I'll send a version using STACKFRAMESIZE - I assume that's the "normal"
> stack frame :)
>
I think STACKFRAMESIZE is STACK_FRAME_OVERHEAD + NVGPRs. LR and CR can
be saved in the caller's frame so that should be okay.
> I admit I am a bit confused when I saw the similar but much smaller
> STACK_FRAME_OVERHEAD which is also used in _some_ cases to save/restore
> a few registers.
Yeah if you don't need to save all nvgprs you can use caller's frame
plus a few bytes in the minimum frame as volatile storage.
STACK_FRAME_OVERHEAD should be 32 on LE, but I think the problem is a
lot of asm uses it and hasn't necessarily been audited to make sure it's
not assuming it's bigger. You could actually use STACK_FRAME_MIN_SIZE
for new code, maybe we add a STACK_FRAME_MIN_NVGPR_SIZE to match and
use that.
Thanks,
Nick
^ permalink raw reply
* Re: [PATCH v7 39/42] powerpc: move NMI entry/exit code into wrapper
From: Michael Ellerman @ 2021-02-04 10:15 UTC (permalink / raw)
To: Nicholas Piggin, linuxppc-dev; +Cc: Athira Rajeev, Nicholas Piggin
In-Reply-To: <20210130130852.2952424-40-npiggin@gmail.com>
Nicholas Piggin <npiggin@gmail.com> writes:
> This moves the common NMI entry and exit code into the interrupt handler
> wrappers.
>
> This changes the behaviour of soft-NMI (watchdog) and HMI interrupts, and
> also MCE interrupts on 64e, by adding missing parts of the NMI entry to
> them.
>
> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
> ---
> arch/powerpc/include/asm/interrupt.h | 28 ++++++++++++++++++++++
> arch/powerpc/kernel/mce.c | 11 ---------
> arch/powerpc/kernel/traps.c | 35 +++++-----------------------
> arch/powerpc/kernel/watchdog.c | 10 ++++----
> 4 files changed, 38 insertions(+), 46 deletions(-)
This is unhappy when injecting SLB multi-hits:
root@p86-2:~# echo PPC_SLB_MULTIHIT > /sys/kernel/debug/provoke-crash/DIRECT
[ 312.496026][ T1344] kernel BUG at arch/powerpc/include/asm/interrupt.h:152!
[ 312.496037][ T1344] Oops: Exception in kernel mode, sig: 5 [#1]
[ 312.496045][ T1344] LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA pSeries
[ 312.496053][ T1344] Modules linked in: squashfs dm_multipath scsi_dh_rdac scsi_dh_alua pseries_rng rng_core vmx_crypto gf128mul crc32c_vpmsum ip_tables x_tables autofs4
[ 312.496085][ T1344] CPU: 19 PID: 1344 Comm: bash Not tainted 5.11.0-rc2-gcc-8.2.0-00123-g3fadced17474-dirty #638
[ 312.496096][ T1344] NIP: c000000000ef1618 LR: c000000000ef1600 CTR: 0000000000000000
[ 312.496104][ T1344] REGS: c00000001eb4ba00 TRAP: 0700 Not tainted (5.11.0-rc2-gcc-8.2.0-00123-g3fadced17474-dirty)
[ 312.496113][ T1344] MSR: 8000000000021033 <SF,ME,IR,DR,RI,LE> CR: 48428284 XER: 00000000
[ 312.496132][ T1344] CFAR: c000000000ef28b8 IRQMASK: 3
[ 312.496132][ T1344] GPR00: c000000000ef15e4 c00000001eb4bca0 c000000001a53900 0000000000000001
[ 312.496132][ T1344] GPR04: c0000000017e7230 4000000000000000 3ffffffffffffffe 0000000000006d66
[ 312.496132][ T1344] GPR08: c00000001ec6fe80 0000000000000001 c00000000e72d380 0000000000001001
[ 312.496132][ T1344] GPR12: 0000000000000010 c00000001ec6fe80 00000100235ad1d0 000000013c2fb738
[ 312.496132][ T1344] GPR16: 000000013c210ae0 0000000000000000 0000000022000000 00000100235af740
[ 312.496132][ T1344] GPR20: 0000000000000000 0000000000000001 000000013c2a3ca0 c000000033c50040
[ 312.496132][ T1344] GPR24: c0000000100fbd80 0000000000000000 c000000001a7dc78 0000000000000001
[ 312.496132][ T1344] GPR28: c00000001eb4bd60 0000000000000001 0000000000000000 0000000000000001
[ 312.496229][ T1344] NIP [c000000000ef1618] machine_check_early+0x138/0x1f0
[ 312.496241][ T1344] LR [c000000000ef1600] machine_check_early+0x120/0x1f0
[ 312.496249][ T1344] Call Trace:
[ 312.496254][ T1344] [c00000001eb4bca0] [c000000000ef15e4] machine_check_early+0x104/0x1f0 (unreliable)
[ 312.496267][ T1344] [c00000001eb4bcf0] [c000000000008394] machine_check_early_common+0x134/0x1f0
[ 312.496279][ T1344] --- interrupt: 200 at lkdtm_PPC_SLB_MULTIHIT+0x128/0x138
[ 312.496290][ T1344] NIP: c0000000009cfea8 LR: c0000000009cfea0 CTR: 0000000000000000
[ 312.496298][ T1344] REGS: c00000001eb4bd60 TRAP: 0200 Not tainted (5.11.0-rc2-gcc-8.2.0-00123-g3fadced17474-dirty)
[ 312.496307][ T1344] MSR: 8000000000209033 <SF,EE,ME,IR,DR,RI,LE> CR: 24428284 XER: 00000000
[ 312.496326][ T1344] CFAR: 000000000000021c DAR: c008000003880000 DSISR: 00000080 IRQMASK: 0
[ 312.496326][ T1344] GPR00: c0000000009cfea0 c0000000100fbb80 c000000001a53900 c008000003880000
[ 312.496326][ T1344] GPR04: 00000000000000b0 c000000401023440 8e01c533000000c0 0000000000bf50d9
[ 312.496326][ T1344] GPR08: 000000000fffffff 0000000000000021 000000000000001c c008000004880000
[ 312.496326][ T1344] GPR12: 0000000048428222 c00000001ec6fe80 00000100235ad1d0 000000013c2fb738
[ 312.496326][ T1344] GPR16: 000000013c210ae0 0000000000000000 0000000022000000 00000100235af740
[ 312.496326][ T1344] GPR20: 0000000000000000 0000000000000001 000000013c2a3ca0 c000000033c50040
[ 312.496326][ T1344] GPR24: c0000000100fbd80 0000000000000000 0000000000000011 c000000001a2ffb8
[ 312.496326][ T1344] GPR28: 00000000000004b0 c000000033c50000 c000000001105298 c008000003880000
[ 312.496427][ T1344] NIP [c0000000009cfea8] lkdtm_PPC_SLB_MULTIHIT+0x128/0x138
[ 312.496437][ T1344] LR [c0000000009cfea0] lkdtm_PPC_SLB_MULTIHIT+0x120/0x138
[ 312.496446][ T1344] --- interrupt: 200
[ 312.496451][ T1344] [c0000000100fbbf0] [c0000000009cb530] lkdtm_do_action+0x40/0x80
[ 312.496462][ T1344] [c0000000100fbc10] [c0000000009cbdfc] direct_entry+0x16c/0x350
[ 312.496473][ T1344] [c0000000100fbcc0] [c0000000007a7590] full_proxy_write+0x90/0xe0
[ 312.496484][ T1344] [c0000000100fbd10] [c00000000046b090] vfs_write+0xf0/0x310
[ 312.496496][ T1344] [c0000000100fbd60] [c00000000046b48c] ksys_write+0x7c/0x140
[ 312.496507][ T1344] [c0000000100fbdb0] [c000000000036340] system_call_exception+0x1a0/0x2e0
[ 312.496518][ T1344] [c0000000100fbe10] [c00000000000d360] system_call_common+0xf0/0x27c
[ 312.496528][ T1344] Instruction dump:
[ 312.496534][ T1344] 7c7b1b78 e93a0000 75290040 41820008 480000a8 4800125d 60000000 e94d0968
[ 312.496552][ T1344] 812a0000 55290216 7d290034 5529d97e <0b090000> 812a0000 3d29ffef 912a0000
[ 312.496571][ T1344] ---[ end trace 1cd2275de93cc3c3 ]---
[ 312.500581][ T1344]
[ 312.500705][ C19] RTAS: event: 1, Type: Unknown (0), Severity: 3
[ 312.501068][ T0] ------------[ cut here ]------------
[ 312.501081][ T0] WARNING: CPU: 19 PID: 0 at kernel/rcu/tree.c:632 rcu_eqs_enter.isra.59+0x140/0x160
[ 312.501103][ T0] Modules linked in: squashfs dm_multipath scsi_dh_rdac scsi_dh_alua pseries_rng rng_core vmx_crypto gf128mul crc32c_vpmsum ip_tables x_tables autofs4
[ 312.501152][ T0] CPU: 19 PID: 0 Comm: swapper/19 Tainted: G D 5.11.0-rc2-gcc-8.2.0-00123-g3fadced17474-dirty #638
[ 312.501173][ T0] NIP: c000000000ef2830 LR: c000000000c287c0 CTR: 0000000000000000
[ 312.501187][ T0] REGS: c000000008d5fa50 TRAP: 0700 Tainted: G D (5.11.0-rc2-gcc-8.2.0-00123-g3fadced17474-dirty)
[ 312.501203][ T0] MSR: 800000000282b033 <SF,VEC,VSX,EE,FP,ME,IR,DR,RI,LE> CR: 28000248 XER: 20000009
[ 312.501248][ T0] CFAR: c000000000ef2728 IRQMASK: 1
[ 312.501248][ T0] GPR00: c000000000c287c0 c000000008d5fcf0 c000000001a53900 00000048c283bf7e
[ 312.501248][ T0] GPR04: c00000000199fae0 0000000000000001 0000000000000800 4000000000000000
[ 312.501248][ T0] GPR08: c00000001ec6fe80 c0000003fdb93980 3ffffffffffffffe 000000000098967f
[ 312.501248][ T0] GPR12: 00000000ffffffff c00000001ec6fe80 0000000000000000 000000001ef2fa60
[ 312.501248][ T0] GPR16: 0000000000000000 0000000000000000 c0000007fffebff8 c000000000051ca0
[ 312.501248][ T0] GPR20: c0000007fffec628 c00000000199fae0 0000000000000001 c0000003fdb917c8
[ 312.501248][ T0] GPR24: 0000000000000001 00000048c283bf7e 0000000000000000 0000000000000001
[ 312.501248][ T0] GPR28: c0000003fdb917c8 c00000000199fae0 0000000000000001 c0000000013d3980
[ 312.501428][ T0] NIP [c000000000ef2830] rcu_eqs_enter.isra.59+0x140/0x160
[ 312.501445][ T0] LR [c000000000c287c0] cpuidle_enter_state+0x2f0/0x540
[ 312.501469][ T0] Call Trace:
[ 312.501481][ T0] [c000000008d5fcf0] [c000000008d5fd40] 0xc000000008d5fd40 (unreliable)
[ 312.501508][ T0] [c000000008d5fd20] [c0000003fdb917c8] 0xc0000003fdb917c8
[ 312.501524][ T0] [c000000008d5fd80] [c000000000c28ab0] cpuidle_enter+0x50/0x70
[ 312.501544][ T0] [c000000008d5fdc0] [c00000000019000c] call_cpuidle+0x4c/0x80
[ 312.501564][ T0] [c000000008d5fde0] [c0000000001906a0] do_idle+0x390/0x3e0
[ 312.501581][ T0] [c000000008d5fe70] [c00000000019096c] cpu_startup_entry+0x3c/0x40
[ 312.501602][ T0] [c000000008d5fea0] [c000000000054838] start_secondary+0x5b8/0x9b0
[ 312.501619][ T0] [c000000008d5ff90] [c00000000000c654] start_secondary_prolog+0x10/0x14
[ 312.501642][ T0] Instruction dump:
[ 312.501657][ T0] 60000000 e8010040 7c0803a6 e94d0030 39200000 38210030 7fff5214 f93f00f0
[ 312.501692][ T0] ebe1fff8 4bfffd14 60000000 60000000 <0fe00000> 4bfffef8 60000000 60000000
[ 312.501721][ T0] ---[ end trace 1cd2275de93cc3c4 ]---
147 static inline void interrupt_nmi_exit_prepare(struct pt_regs *regs, struct interrupt_nmi_state *state)
148 {
149 if (!IS_ENABLED(CONFIG_PPC_BOOK3S_64) ||
150 !firmware_has_feature(FW_FEATURE_LPAR) ||
151 radix_enabled() || (mfmsr() & MSR_DR))
152 nmi_exit();
So presumably it's:
#define __nmi_exit() \
do { \
BUG_ON(!in_nmi()); \
cheers
^ permalink raw reply
* RE: [PATCH v2 1/3] powerpc: sstep: Fix load and update emulation
From: David Laight @ 2021-02-04 10:29 UTC (permalink / raw)
To: 'Segher Boessenkool', Naveen N. Rao
Cc: ravi.bangoria@linux.ibm.com, ananth@linux.ibm.com,
jniethe5@gmail.com, paulus@samba.org, Sandipan Das,
linuxppc-dev@lists.ozlabs.org, dja@axtens.net
In-Reply-To: <20210203211732.GD30983@gate.crashing.org>
From: Segher Boessenkool
> Sent: 03 February 2021 21:18
...
> Power9 does:
>
> Load with Update Instructions (RA = 0)
> EA is placed into R0.
Does that change the value of 0?
Rather reminds me of some 1960s era systems that had the small integers
at fixed (global) addresses.
FORTRAN always passes by reference, pass 0 and the address of the global
zero location was passed, the called function could change 0 to 1 for
the entire computer!
> Load with Update Instructions (RA = RT)
> The storage operand addressed by EA is accessed. The displacement
> field is added to the data returned by the load and placed into RT.
Shame that isn't standard - could be used to optimise some code.
David
-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)
^ permalink raw reply
* Re: [PATCH 01/13] powerpc/powernv: remove get_cxl_module
From: Michael Ellerman @ 2021-02-04 10:44 UTC (permalink / raw)
To: Christoph Hellwig, Frederic Barrat, Andrew Donnellan,
Maarten Lankhorst, Maxime Ripard, Thomas Zimmermann, David Airlie,
Daniel Vetter, Jessica Yu, Josh Poimboeuf, Jiri Kosina,
Miroslav Benes, Petr Mladek, Joe Lawrence
Cc: Michal Marek, linux-kbuild, Masahiro Yamada, linux-kernel,
dri-devel, live-patching, linuxppc-dev
In-Reply-To: <20210202121334.1361503-2-hch@lst.de>
Christoph Hellwig <hch@lst.de> writes:
> The static inline get_cxl_module function is entirely unused since commit
> 8bf6b91a5125a ("Revert "powerpc/powernv: Add support for the cxl kernel
> api on the real phb"), so remove it.
>
> Signed-off-by: Christoph Hellwig <hch@lst.de>
> Reviewed-by: Andrew Donnellan <ajd@linux.ibm.com>
> ---
> arch/powerpc/platforms/powernv/pci-cxl.c | 22 ----------------------
> 1 file changed, 22 deletions(-)
Acked-by: Michael Ellerman <mpe@ellerman.id.au>
cheers
^ permalink raw reply
* [PATCH v2] powerpc/uprobes: Validation for prefixed instruction
From: Ravi Bangoria @ 2021-02-04 10:47 UTC (permalink / raw)
To: mpe
Cc: ravi.bangoria, jniethe5, oleg, rostedt, linux-kernel, paulus,
sandipan, naveen.n.rao, linuxppc-dev
Don't allow Uprobe on 2nd word of a prefixed instruction. As per
ISA 3.1, prefixed instruction should not cross 64-byte boundary.
So don't allow Uprobe on such prefixed instruction as well.
There are two ways probed instruction is changed in mapped pages.
First, when Uprobe is activated, it searches for all the relevant
pages and replace instruction in them. In this case, if we notice
that probe is on the 2nd word of prefixed instruction, error out
directly. Second, when Uprobe is already active and user maps a
relevant page via mmap(), instruction is replaced via mmap() code
path. But because Uprobe is invalid, entire mmap() operation can
not be stopped. In this case just print an error and continue.
Signed-off-by: Ravi Bangoria <ravi.bangoria@linux.ibm.com>
---
v1: http://lore.kernel.org/r/20210119091234.76317-1-ravi.bangoria@linux.ibm.com
v1->v2:
- Instead of introducing new arch hook from verify_opcode(), use
existing hook arch_uprobe_analyze_insn().
- Add explicit check for prefixed instruction crossing 64-byte
boundary. If probe is on such instruction, throw an error.
arch/powerpc/kernel/uprobes.c | 66 ++++++++++++++++++++++++++++++++++-
1 file changed, 65 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/kernel/uprobes.c b/arch/powerpc/kernel/uprobes.c
index e8a63713e655..485d19a2a31f 100644
--- a/arch/powerpc/kernel/uprobes.c
+++ b/arch/powerpc/kernel/uprobes.c
@@ -7,6 +7,7 @@
* Adapted from the x86 port by Ananth N Mavinakayanahalli <ananth@in.ibm.com>
*/
#include <linux/kernel.h>
+#include <linux/highmem.h>
#include <linux/sched.h>
#include <linux/ptrace.h>
#include <linux/uprobes.h>
@@ -28,6 +29,69 @@ bool is_trap_insn(uprobe_opcode_t *insn)
return (is_trap(*insn));
}
+#ifdef CONFIG_PPC64
+static int get_instr(struct mm_struct *mm, unsigned long addr, u32 *instr)
+{
+ struct page *page;
+ struct vm_area_struct *vma;
+ void *kaddr;
+ unsigned int gup_flags = FOLL_FORCE | FOLL_SPLIT_PMD;
+
+ if (get_user_pages_remote(mm, addr, 1, gup_flags, &page, &vma, NULL) <= 0)
+ return -EINVAL;
+
+ kaddr = kmap_atomic(page);
+ *instr = *((u32 *)(kaddr + (addr & ~PAGE_MASK)));
+ kunmap_atomic(kaddr);
+ put_page(page);
+ return 0;
+}
+
+static int validate_prefixed_instr(struct mm_struct *mm, unsigned long addr)
+{
+ struct ppc_inst inst;
+ u32 prefix, suffix;
+
+ /*
+ * No need to check if addr is pointing to beginning of the
+ * page. Even if probe is on a suffix of page-unaligned
+ * prefixed instruction, hw will raise exception and kernel
+ * will send SIGBUS.
+ */
+ if (!(addr & ~PAGE_MASK))
+ return 0;
+
+ if (get_instr(mm, addr, &prefix) < 0)
+ return -EINVAL;
+ if (get_instr(mm, addr + 4, &suffix) < 0)
+ return -EINVAL;
+
+ inst = ppc_inst_prefix(prefix, suffix);
+ if (ppc_inst_prefixed(inst) && (addr & 0x3F) == 0x3C) {
+ printk_ratelimited("Cannot register a uprobe on 64 byte "
+ "unaligned prefixed instruction\n");
+ return -EINVAL;
+ }
+
+ suffix = prefix;
+ if (get_instr(mm, addr - 4, &prefix) < 0)
+ return -EINVAL;
+
+ inst = ppc_inst_prefix(prefix, suffix);
+ if (ppc_inst_prefixed(inst)) {
+ printk_ratelimited("Cannot register a uprobe on the second "
+ "word of prefixed instruction\n");
+ return -EINVAL;
+ }
+ return 0;
+}
+#else
+static int validate_prefixed_instr(struct mm_struct *mm, unsigned long addr)
+{
+ return 0;
+}
+#endif
+
/**
* arch_uprobe_analyze_insn
* @mm: the probed address space.
@@ -41,7 +105,7 @@ int arch_uprobe_analyze_insn(struct arch_uprobe *auprobe,
if (addr & 0x03)
return -EINVAL;
- return 0;
+ return validate_prefixed_instr(mm, addr);
}
/*
--
2.26.2
^ permalink raw reply related
* Re: [PATCH v2] powerpc/uprobes: Validation for prefixed instruction
From: Ravi Bangoria @ 2021-02-04 10:49 UTC (permalink / raw)
To: mpe
Cc: Ravi Bangoria, jniethe5, oleg, rostedt, linux-kernel, paulus,
sandipan, naveen.n.rao, linuxppc-dev
In-Reply-To: <20210204104703.273429-1-ravi.bangoria@linux.ibm.com>
On 2/4/21 4:17 PM, Ravi Bangoria wrote:
> Don't allow Uprobe on 2nd word of a prefixed instruction. As per
> ISA 3.1, prefixed instruction should not cross 64-byte boundary.
> So don't allow Uprobe on such prefixed instruction as well.
>
> There are two ways probed instruction is changed in mapped pages.
> First, when Uprobe is activated, it searches for all the relevant
> pages and replace instruction in them. In this case, if we notice
> that probe is on the 2nd word of prefixed instruction, error out
> directly. Second, when Uprobe is already active and user maps a
> relevant page via mmap(), instruction is replaced via mmap() code
> path. But because Uprobe is invalid, entire mmap() operation can
> not be stopped. In this case just print an error and continue.
@mpe,
arch_uprobe_analyze_insn() can return early if
cpu_has_feature(CPU_FTR_ARCH_31) is not set. But that will
miss out a rare scenario of user running binary with prefixed
instruction on p10 predecessors. Please let me know if I
should add cpu_has_feature(CPU_FTR_ARCH_31) or not.
- Ravi
^ permalink raw reply
* [PATCH 00/20] Rid W=1 warnings in Crypto
From: Lee Jones @ 2021-02-04 11:09 UTC (permalink / raw)
To: lee.jones
Cc: Alexandre Belloni, Aymen Sghaier, Takashi Iwai, Kent Yoder,
Ayush Sawal, Joakim Bech, Gustavo A. R. Silva, Paul Mackerras,
Andreas Westin, Breno Leitão, Atul Gupta, Niklas Hernaeus,
M R Gowda, Herbert Xu, Horia Geantă, Rohit Maheshwari,
Nayna Jain, Manoj Malviya, Ludovic Desroches, Jonas Linde,
Rob Rice, Zaibo Xu, Harsh Jain, Declan Murphy, Vinay Kumar Yadav,
Tudor Ambarus, Nicolas Ferre, Shujuan Chen, Henrique Cerri,
Daniele Alessandrelli, linux-arm-kernel, Jonathan Cameron,
linux-kernel, Berne Hebark, linux-crypto, Jitendra Lulla,
Paulo Flabiano Smorigo, linuxppc-dev, David S. Miller
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.
This is set 1 of 2 sets required to fully clean Crypto.
Lee Jones (20):
crypto: hisilicon: sec_drv: Supply missing description for
'sec_queue_empty()'s 'queue' param
crypto: bcm: util: Repair a couple of documentation formatting issues
crypto: chelsio: chcr_core: File headers are not good candidates for
kernel-doc
crypto: ux500: hash: hash_core: Fix worthy kernel-doc headers and
remove others
crypto: bcm: spu: Fix formatting and misspelling issues
crypto: keembay: ocs-hcu: Fix incorrectly named functions/structs
crypto: bcm: spu2: Fix a whole host of kernel-doc misdemeanours
crypto: ux500: cryp: Demote some conformant non-kernel headers fix
another
crypto: ux500: cryp_irq: File headers are not good kernel-doc
candidates
crypto: chelsio: chcr_algo: Fix a couple of kernel-doc issues caused
by doc-rot
crypto: ux500: cryp_core: Fix formatting issue and add description for
'session_id'
crypto: atmel-ecc: Struct headers need to start with keyword 'struct'
crypto: bcm: cipher: Provide description for 'req' and fix formatting
issues
crypto: caam: caampkc: Provide the name of the function
crypto: caam: caamalg_qi2: Supply a couple of 'fallback' related
descriptions
crypto: vmx: Source headers are not good kernel-doc candidates
crypto: nx: nx-aes-cbc: Headers comments should not be kernel-doc
crypto: nx: nx_debugfs: Header comments should not be kernel-doc
crypto: nx: Demote header comment and add description for 'nbytes'
crypto: cavium: nitrox_isr: Demote non-compliant kernel-doc headers
drivers/crypto/atmel-ecc.c | 2 +-
drivers/crypto/bcm/cipher.c | 7 ++--
drivers/crypto/bcm/spu.c | 16 ++++-----
drivers/crypto/bcm/spu2.c | 43 +++++++++++++----------
drivers/crypto/bcm/util.c | 4 +--
drivers/crypto/caam/caamalg_qi2.c | 2 ++
drivers/crypto/caam/caampkc.c | 3 +-
drivers/crypto/cavium/nitrox/nitrox_isr.c | 4 +--
drivers/crypto/chelsio/chcr_algo.c | 8 ++---
drivers/crypto/chelsio/chcr_core.c | 2 +-
drivers/crypto/hisilicon/sec/sec_drv.c | 1 +
drivers/crypto/keembay/ocs-hcu.c | 6 ++--
drivers/crypto/nx/nx-aes-cbc.c | 2 +-
drivers/crypto/nx/nx.c | 5 +--
drivers/crypto/nx/nx_debugfs.c | 2 +-
drivers/crypto/ux500/cryp/cryp.c | 5 +--
drivers/crypto/ux500/cryp/cryp_core.c | 5 +--
drivers/crypto/ux500/cryp/cryp_irq.c | 2 +-
drivers/crypto/ux500/hash/hash_core.c | 15 +++-----
drivers/crypto/vmx/vmx.c | 2 +-
20 files changed, 71 insertions(+), 65 deletions(-)
Cc: Alexandre Belloni <alexandre.belloni@bootlin.com>
Cc: Andreas Westin <andreas.westin@stericsson.com>
Cc: Atul Gupta <atul.gupta@chelsio.com>
Cc: Aymen Sghaier <aymen.sghaier@nxp.com>
Cc: Ayush Sawal <ayush.sawal@chelsio.com>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Berne Hebark <berne.herbark@stericsson.com>
Cc: "Breno Leitão" <leitao@debian.org>
Cc: Daniele Alessandrelli <daniele.alessandrelli@intel.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Declan Murphy <declan.murphy@intel.com>
Cc: "Gustavo A. R. Silva" <gustavoars@kernel.org>
Cc: Harsh Jain <harsh@chelsio.com>
Cc: Henrique Cerri <mhcerri@br.ibm.com>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: "Horia Geantă" <horia.geanta@nxp.com>
Cc: Jitendra Lulla <jlulla@chelsio.com>
Cc: Joakim Bech <joakim.xx.bech@stericsson.com>
Cc: Jonas Linde <jonas.linde@stericsson.com>
Cc: Jonathan Cameron <jonathan.cameron@huawei.com>
Cc: Kent Yoder <yoder1@us.ibm.com>
Cc: linux-arm-kernel@lists.infradead.org
Cc: linux-crypto@vger.kernel.org
Cc: linuxppc-dev@lists.ozlabs.org
Cc: Ludovic Desroches <ludovic.desroches@microchip.com>
Cc: Manoj Malviya <manojmalviya@chelsio.com>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: M R Gowda <yeshaswi@chelsio.com>
Cc: Nayna Jain <nayna@linux.ibm.com>
Cc: Nicolas Ferre <nicolas.ferre@microchip.com>
Cc: Niklas Hernaeus <niklas.hernaeus@stericsson.com>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Paulo Flabiano Smorigo <pfsmorigo@gmail.com>
Cc: Rob Rice <rob.rice@broadcom.com>
Cc: Rohit Maheshwari <rohitm@chelsio.com>
Cc: Shujuan Chen <shujuan.chen@stericsson.com>
Cc: Takashi Iwai <tiwai@suse.de>
Cc: Tudor Ambarus <tudor.ambarus@microchip.com>
Cc: Vinay Kumar Yadav <vinay.yadav@chelsio.com>
Cc: Zaibo Xu <xuzaibo@huawei.com>
--
2.25.1
^ permalink raw reply
* [PATCH 19/20] crypto: nx: Demote header comment and add description for 'nbytes'
From: Lee Jones @ 2021-02-04 11:09 UTC (permalink / raw)
To: lee.jones
Cc: Herbert Xu, Kent Yoder, Nayna Jain, linux-kernel,
Paulo Flabiano Smorigo, linux-crypto, Breno Leitão,
Paul Mackerras, linuxppc-dev, David S. Miller
In-Reply-To: <20210204111000.2800436-1-lee.jones@linaro.org>
Fixes the following W=1 kernel build warning(s):
drivers/crypto/nx/nx.c:31: warning: Incorrect use of kernel-doc format: * nx_hcall_sync - make an H_COP_OP hcall for the passed in op structure
drivers/crypto/nx/nx.c:43: warning: Function parameter or member 'nx_ctx' not described in 'nx_hcall_sync'
drivers/crypto/nx/nx.c:43: warning: Function parameter or member 'op' not described in 'nx_hcall_sync'
drivers/crypto/nx/nx.c:43: warning: Function parameter or member 'may_sleep' not described in 'nx_hcall_sync'
drivers/crypto/nx/nx.c:43: warning: expecting prototype for Nest Accelerators driver(). Prototype was for nx_hcall_sync() instead
drivers/crypto/nx/nx.c:209: warning: Function parameter or member 'nbytes' not described in 'trim_sg_list'
Cc: "Breno Leitão" <leitao@debian.org>
Cc: Nayna Jain <nayna@linux.ibm.com>
Cc: Paulo Flabiano Smorigo <pfsmorigo@gmail.com>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Kent Yoder <yoder1@us.ibm.com>
Cc: linux-crypto@vger.kernel.org
Cc: linuxppc-dev@lists.ozlabs.org
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
drivers/crypto/nx/nx.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/crypto/nx/nx.c b/drivers/crypto/nx/nx.c
index 0d2dc5be7f192..010be6793c9fc 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.
@@ -200,7 +200,8 @@ struct nx_sg *nx_walk_and_build(struct nx_sg *nx_dst,
* @sg: sg list head
* @end: sg lisg end
* @delta: is the amount we need to crop in order to bound the list.
- *
+ * @nbytes: length of data in the scatterlists or data length - whichever
+ * is greater.
*/
static long int trim_sg_list(struct nx_sg *sg,
struct nx_sg *end,
--
2.25.1
^ permalink raw reply related
* [PATCH 17/20] crypto: nx: nx-aes-cbc: Headers comments should not be kernel-doc
From: Lee Jones @ 2021-02-04 11:09 UTC (permalink / raw)
To: lee.jones
Cc: Herbert Xu, Kent Yoder, Nayna Jain, linux-kernel,
Paulo Flabiano Smorigo, linux-crypto, Breno Leitão,
Paul Mackerras, linuxppc-dev, David S. Miller
In-Reply-To: <20210204111000.2800436-1-lee.jones@linaro.org>
Fixes the following W=1 kernel build warning(s):
drivers/crypto/nx/nx-aes-cbc.c:24: warning: Function parameter or member 'tfm' not described in 'cbc_aes_nx_set_key'
drivers/crypto/nx/nx-aes-cbc.c:24: warning: Function parameter or member 'in_key' not described in 'cbc_aes_nx_set_key'
drivers/crypto/nx/nx-aes-cbc.c:24: warning: Function parameter or member 'key_len' not described in 'cbc_aes_nx_set_key'
drivers/crypto/nx/nx-aes-cbc.c:24: warning: expecting prototype for Nest Accelerators driver(). Prototype was for cbc_aes_nx_set_key() instead
Cc: "Breno Leitão" <leitao@debian.org>
Cc: Nayna Jain <nayna@linux.ibm.com>
Cc: Paulo Flabiano Smorigo <pfsmorigo@gmail.com>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Kent Yoder <yoder1@us.ibm.com>
Cc: linux-crypto@vger.kernel.org
Cc: linuxppc-dev@lists.ozlabs.org
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
drivers/crypto/nx/nx-aes-cbc.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/crypto/nx/nx-aes-cbc.c b/drivers/crypto/nx/nx-aes-cbc.c
index 92e921eceed75..d6314ea9ae896 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.
--
2.25.1
^ permalink raw reply related
* [PATCH 16/20] crypto: vmx: Source headers are not good kernel-doc candidates
From: Lee Jones @ 2021-02-04 11:09 UTC (permalink / raw)
To: lee.jones
Cc: Herbert Xu, Nayna Jain, linux-kernel, Henrique Cerri,
Paulo Flabiano Smorigo, linux-crypto, Breno Leitão,
Paul Mackerras, linuxppc-dev, David S. Miller
In-Reply-To: <20210204111000.2800436-1-lee.jones@linaro.org>
Fixes the following W=1 kernel build warning(s):
drivers/crypto/vmx/vmx.c:23: warning: expecting prototype for Routines supporting VMX instructions on the Power 8(). Prototype was for p8_init() instead
Cc: "Breno Leitão" <leitao@debian.org>
Cc: Nayna Jain <nayna@linux.ibm.com>
Cc: Paulo Flabiano Smorigo <pfsmorigo@gmail.com>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Henrique Cerri <mhcerri@br.ibm.com>
Cc: linux-crypto@vger.kernel.org
Cc: linuxppc-dev@lists.ozlabs.org
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
drivers/crypto/vmx/vmx.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/crypto/vmx/vmx.c b/drivers/crypto/vmx/vmx.c
index a40d08e75fc0b..7eb713cc87c8c 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.25.1
^ permalink raw reply related
* [PATCH 18/20] crypto: nx: nx_debugfs: Header comments should not be kernel-doc
From: Lee Jones @ 2021-02-04 11:09 UTC (permalink / raw)
To: lee.jones
Cc: Herbert Xu, Kent Yoder, Nayna Jain, linux-kernel,
Paulo Flabiano Smorigo, linux-crypto, Breno Leitão,
Paul Mackerras, linuxppc-dev, David S. Miller
In-Reply-To: <20210204111000.2800436-1-lee.jones@linaro.org>
Fixes the following W=1 kernel build warning(s):
drivers/crypto/nx/nx_debugfs.c:34: warning: Function parameter or member 'drv' not described in 'nx_debugfs_init'
drivers/crypto/nx/nx_debugfs.c:34: warning: expecting prototype for Nest Accelerators driver(). Prototype was for nx_debugfs_init() instead
Cc: "Breno Leitão" <leitao@debian.org>
Cc: Nayna Jain <nayna@linux.ibm.com>
Cc: Paulo Flabiano Smorigo <pfsmorigo@gmail.com>
Cc: Michael Ellerman <mpe@ellerman.id.au>
Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
Cc: Paul Mackerras <paulus@samba.org>
Cc: Herbert Xu <herbert@gondor.apana.org.au>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Kent Yoder <yoder1@us.ibm.com>
Cc: linux-crypto@vger.kernel.org
Cc: linuxppc-dev@lists.ozlabs.org
Signed-off-by: Lee Jones <lee.jones@linaro.org>
---
drivers/crypto/nx/nx_debugfs.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/crypto/nx/nx_debugfs.c b/drivers/crypto/nx/nx_debugfs.c
index 1975bcbee9974..ee7cd88bb10a7 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.25.1
^ permalink raw reply related
* Re: [PATCH] powerpc64/idle: Fix SP offsets when saving GPRs
From: Michael Ellerman @ 2021-02-04 11:13 UTC (permalink / raw)
To: Nicholas Piggin, Christopher M. Riedl, linuxppc-dev
In-Reply-To: <1612429032.j2hz14yfcw.astroid@bobo.none>
Nicholas Piggin <npiggin@gmail.com> writes:
> Excerpts from Christopher M. Riedl's message of February 4, 2021 4:59 pm:
>> On Sat Jan 30, 2021 at 7:44 AM CST, Nicholas Piggin wrote:
>>> Excerpts from Michael Ellerman's message of January 30, 2021 9:32 pm:
>>> > "Christopher M. Riedl" <cmr@codefail.de> writes:
>>> >> The idle entry/exit code saves/restores GPRs in the stack "red zone"
>>> >> (Protected Zone according to PowerPC64 ELF ABI v2). However, the offset
>>> >> used for the first GPR is incorrect and overwrites the back chain - the
>>> >> Protected Zone actually starts below the current SP. In practice this is
>>> >> probably not an issue, but it's still incorrect so fix it.
>>> >
>>> > Nice catch.
>>> >
>>> > Corrupting the back chain means you can't backtrace from there, which
>>> > could be confusing for debugging one day.
>>>
>>> Yeah, we seem to have got away without noticing because the CPU will
>>> wake up and return out of here before it tries to unwind the stack,
>>> but if you tried to walk it by hand if the CPU got stuck in idle or
>>> something, then we'd get confused.
>>>
>>> > It does make me wonder why we don't just create a stack frame and use
>>> > the normal macros? It would use a bit more stack space, but we shouldn't
>>> > be short of stack space when going idle.
>>> >
>>> > Nick, was there a particular reason for using the red zone?
>>>
>>> I don't recall a particular reason, I think a normal stack frame is
>>> probably a good idea.
>>
>> I'll send a version using STACKFRAMESIZE - I assume that's the "normal"
>> stack frame :)
>>
>
> I think STACKFRAMESIZE is STACK_FRAME_OVERHEAD + NVGPRs. LR and CR can
> be saved in the caller's frame so that should be okay.
TBH I didn't know/had forgotten we had STACKFRAMESIZE.
The safest is SWITCH_FRAME_SIZE, because it's calculated based on
pt_regs (which can change size):
DEFINE(SWITCH_FRAME_SIZE, STACK_FRAME_OVERHEAD + sizeof(struct pt_regs));
But the name is obviously terrible for your usage, and it will allocate
a bit more space than you need, because pt_regs has more than just the GPRs.
>> I admit I am a bit confused when I saw the similar but much smaller
>> STACK_FRAME_OVERHEAD which is also used in _some_ cases to save/restore
>> a few registers.
>
> Yeah if you don't need to save all nvgprs you can use caller's frame
> plus a few bytes in the minimum frame as volatile storage.
>
> STACK_FRAME_OVERHEAD should be 32 on LE, but I think the problem is a
> lot of asm uses it and hasn't necessarily been audited to make sure it's
> not assuming it's bigger.
Yeah it's a total mess. See this ~3.5 year old issue :/
https://github.com/linuxppc/issues/issues/113
> You could actually use STACK_FRAME_MIN_SIZE for new code, maybe we add
> a STACK_FRAME_MIN_NVGPR_SIZE to match and use that.
Something like that makes me nervous because it's so easy to
accidentally use one of the macros that expects a full pt_regs.
I think ideally you have just two options.
Option 1:
You use:
STACK_FRAME_WITH_PT_REGS = STACK_FRAME_MIN_SIZE + sizeof(struct pt_regs)
And then you can use all the macros in asm-offsets.c generated with
STACK_PT_REGS_OFFSET.
Option 2:
If you want to be fancy you manually allocate your frame with just
the right amount of space, but with the size there in the code, so for
example the idle code that wants 19 GPRs would do:
stdu r1, -(STACK_FRAME_MIN_SIZE + 8 * 19)(r1)
And then it's very obvious that you have a non-standard frame size and
need to be more careful.
cheers
^ permalink raw reply
* Re: [PATCH] powerpc64/idle: Fix SP offsets when saving GPRs
From: Nicholas Piggin @ 2021-02-04 11:26 UTC (permalink / raw)
To: Christopher M. Riedl, linuxppc-dev, Michael Ellerman
In-Reply-To: <87eehwozkj.fsf@mpe.ellerman.id.au>
Excerpts from Michael Ellerman's message of February 4, 2021 9:13 pm:
> Nicholas Piggin <npiggin@gmail.com> writes:
>> Excerpts from Christopher M. Riedl's message of February 4, 2021 4:59 pm:
>>> On Sat Jan 30, 2021 at 7:44 AM CST, Nicholas Piggin wrote:
>>>> Excerpts from Michael Ellerman's message of January 30, 2021 9:32 pm:
>>>> > "Christopher M. Riedl" <cmr@codefail.de> writes:
>>>> >> The idle entry/exit code saves/restores GPRs in the stack "red zone"
>>>> >> (Protected Zone according to PowerPC64 ELF ABI v2). However, the offset
>>>> >> used for the first GPR is incorrect and overwrites the back chain - the
>>>> >> Protected Zone actually starts below the current SP. In practice this is
>>>> >> probably not an issue, but it's still incorrect so fix it.
>>>> >
>>>> > Nice catch.
>>>> >
>>>> > Corrupting the back chain means you can't backtrace from there, which
>>>> > could be confusing for debugging one day.
>>>>
>>>> Yeah, we seem to have got away without noticing because the CPU will
>>>> wake up and return out of here before it tries to unwind the stack,
>>>> but if you tried to walk it by hand if the CPU got stuck in idle or
>>>> something, then we'd get confused.
>>>>
>>>> > It does make me wonder why we don't just create a stack frame and use
>>>> > the normal macros? It would use a bit more stack space, but we shouldn't
>>>> > be short of stack space when going idle.
>>>> >
>>>> > Nick, was there a particular reason for using the red zone?
>>>>
>>>> I don't recall a particular reason, I think a normal stack frame is
>>>> probably a good idea.
>>>
>>> I'll send a version using STACKFRAMESIZE - I assume that's the "normal"
>>> stack frame :)
>>>
>>
>> I think STACKFRAMESIZE is STACK_FRAME_OVERHEAD + NVGPRs. LR and CR can
>> be saved in the caller's frame so that should be okay.
>
> TBH I didn't know/had forgotten we had STACKFRAMESIZE.
>
> The safest is SWITCH_FRAME_SIZE, because it's calculated based on
> pt_regs (which can change size):
>
> DEFINE(SWITCH_FRAME_SIZE, STACK_FRAME_OVERHEAD + sizeof(struct pt_regs));
>
> But the name is obviously terrible for your usage, and it will allocate
> a bit more space than you need, because pt_regs has more than just the GPRs.
I don't see why that's safer if we're not using pt_regs.
>
>>> I admit I am a bit confused when I saw the similar but much smaller
>>> STACK_FRAME_OVERHEAD which is also used in _some_ cases to save/restore
>>> a few registers.
>>
>> Yeah if you don't need to save all nvgprs you can use caller's frame
>> plus a few bytes in the minimum frame as volatile storage.
>>
>> STACK_FRAME_OVERHEAD should be 32 on LE, but I think the problem is a
>> lot of asm uses it and hasn't necessarily been audited to make sure it's
>> not assuming it's bigger.
>
> Yeah it's a total mess. See this ~3.5 year old issue :/
>
> https://github.com/linuxppc/issues/issues/113
>
>> You could actually use STACK_FRAME_MIN_SIZE for new code, maybe we add
>> a STACK_FRAME_MIN_NVGPR_SIZE to match and use that.
>
> Something like that makes me nervous because it's so easy to
> accidentally use one of the macros that expects a full pt_regs.
>
> I think ideally you have just two options.
>
> Option 1:
>
> You use:
> STACK_FRAME_WITH_PT_REGS = STACK_FRAME_MIN_SIZE + sizeof(struct pt_regs)
>
> And then you can use all the macros in asm-offsets.c generated with
> STACK_PT_REGS_OFFSET.
I don't see a good reason to use pt_regs here, but in general sure this
would be good to have and begin using.
> Option 2:
>
> If you want to be fancy you manually allocate your frame with just
> the right amount of space, but with the size there in the code, so for
> example the idle code that wants 19 GPRs would do:
>
> stdu r1, -(STACK_FRAME_MIN_SIZE + 8 * 19)(r1)
>
> And then it's very obvious that you have a non-standard frame size and
> need to be more careful.
I would be happy with this for the idle code.
Thanks,
Nick
^ permalink raw reply
* [PATCH] powerpc/kexec_file: fix FDT size estimation for kdump kernel
From: Hari Bathini @ 2021-02-04 11:31 UTC (permalink / raw)
To: Michael Ellerman
Cc: Pingfan Liu, Petr Tesarik, Mahesh J Salgaonkar, Sourabh Jain,
linuxppc-dev, stable, Dave Young, Thiago Jung Bauermann
On systems with large amount of memory, loading kdump kernel through
kexec_file_load syscall may fail with the below error:
"Failed to update fdt with linux,drconf-usable-memory property"
This happens because the size estimation for kdump kernel's FDT does
not account for the additional space needed to setup usable memory
properties. Fix it by accounting for the space needed to include
linux,usable-memory & linux,drconf-usable-memory properties while
estimating kdump kernel's FDT size.
Fixes: 6ecd0163d360 ("powerpc/kexec_file: Add appropriate regions for memory reserve map")
Cc: stable@vger.kernel.org
Signed-off-by: Hari Bathini <hbathini@linux.ibm.com>
---
arch/powerpc/include/asm/kexec.h | 1 +
arch/powerpc/kexec/elf_64.c | 2 +-
arch/powerpc/kexec/file_load_64.c | 34 ++++++++++++++++++++++++++++++++++
3 files changed, 36 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/include/asm/kexec.h b/arch/powerpc/include/asm/kexec.h
index 55d6ede30c19..9ab344d29a54 100644
--- a/arch/powerpc/include/asm/kexec.h
+++ b/arch/powerpc/include/asm/kexec.h
@@ -136,6 +136,7 @@ int load_crashdump_segments_ppc64(struct kimage *image,
int setup_purgatory_ppc64(struct kimage *image, const void *slave_code,
const void *fdt, unsigned long kernel_load_addr,
unsigned long fdt_load_addr);
+unsigned int kexec_fdt_totalsize_ppc64(struct kimage *image);
int setup_new_fdt_ppc64(const struct kimage *image, void *fdt,
unsigned long initrd_load_addr,
unsigned long initrd_len, const char *cmdline);
diff --git a/arch/powerpc/kexec/elf_64.c b/arch/powerpc/kexec/elf_64.c
index d0e459bb2f05..9842e33533df 100644
--- a/arch/powerpc/kexec/elf_64.c
+++ b/arch/powerpc/kexec/elf_64.c
@@ -102,7 +102,7 @@ static void *elf64_load(struct kimage *image, char *kernel_buf,
pr_debug("Loaded initrd at 0x%lx\n", initrd_load_addr);
}
- fdt_size = fdt_totalsize(initial_boot_params) * 2;
+ fdt_size = kexec_fdt_totalsize_ppc64(image);
fdt = kmalloc(fdt_size, GFP_KERNEL);
if (!fdt) {
pr_err("Not enough memory for the device tree.\n");
diff --git a/arch/powerpc/kexec/file_load_64.c b/arch/powerpc/kexec/file_load_64.c
index c69bcf9b547a..67fa7bfcfa30 100644
--- a/arch/powerpc/kexec/file_load_64.c
+++ b/arch/powerpc/kexec/file_load_64.c
@@ -21,6 +21,7 @@
#include <linux/memblock.h>
#include <linux/slab.h>
#include <linux/vmalloc.h>
+#include <asm/setup.h>
#include <asm/drmem.h>
#include <asm/kexec_ranges.h>
#include <asm/crashdump-ppc64.h>
@@ -925,6 +926,39 @@ int setup_purgatory_ppc64(struct kimage *image, const void *slave_code,
return ret;
}
+/**
+ * kexec_fdt_totalsize_ppc64 - Return the estimated size needed to setup FDT
+ * for kexec/kdump kernel.
+ * @image: kexec image being loaded.
+ *
+ * Returns the estimated size needed for kexec/kdump kernel FDT.
+ */
+unsigned int kexec_fdt_totalsize_ppc64(struct kimage *image)
+{
+ unsigned int fdt_size;
+ uint64_t usm_entries;
+
+ /*
+ * The below estimate more than accounts for a typical kexec case where
+ * the additional space is to accommodate things like kexec cmdline,
+ * chosen node with properties for initrd start & end addresses and
+ * a property to indicate kexec boot..
+ */
+ fdt_size = fdt_totalsize(initial_boot_params) + (2 * COMMAND_LINE_SIZE);
+ if (image->type != KEXEC_TYPE_CRASH)
+ return fdt_size;
+
+ /*
+ * For kdump kernel, also account for linux,usable-memory and
+ * linux,drconf-usable-memory properties. Get an approximate on the
+ * number of usable memory entries and use for FDT size estimation.
+ */
+ usm_entries = ((memblock_end_of_DRAM() / drmem_lmb_size()) +
+ (2 * (resource_size(&crashk_res) / drmem_lmb_size())));
+ fdt_size += (unsigned int)(usm_entries * sizeof(uint64_t));
+ return fdt_size;
+}
+
/**
* setup_new_fdt_ppc64 - Update the flattend device-tree of the kernel
* being loaded.
^ permalink raw reply related
* Re: [PATCH v7 39/42] powerpc: move NMI entry/exit code into wrapper
From: Nicholas Piggin @ 2021-02-04 11:31 UTC (permalink / raw)
To: linuxppc-dev, Michael Ellerman; +Cc: Athira Rajeev
In-Reply-To: <87k0rop29e.fsf@mpe.ellerman.id.au>
Excerpts from Michael Ellerman's message of February 4, 2021 8:15 pm:
> Nicholas Piggin <npiggin@gmail.com> writes:
>> This moves the common NMI entry and exit code into the interrupt handler
>> wrappers.
>>
>> This changes the behaviour of soft-NMI (watchdog) and HMI interrupts, and
>> also MCE interrupts on 64e, by adding missing parts of the NMI entry to
>> them.
>>
>> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
>> ---
>> arch/powerpc/include/asm/interrupt.h | 28 ++++++++++++++++++++++
>> arch/powerpc/kernel/mce.c | 11 ---------
>> arch/powerpc/kernel/traps.c | 35 +++++-----------------------
>> arch/powerpc/kernel/watchdog.c | 10 ++++----
>> 4 files changed, 38 insertions(+), 46 deletions(-)
>
> This is unhappy when injecting SLB multi-hits:
>
> root@p86-2:~# echo PPC_SLB_MULTIHIT > /sys/kernel/debug/provoke-crash/DIRECT
> [ 312.496026][ T1344] kernel BUG at arch/powerpc/include/asm/interrupt.h:152!
> [ 312.496037][ T1344] Oops: Exception in kernel mode, sig: 5 [#1]
> [ 312.496045][ T1344] LE PAGE_SIZE=64K MMU=Hash SMP NR_CPUS=2048 NUMA pSeries
pseries hash. Blast!
> 147 static inline void interrupt_nmi_exit_prepare(struct pt_regs *regs, struct interrupt_nmi_state *state)
> 148 {
> 149 if (!IS_ENABLED(CONFIG_PPC_BOOK3S_64) ||
> 150 !firmware_has_feature(FW_FEATURE_LPAR) ||
> 151 radix_enabled() || (mfmsr() & MSR_DR))
> 152 nmi_exit();
>
>
> So presumably it's:
>
> #define __nmi_exit() \
> do { \
> BUG_ON(!in_nmi()); \
Yes that would be it, pseries machine check enables MMU half way through
so only one side of this triggers.
The MSR_DR check is supposed to catch the other NMIs that run with MMU
on (perf, watchdog, etc). Suppose it could test TRAP(regs) explicitly
although I wonder if we should also do this to keep things balanced
diff --git a/arch/powerpc/platforms/pseries/ras.c b/arch/powerpc/platforms/pseries/ras.c
index 149cec2212e6..f57ca0c570be 100644
--- a/arch/powerpc/platforms/pseries/ras.c
+++ b/arch/powerpc/platforms/pseries/ras.c
@@ -719,6 +719,7 @@ static int mce_handle_err_virtmode(struct pt_regs *regs,
static int mce_handle_error(struct pt_regs *regs, struct rtas_error_log *errp)
{
+ unsigned long msr;
struct pseries_errorlog *pseries_log;
struct pseries_mc_errorlog *mce_log = NULL;
int disposition = rtas_error_disposition(errp);
@@ -747,9 +748,12 @@ static int mce_handle_error(struct pt_regs *regs, struct rtas_error_log *errp)
* SLB multihit is done by now.
*/
out:
- mtmsr(mfmsr() | MSR_IR | MSR_DR);
+ msr = mfmsr();
+ mtmsr(msr | MSR_IR | MSR_DR);
disposition = mce_handle_err_virtmode(regs, errp, mce_log,
disposition);
+ mtmsr(msr);
+
return disposition;
}
^ permalink raw reply related
* Re: [PATCH RFC v1 2/6] swiotlb: convert variables to arrays
From: Robin Murphy @ 2021-02-04 11:49 UTC (permalink / raw)
To: Christoph Hellwig, Dongli Zhang
Cc: ulf.hansson, airlied, joonas.lahtinen, dri-devel, linux-kernel,
bhelgaas, paulus, hpa, mingo, m.szyprowski, sstabellini,
adrian.hunter, x86, joe.jin, peterz, mingo, bskeggs, linux-pci,
xen-devel, matthew.auld, thomas.lendacky, konrad.wilk, intel-gfx,
jani.nikula, bp, rodrigo.vivi, nouveau, Claire Chang,
boris.ostrovsky, chris, jgross, tsbogend, linux-mmc, linux-mips,
iommu, tglx, bauerman, daniel, akpm, linuxppc-dev, rppt
In-Reply-To: <20210204072947.GA29812@lst.de>
On 2021-02-04 07:29, Christoph Hellwig wrote:
> On Wed, Feb 03, 2021 at 03:37:05PM -0800, Dongli Zhang wrote:
>> This patch converts several swiotlb related variables to arrays, in
>> order to maintain stat/status for different swiotlb buffers. Here are
>> variables involved:
>>
>> - io_tlb_start and io_tlb_end
>> - io_tlb_nslabs and io_tlb_used
>> - io_tlb_list
>> - io_tlb_index
>> - max_segment
>> - io_tlb_orig_addr
>> - no_iotlb_memory
>>
>> There is no functional change and this is to prepare to enable 64-bit
>> swiotlb.
>
> Claire Chang (on Cc) already posted a patch like this a month ago,
> which looks much better because it actually uses a struct instead
> of all the random variables.
Indeed, I skimmed the cover letter and immediately thought that this
whole thing is just the restricted DMA pool concept[1] again, only from
a slightly different angle.
Robin.
[1]
https://lore.kernel.org/linux-iommu/20210106034124.30560-1-tientzu@chromium.org/
^ permalink raw reply
* Re: [PATCH] tools/perf: Fix powerpc gap between kernel end and module start
From: Athira Rajeev @ 2021-02-04 12:11 UTC (permalink / raw)
To: Arnaldo Carvalho de Melo
Cc: linuxppc-dev, Madhavan Srinivasan, Jiri Olsa, Jiri Olsa,
Kajol Jain
In-Reply-To: <20210203153148.GC854763@kernel.org>
> On 03-Feb-2021, at 9:01 PM, Arnaldo Carvalho de Melo <acme@kernel.org> wrote:
>
> Thanks, collected the Tested-by from Kajol and the Acked-by from Jiri
> and applied to my local tree for testing, then up to my perf/core
> branch.
>
> - Arnaldo
Thanks Arnaldo for taking this fix.
^ permalink raw reply
* Re: [PATCH 3/3] tools/perf: Add perf tools support to expose Performance Monitor Counter SPRs as part of extended regs
From: Athira Rajeev @ 2021-02-04 12:14 UTC (permalink / raw)
To: Arnaldo Carvalho de Melo; +Cc: kjain, Madhavan Srinivasan, linuxppc-dev, jolsa
In-Reply-To: <20210203162520.GG854763@kernel.org>
> On 03-Feb-2021, at 9:55 PM, Arnaldo Carvalho de Melo <acme@kernel.org> wrote:
>
> Em Wed, Feb 03, 2021 at 01:55:37AM -0500, Athira Rajeev escreveu:
>> To enable presenting of Performance Monitor Counter Registers
>> (PMC1 to PMC6) as part of extended regsiters, patch adds these
>> to sample_reg_mask in the tool side (to use with -I? option).
>>
>> Simplified the PERF_REG_PMU_MASK_300/31 definition. Excluded the
>> unsupported SPRs (MMCR3, SIER2, SIER3) from extended mask value for
>> CPU_FTR_ARCH_300.
>
> Applied just 3/3, the tooling part, to my local branch, please holler if
> I should wait a bit more.
>
> - Arnaldo
>
Thanks Arnaldo for taking the tool side changes.
Athira.
>> Signed-off-by: Athira Rajeev <atrajeev@linux.vnet.ibm.com>
>> ---
>> tools/arch/powerpc/include/uapi/asm/perf_regs.h | 28 +++++++++++++++++++------
>> tools/perf/arch/powerpc/include/perf_regs.h | 6 ++++++
>> tools/perf/arch/powerpc/util/perf_regs.c | 6 ++++++
>> 3 files changed, 34 insertions(+), 6 deletions(-)
>>
>> diff --git a/tools/arch/powerpc/include/uapi/asm/perf_regs.h b/tools/arch/powerpc/include/uapi/asm/perf_regs.h
>> index bdf5f10f8b9f..578b3ee86105 100644
>> --- a/tools/arch/powerpc/include/uapi/asm/perf_regs.h
>> +++ b/tools/arch/powerpc/include/uapi/asm/perf_regs.h
>> @@ -55,17 +55,33 @@ enum perf_event_powerpc_regs {
>> PERF_REG_POWERPC_MMCR3,
>> PERF_REG_POWERPC_SIER2,
>> PERF_REG_POWERPC_SIER3,
>> + PERF_REG_POWERPC_PMC1,
>> + PERF_REG_POWERPC_PMC2,
>> + PERF_REG_POWERPC_PMC3,
>> + PERF_REG_POWERPC_PMC4,
>> + PERF_REG_POWERPC_PMC5,
>> + PERF_REG_POWERPC_PMC6,
>> /* Max regs without the extended regs */
>> PERF_REG_POWERPC_MAX = PERF_REG_POWERPC_MMCRA + 1,
>> };
>>
>> #define PERF_REG_PMU_MASK ((1ULL << PERF_REG_POWERPC_MAX) - 1)
>>
>> -/* PERF_REG_EXTENDED_MASK value for CPU_FTR_ARCH_300 */
>> -#define PERF_REG_PMU_MASK_300 (((1ULL << (PERF_REG_POWERPC_MMCR2 + 1)) - 1) - PERF_REG_PMU_MASK)
>> -/* PERF_REG_EXTENDED_MASK value for CPU_FTR_ARCH_31 */
>> -#define PERF_REG_PMU_MASK_31 (((1ULL << (PERF_REG_POWERPC_SIER3 + 1)) - 1) - PERF_REG_PMU_MASK)
>> +/* Exclude MMCR3, SIER2, SIER3 for CPU_FTR_ARCH_300 */
>> +#define PERF_EXCLUDE_REG_EXT_300 (7ULL << PERF_REG_POWERPC_MMCR3)
>>
>> -#define PERF_REG_MAX_ISA_300 (PERF_REG_POWERPC_MMCR2 + 1)
>> -#define PERF_REG_MAX_ISA_31 (PERF_REG_POWERPC_SIER3 + 1)
>> +/*
>> + * PERF_REG_EXTENDED_MASK value for CPU_FTR_ARCH_300
>> + * includes 9 SPRS from MMCR0 to PMC6 excluding the
>> + * unsupported SPRS in PERF_EXCLUDE_REG_EXT_300.
>> + */
>> +#define PERF_REG_PMU_MASK_300 ((0xfffULL << PERF_REG_POWERPC_MMCR0) - PERF_EXCLUDE_REG_EXT_300)
>> +
>> +/*
>> + * PERF_REG_EXTENDED_MASK value for CPU_FTR_ARCH_31
>> + * includes 12 SPRs from MMCR0 to PMC6.
>> + */
>> +#define PERF_REG_PMU_MASK_31 (0xfffULL << PERF_REG_POWERPC_MMCR0)
>> +
>> +#define PERF_REG_EXTENDED_MAX (PERF_REG_POWERPC_PMC6 + 1)
>> #endif /* _UAPI_ASM_POWERPC_PERF_REGS_H */
>> diff --git a/tools/perf/arch/powerpc/include/perf_regs.h b/tools/perf/arch/powerpc/include/perf_regs.h
>> index 63f3ac91049f..98b6f9eabfc3 100644
>> --- a/tools/perf/arch/powerpc/include/perf_regs.h
>> +++ b/tools/perf/arch/powerpc/include/perf_regs.h
>> @@ -71,6 +71,12 @@
>> [PERF_REG_POWERPC_MMCR3] = "mmcr3",
>> [PERF_REG_POWERPC_SIER2] = "sier2",
>> [PERF_REG_POWERPC_SIER3] = "sier3",
>> + [PERF_REG_POWERPC_PMC1] = "pmc1",
>> + [PERF_REG_POWERPC_PMC2] = "pmc2",
>> + [PERF_REG_POWERPC_PMC3] = "pmc3",
>> + [PERF_REG_POWERPC_PMC4] = "pmc4",
>> + [PERF_REG_POWERPC_PMC5] = "pmc5",
>> + [PERF_REG_POWERPC_PMC6] = "pmc6",
>> };
>>
>> static inline const char *perf_reg_name(int id)
>> diff --git a/tools/perf/arch/powerpc/util/perf_regs.c b/tools/perf/arch/powerpc/util/perf_regs.c
>> index 2b6d4704e3aa..8116a253f91f 100644
>> --- a/tools/perf/arch/powerpc/util/perf_regs.c
>> +++ b/tools/perf/arch/powerpc/util/perf_regs.c
>> @@ -68,6 +68,12 @@
>> SMPL_REG(mmcr3, PERF_REG_POWERPC_MMCR3),
>> SMPL_REG(sier2, PERF_REG_POWERPC_SIER2),
>> SMPL_REG(sier3, PERF_REG_POWERPC_SIER3),
>> + SMPL_REG(pmc1, PERF_REG_POWERPC_PMC1),
>> + SMPL_REG(pmc2, PERF_REG_POWERPC_PMC2),
>> + SMPL_REG(pmc3, PERF_REG_POWERPC_PMC3),
>> + SMPL_REG(pmc4, PERF_REG_POWERPC_PMC4),
>> + SMPL_REG(pmc5, PERF_REG_POWERPC_PMC5),
>> + SMPL_REG(pmc6, PERF_REG_POWERPC_PMC6),
>> SMPL_REG_END
>> };
>>
>> --
>> 1.8.3.1
>>
>
> --
>
> - Arnaldo
^ permalink raw reply
* [PATCH kernel v3] powerpc/uaccess: Skip might_fault() when user access is enabled
From: Alexey Kardashevskiy @ 2021-02-04 12:16 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Alexey Kardashevskiy, Jordan Niethe, Nicholas Piggin
The amount of code executed with enabled user space access (unlocked KUAP)
should be minimal. However with CONFIG_PROVE_LOCKING or
CONFIG_DEBUG_ATOMIC_SLEEP enabled, might_fault() may end up replaying
interrupts which in turn may access the user space and forget to restore
the KUAP state.
The problem places are:
1. strncpy_from_user (and similar) which unlock KUAP and call
unsafe_get_user -> __get_user_allowed -> __get_user_nocheck()
with do_allow=false to skip KUAP as the caller took care of it.
2. __put_user_nocheck_goto() which is called with unlocked KUAP.
This changes __get_user_nocheck() to look at @do_allow to decide whether
to skip might_fault(). Since strncpy_from_user/etc call might_fault()
anyway before unlocking KUAP, there should be no visible change.
This drops might_fault() in __put_user_nocheck_goto() as it is only
called from unsafe_xxx helpers which manage KUAP themselves.
Since keeping might_fault() is still desireable, this adds those
to user_access_begin/read/write which is the last point where
we can safely do so.
Fixes: 334710b1496a ("powerpc/uaccess: Implement unsafe_put_user() using 'asm goto'")
Signed-off-by: Alexey Kardashevskiy <aik@ozlabs.ru>
---
Changes:
v3:
* removed might_fault() from __put_user_nocheck_goto
* added might_fault() to user(_|_read_|_write_)access_begin
v2:
* s/!do_allow/do_allow/
---
Here is more detail about the issue:
https://lore.kernel.org/linuxppc-dev/20210203084503.GX6564@kitsune.suse.cz/T/
Another example of the problem:
Kernel attempted to write user page (200002c3) - exploit attempt? (uid: 0)
------------[ cut here ]------------
Bug: Write fault blocked by KUAP!
WARNING: CPU: 1 PID: 16712 at /home/aik/p/kernel-syzkaller/arch/powerpc/mm/fault.c:229 __do_page_fault+0xca4/0xf10
NIP [c0000000006ff804] filldir64+0x484/0x820
LR [c0000000006ff7fc] filldir64+0x47c/0x820
--- interrupt: 300
[c0000000589f3b40] [c0000000008131b0] proc_fill_cache+0xf0/0x2b0
[c0000000589f3c60] [c000000000814658] proc_pident_readdir+0x1f8/0x390
[c0000000589f3cc0] [c0000000006fd8e8] iterate_dir+0x108/0x370
[c0000000589f3d20] [c0000000006fe3d8] sys_getdents64+0xa8/0x410
[c0000000589f3db0] [c00000000004b708] system_call_exception+0x178/0x2b0
[c0000000589f3e10] [c00000000000e060] system_call_common+0xf0/0x27c
---
arch/powerpc/include/asm/uaccess.h | 10 +++++++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/include/asm/uaccess.h b/arch/powerpc/include/asm/uaccess.h
index 501c9a79038c..a789601998d3 100644
--- a/arch/powerpc/include/asm/uaccess.h
+++ b/arch/powerpc/include/asm/uaccess.h
@@ -216,8 +216,6 @@ do { \
#define __put_user_nocheck_goto(x, ptr, size, label) \
do { \
__typeof__(*(ptr)) __user *__pu_addr = (ptr); \
- if (!is_kernel_addr((unsigned long)__pu_addr)) \
- might_fault(); \
__chk_user_ptr(ptr); \
__put_user_size_goto((x), __pu_addr, (size), label); \
} while (0)
@@ -313,7 +311,7 @@ do { \
__typeof__(size) __gu_size = (size); \
\
__chk_user_ptr(__gu_addr); \
- if (!is_kernel_addr((unsigned long)__gu_addr)) \
+ if (do_allow && !is_kernel_addr((unsigned long)__gu_addr)) \
might_fault(); \
barrier_nospec(); \
if (do_allow) \
@@ -508,6 +506,8 @@ static __must_check inline bool user_access_begin(const void __user *ptr, size_t
{
if (unlikely(!access_ok(ptr, len)))
return false;
+ if (!is_kernel_addr((unsigned long)ptr))
+ might_fault();
allow_read_write_user((void __user *)ptr, ptr, len);
return true;
}
@@ -521,6 +521,8 @@ user_read_access_begin(const void __user *ptr, size_t len)
{
if (unlikely(!access_ok(ptr, len)))
return false;
+ if (!is_kernel_addr((unsigned long)ptr))
+ might_fault();
allow_read_from_user(ptr, len);
return true;
}
@@ -532,6 +534,8 @@ user_write_access_begin(const void __user *ptr, size_t len)
{
if (unlikely(!access_ok(ptr, len)))
return false;
+ if (!is_kernel_addr((unsigned long)ptr))
+ might_fault();
allow_write_to_user((void __user *)ptr, len);
return true;
}
--
2.17.1
^ permalink raw reply related
* Re: [PATCH v2] powerpc/uprobes: Validation for prefixed instruction
From: Naveen N. Rao @ 2021-02-04 13:08 UTC (permalink / raw)
To: Ravi Bangoria
Cc: oleg, rostedt, linux-kernel, paulus, sandipan, jniethe5,
naveen.n.rao, linuxppc-dev
In-Reply-To: <20210204104703.273429-1-ravi.bangoria@linux.ibm.com>
On 2021/02/04 04:17PM, Ravi Bangoria wrote:
> Don't allow Uprobe on 2nd word of a prefixed instruction. As per
> ISA 3.1, prefixed instruction should not cross 64-byte boundary.
> So don't allow Uprobe on such prefixed instruction as well.
>
> There are two ways probed instruction is changed in mapped pages.
> First, when Uprobe is activated, it searches for all the relevant
> pages and replace instruction in them. In this case, if we notice
> that probe is on the 2nd word of prefixed instruction, error out
> directly. Second, when Uprobe is already active and user maps a
> relevant page via mmap(), instruction is replaced via mmap() code
> path. But because Uprobe is invalid, entire mmap() operation can
> not be stopped. In this case just print an error and continue.
>
> Signed-off-by: Ravi Bangoria <ravi.bangoria@linux.ibm.com>
> ---
> v1: http://lore.kernel.org/r/20210119091234.76317-1-ravi.bangoria@linux.ibm.com
> v1->v2:
> - Instead of introducing new arch hook from verify_opcode(), use
> existing hook arch_uprobe_analyze_insn().
> - Add explicit check for prefixed instruction crossing 64-byte
> boundary. If probe is on such instruction, throw an error.
>
> arch/powerpc/kernel/uprobes.c | 66 ++++++++++++++++++++++++++++++++++-
> 1 file changed, 65 insertions(+), 1 deletion(-)
>
> diff --git a/arch/powerpc/kernel/uprobes.c b/arch/powerpc/kernel/uprobes.c
> index e8a63713e655..485d19a2a31f 100644
> --- a/arch/powerpc/kernel/uprobes.c
> +++ b/arch/powerpc/kernel/uprobes.c
> @@ -7,6 +7,7 @@
> * Adapted from the x86 port by Ananth N Mavinakayanahalli <ananth@in.ibm.com>
> */
> #include <linux/kernel.h>
> +#include <linux/highmem.h>
> #include <linux/sched.h>
> #include <linux/ptrace.h>
> #include <linux/uprobes.h>
> @@ -28,6 +29,69 @@ bool is_trap_insn(uprobe_opcode_t *insn)
> return (is_trap(*insn));
> }
>
> +#ifdef CONFIG_PPC64
> +static int get_instr(struct mm_struct *mm, unsigned long addr, u32 *instr)
> +{
> + struct page *page;
> + struct vm_area_struct *vma;
> + void *kaddr;
> + unsigned int gup_flags = FOLL_FORCE | FOLL_SPLIT_PMD;
> +
> + if (get_user_pages_remote(mm, addr, 1, gup_flags, &page, &vma, NULL) <= 0)
> + return -EINVAL;
> +
> + kaddr = kmap_atomic(page);
> + *instr = *((u32 *)(kaddr + (addr & ~PAGE_MASK)));
> + kunmap_atomic(kaddr);
> + put_page(page);
> + return 0;
> +}
> +
> +static int validate_prefixed_instr(struct mm_struct *mm, unsigned long addr)
> +{
> + struct ppc_inst inst;
> + u32 prefix, suffix;
> +
> + /*
> + * No need to check if addr is pointing to beginning of the
> + * page. Even if probe is on a suffix of page-unaligned
> + * prefixed instruction, hw will raise exception and kernel
> + * will send SIGBUS.
> + */
> + if (!(addr & ~PAGE_MASK))
> + return 0;
> +
> + if (get_instr(mm, addr, &prefix) < 0)
> + return -EINVAL;
> + if (get_instr(mm, addr + 4, &suffix) < 0)
> + return -EINVAL;
> +
> + inst = ppc_inst_prefix(prefix, suffix);
> + if (ppc_inst_prefixed(inst) && (addr & 0x3F) == 0x3C) {
> + printk_ratelimited("Cannot register a uprobe on 64 byte "
^^^^^^^^^^^^^^^^^^ pr_info_ratelimited()
It should be sufficient to check the primary opcode to determine if it
is a prefixed instruction. You don't have to read the suffix. I see that
we don't have a helper to do this currently, so you could do:
if (ppc_inst_primary_opcode(ppc_inst(prefix)) == 1)
In the future, it might be worthwhile to add IS_PREFIX() as a macro
similar to IS_MTMSRD() if there are more such uses.
Along with this, if you also add the below to the start of this
function, you can get rid of the #ifdef:
if (!IS_ENABLED(CONFIG_PPC64))
return 0;
- Naveen
^ permalink raw reply
* Re: [PATCH v2] powerpc/uprobes: Validation for prefixed instruction
From: Naveen N. Rao @ 2021-02-04 13:15 UTC (permalink / raw)
To: Ravi Bangoria
Cc: oleg, rostedt, linux-kernel, paulus, sandipan, jniethe5,
naveen.n.rao, linuxppc-dev
In-Reply-To: <79b0bed7-8b98-d58d-dc47-644195bbc095@linux.ibm.com>
On 2021/02/04 04:19PM, Ravi Bangoria wrote:
>
>
> On 2/4/21 4:17 PM, Ravi Bangoria wrote:
> > Don't allow Uprobe on 2nd word of a prefixed instruction. As per
> > ISA 3.1, prefixed instruction should not cross 64-byte boundary.
> > So don't allow Uprobe on such prefixed instruction as well.
> >
> > There are two ways probed instruction is changed in mapped pages.
> > First, when Uprobe is activated, it searches for all the relevant
> > pages and replace instruction in them. In this case, if we notice
> > that probe is on the 2nd word of prefixed instruction, error out
> > directly. Second, when Uprobe is already active and user maps a
> > relevant page via mmap(), instruction is replaced via mmap() code
> > path. But because Uprobe is invalid, entire mmap() operation can
> > not be stopped. In this case just print an error and continue.
>
> @mpe,
>
> arch_uprobe_analyze_insn() can return early if
> cpu_has_feature(CPU_FTR_ARCH_31) is not set. But that will
> miss out a rare scenario of user running binary with prefixed
> instruction on p10 predecessors. Please let me know if I
> should add cpu_has_feature(CPU_FTR_ARCH_31) or not.
The check you are adding is very specific to prefixed instructions, so
it makes sense to add a cpu feature check for v3.1.
On older processors, those are invalid instructions like any other. The
instruction emulation infrastructure will refuse to emulate it and the
instruction will be single stepped.
- Naveen
^ permalink raw reply
* Re: [PATCH v2] powerpc/uprobes: Validation for prefixed instruction
From: Ananth N Mavinakayanahalli @ 2021-02-04 14:19 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <79b0bed7-8b98-d58d-dc47-644195bbc095@linux.ibm.com>
On 2/4/21 4:19 PM, Ravi Bangoria wrote:
>
>
> On 2/4/21 4:17 PM, Ravi Bangoria wrote:
>> Don't allow Uprobe on 2nd word of a prefixed instruction. As per
>> ISA 3.1, prefixed instruction should not cross 64-byte boundary.
>> So don't allow Uprobe on such prefixed instruction as well.
>>
>> There are two ways probed instruction is changed in mapped pages.
>> First, when Uprobe is activated, it searches for all the relevant
>> pages and replace instruction in them. In this case, if we notice
>> that probe is on the 2nd word of prefixed instruction, error out
>> directly. Second, when Uprobe is already active and user maps a
>> relevant page via mmap(), instruction is replaced via mmap() code
>> path. But because Uprobe is invalid, entire mmap() operation can
>> not be stopped. In this case just print an error and continue.
>
> @mpe,
>
> arch_uprobe_analyze_insn() can return early if
> cpu_has_feature(CPU_FTR_ARCH_31) is not set. But that will
> miss out a rare scenario of user running binary with prefixed
> instruction on p10 predecessors. Please let me know if I
> should add cpu_has_feature(CPU_FTR_ARCH_31) or not.
Wouldn't that binary get a SIGILL in any case? I concur with Naveen...
it makes sense to add the check.
--
Ananth
^ permalink raw reply
* Re: [PATCH] vio: make remove callback return void
From: Greg Kroah-Hartman @ 2021-02-04 16:08 UTC (permalink / raw)
To: Uwe Kleine-König
Cc: Cristobal Forno, Tyrel Datwyler, sparclinux, target-devel,
Paul Mackerras, Breno Leitão, Peter Huewe,
Sukadev Bhattiprolu, Jiri Slaby, Herbert Xu, linux-scsi,
Nayna Jain, Jason Gunthorpe, Michael Cyr, Jakub Kicinski,
Arnd Bergmann, James E.J. Bottomley, linux-block, Lijun Pan,
Matt Mackall, Jens Axboe, Steven Royer, Martin K. Petersen,
netdev, linux-kernel, Jarkko Sakkinen, linux-crypto, Dany Madden,
Paulo Flabiano Smorigo, linux-integrity, linuxppc-dev,
David S. Miller
In-Reply-To: <20210127215010.99954-1-uwe@kleine-koenig.org>
On Wed, Jan 27, 2021 at 10:50:10PM +0100, Uwe Kleine-König wrote:
> The driver core ignores the return value of struct bus_type::remove()
> because there is only little that can be done. To simplify the quest to
> make this function return void, let struct vio_driver::remove() return
> void, too. All users already unconditionally return 0, this commit makes
> it obvious that returning an error code is a bad idea and makes it
> obvious for future driver authors that returning an error code isn't
> intended.
>
> Note there are two nominally different implementations for a vio bus:
> one in arch/sparc/kernel/vio.c and the other in
> arch/powerpc/platforms/pseries/vio.c. I didn't care to check which
> driver is using which of these busses (or if even some of them can be
> used with both) and simply adapt all drivers and the two bus codes in
> one go.
>
> Note that for the powerpc implementation there is a semantical change:
> Before this patch for a device that was bound to a driver without a
> remove callback vio_cmo_bus_remove(viodev) wasn't called. As the device
> core still considers the device unbound after vio_bus_remove() returns
> calling this unconditionally is the consistent behaviour which is
> implemented here.
>
> Signed-off-by: Uwe Kleine-König <uwe@kleine-koenig.org>
> ---
> Hello,
>
> note that this change depends on
> https://lore.kernel.org/r/20210121062005.53271-1-ljp@linux.ibm.com which removes
> an (ignored) return -EBUSY in drivers/net/ethernet/ibm/ibmvnic.c.
> I don't know when/if this latter patch will be applied, so it might take
> some time until my patch can go in.
Acked-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
^ permalink raw reply
* Re: [PATCH v2] powerpc/uprobes: Validation for prefixed instruction
From: Naveen N. Rao @ 2021-02-04 16:12 UTC (permalink / raw)
To: Ravi Bangoria
Cc: oleg, rostedt, linux-kernel, paulus, sandipan, jniethe5,
naveen.n.rao, linuxppc-dev
In-Reply-To: <20210204130821.GK210@DESKTOP-TDPLP67.localdomain>
On 2021/02/04 06:38PM, Naveen N. Rao wrote:
> On 2021/02/04 04:17PM, Ravi Bangoria wrote:
> > Don't allow Uprobe on 2nd word of a prefixed instruction. As per
> > ISA 3.1, prefixed instruction should not cross 64-byte boundary.
> > So don't allow Uprobe on such prefixed instruction as well.
> >
> > There are two ways probed instruction is changed in mapped pages.
> > First, when Uprobe is activated, it searches for all the relevant
> > pages and replace instruction in them. In this case, if we notice
> > that probe is on the 2nd word of prefixed instruction, error out
> > directly. Second, when Uprobe is already active and user maps a
> > relevant page via mmap(), instruction is replaced via mmap() code
> > path. But because Uprobe is invalid, entire mmap() operation can
> > not be stopped. In this case just print an error and continue.
> >
> > Signed-off-by: Ravi Bangoria <ravi.bangoria@linux.ibm.com>
> > ---
> > v1: http://lore.kernel.org/r/20210119091234.76317-1-ravi.bangoria@linux.ibm.com
> > v1->v2:
> > - Instead of introducing new arch hook from verify_opcode(), use
> > existing hook arch_uprobe_analyze_insn().
> > - Add explicit check for prefixed instruction crossing 64-byte
> > boundary. If probe is on such instruction, throw an error.
> >
> > arch/powerpc/kernel/uprobes.c | 66 ++++++++++++++++++++++++++++++++++-
> > 1 file changed, 65 insertions(+), 1 deletion(-)
> >
> > diff --git a/arch/powerpc/kernel/uprobes.c b/arch/powerpc/kernel/uprobes.c
> > index e8a63713e655..485d19a2a31f 100644
> > --- a/arch/powerpc/kernel/uprobes.c
> > +++ b/arch/powerpc/kernel/uprobes.c
> > @@ -7,6 +7,7 @@
> > * Adapted from the x86 port by Ananth N Mavinakayanahalli <ananth@in.ibm.com>
> > */
> > #include <linux/kernel.h>
> > +#include <linux/highmem.h>
> > #include <linux/sched.h>
> > #include <linux/ptrace.h>
> > #include <linux/uprobes.h>
> > @@ -28,6 +29,69 @@ bool is_trap_insn(uprobe_opcode_t *insn)
> > return (is_trap(*insn));
> > }
> >
> > +#ifdef CONFIG_PPC64
> > +static int get_instr(struct mm_struct *mm, unsigned long addr, u32 *instr)
> > +{
> > + struct page *page;
> > + struct vm_area_struct *vma;
> > + void *kaddr;
> > + unsigned int gup_flags = FOLL_FORCE | FOLL_SPLIT_PMD;
> > +
> > + if (get_user_pages_remote(mm, addr, 1, gup_flags, &page, &vma, NULL) <= 0)
> > + return -EINVAL;
> > +
> > + kaddr = kmap_atomic(page);
> > + *instr = *((u32 *)(kaddr + (addr & ~PAGE_MASK)));
> > + kunmap_atomic(kaddr);
> > + put_page(page);
> > + return 0;
> > +}
> > +
> > +static int validate_prefixed_instr(struct mm_struct *mm, unsigned long addr)
> > +{
> > + struct ppc_inst inst;
> > + u32 prefix, suffix;
> > +
> > + /*
> > + * No need to check if addr is pointing to beginning of the
> > + * page. Even if probe is on a suffix of page-unaligned
> > + * prefixed instruction, hw will raise exception and kernel
> > + * will send SIGBUS.
> > + */
> > + if (!(addr & ~PAGE_MASK))
> > + return 0;
> > +
> > + if (get_instr(mm, addr, &prefix) < 0)
> > + return -EINVAL;
> > + if (get_instr(mm, addr + 4, &suffix) < 0)
> > + return -EINVAL;
> > +
> > + inst = ppc_inst_prefix(prefix, suffix);
> > + if (ppc_inst_prefixed(inst) && (addr & 0x3F) == 0x3C) {
> > + printk_ratelimited("Cannot register a uprobe on 64 byte "
> ^^^^^^^^^^^^^^^^^^ pr_info_ratelimited()
>
> It should be sufficient to check the primary opcode to determine if it
> is a prefixed instruction. You don't have to read the suffix. I see that
> we don't have a helper to do this currently, so you could do:
>
> if (ppc_inst_primary_opcode(ppc_inst(prefix)) == 1)
Seeing the kprobes code, I realized that we have to check for another
scenario (Thanks, Jordan!). If this is the suffix of a prefix
instruction for which a uprobe has already been installed, then the
previous word will be a 'trap' instruction. You need to check if there
is a uprobe at the previous word, and if the original instruction there
was a prefix instruction.
- Naveen
^ permalink raw reply
* [PATCH v16 02/12] of: Add a common kexec FDT setup function
From: Lakshmi Ramasubramanian @ 2021-02-04 16:41 UTC (permalink / raw)
To: zohar, bauerman, robh, takahiro.akashi, gregkh, will, joe,
catalin.marinas, mpe
Cc: mark.rutland, bhsharma, tao.li, paulus, vincenzo.frascino,
frowand.list, sashal, masahiroy, jmorris, linux-arm-kernel, serge,
devicetree, pasha.tatashin, prsriva, hsinyi, allison,
christophe.leroy, mbrugger, balajib, dmitry.kasatkin,
linux-kernel, james.morse, linux-integrity, linuxppc-dev
In-Reply-To: <20210204164135.29856-1-nramas@linux.microsoft.com>
From: Rob Herring <robh@kernel.org>
Both arm64 and powerpc do essentially the same FDT /chosen setup for
kexec. The differences are either omissions that arm64 should have
or additional properties that will be ignored. The setup code can be
combined and shared by both powerpc and arm64.
The differences relative to the arm64 version:
- If /chosen doesn't exist, it will be created (should never happen).
- Any old dtb and initrd reserved memory will be released.
- The new initrd and elfcorehdr are marked reserved.
- "linux,booted-from-kexec" is set.
The differences relative to the powerpc version:
- "kaslr-seed" and "rng-seed" may be set.
- "linux,elfcorehdr" is set.
- Any existing "linux,usable-memory-range" is removed.
Combine the code for setting up the /chosen node in the FDT and updating
the memory reservation for kexec, for powerpc and arm64, in
of_kexec_setup_new_fdt() and move it to "drivers/of/kexec.c".
Signed-off-by: Rob Herring <robh@kernel.org>
Reviewed-by: Thiago Jung Bauermann <bauerman@linux.ibm.com>
Reviewed-by: Lakshmi Ramasubramanian <nramas@linux.microsoft.com>
---
drivers/of/Makefile | 1 +
drivers/of/kexec.c | 236 ++++++++++++++++++++++++++++++++++++++++++++
include/linux/of.h | 4 +
3 files changed, 241 insertions(+)
create mode 100644 drivers/of/kexec.c
diff --git a/drivers/of/Makefile b/drivers/of/Makefile
index 6e1e5212f058..8ce11955afde 100644
--- a/drivers/of/Makefile
+++ b/drivers/of/Makefile
@@ -13,5 +13,6 @@ obj-$(CONFIG_OF_RESERVED_MEM) += of_reserved_mem.o
obj-$(CONFIG_OF_RESOLVE) += resolver.o
obj-$(CONFIG_OF_OVERLAY) += overlay.o
obj-$(CONFIG_OF_NUMA) += of_numa.o
+obj-$(CONFIG_KEXEC_FILE) += kexec.o
obj-$(CONFIG_OF_UNITTEST) += unittest-data/
diff --git a/drivers/of/kexec.c b/drivers/of/kexec.c
new file mode 100644
index 000000000000..4afd3cc1c04a
--- /dev/null
+++ b/drivers/of/kexec.c
@@ -0,0 +1,236 @@
+// SPDX-License-Identifier: GPL-2.0-only
+/*
+ * Copyright (C) 2020 Arm Limited
+ *
+ * Based on arch/arm64/kernel/machine_kexec_file.c:
+ * Copyright (C) 2018 Linaro Limited
+ *
+ * And arch/powerpc/kexec/file_load.c:
+ * Copyright (C) 2016 IBM Corporation
+ */
+
+#include <linux/kernel.h>
+#include <linux/kexec.h>
+#include <linux/libfdt.h>
+#include <linux/of.h>
+#include <linux/of_fdt.h>
+#include <linux/random.h>
+#include <linux/types.h>
+
+/* relevant device tree properties */
+#define FDT_PROP_KEXEC_ELFHDR "linux,elfcorehdr"
+#define FDT_PROP_MEM_RANGE "linux,usable-memory-range"
+#define FDT_PROP_INITRD_START "linux,initrd-start"
+#define FDT_PROP_INITRD_END "linux,initrd-end"
+#define FDT_PROP_BOOTARGS "bootargs"
+#define FDT_PROP_KASLR_SEED "kaslr-seed"
+#define FDT_PROP_RNG_SEED "rng-seed"
+#define RNG_SEED_SIZE 128
+
+/**
+ * fdt_find_and_del_mem_rsv - delete memory reservation with given address and size
+ *
+ * @fdt: Flattened device tree for the current kernel.
+ * @start: Starting address of the reserved memory.
+ * @size: Size of the reserved memory.
+ *
+ * Return: 0 on success, or negative errno on error.
+ */
+static int fdt_find_and_del_mem_rsv(void *fdt, unsigned long start, unsigned long size)
+{
+ int i, ret, num_rsvs = fdt_num_mem_rsv(fdt);
+
+ for (i = 0; i < num_rsvs; i++) {
+ u64 rsv_start, rsv_size;
+
+ ret = fdt_get_mem_rsv(fdt, i, &rsv_start, &rsv_size);
+ if (ret) {
+ pr_err("Malformed device tree.\n");
+ return -EINVAL;
+ }
+
+ if (rsv_start == start && rsv_size == size) {
+ ret = fdt_del_mem_rsv(fdt, i);
+ if (ret) {
+ pr_err("Error deleting device tree reservation.\n");
+ return -EINVAL;
+ }
+
+ return 0;
+ }
+ }
+
+ return -ENOENT;
+}
+
+/*
+ * of_kexec_setup_new_fdt - modify /chosen and memory reservation for the next kernel
+ *
+ * @image: kexec image being loaded.
+ * @fdt: Flattened device tree for the next kernel.
+ * @initrd_load_addr: Address where the next initrd will be loaded.
+ * @initrd_len: Size of the next initrd, or 0 if there will be none.
+ * @cmdline: Command line for the next kernel, or NULL if there will
+ * be none.
+ *
+ * Return: 0 on success, or negative errno on error.
+ */
+int of_kexec_setup_new_fdt(const struct kimage *image, void *fdt,
+ unsigned long initrd_load_addr, unsigned long initrd_len,
+ const char *cmdline)
+{
+ int ret, chosen_node;
+ const void *prop;
+
+ /* Remove memory reservation for the current device tree. */
+ ret = fdt_find_and_del_mem_rsv(fdt, __pa(initial_boot_params),
+ fdt_totalsize(initial_boot_params));
+ if (ret == -EINVAL)
+ return ret;
+
+ chosen_node = fdt_path_offset(fdt, "/chosen");
+ if (chosen_node == -FDT_ERR_NOTFOUND)
+ chosen_node = fdt_add_subnode(fdt, fdt_path_offset(fdt, "/"),
+ "chosen");
+ if (chosen_node < 0) {
+ ret = chosen_node;
+ goto out;
+ }
+
+ ret = fdt_delprop(fdt, chosen_node, FDT_PROP_KEXEC_ELFHDR);
+ if (ret && ret != -FDT_ERR_NOTFOUND)
+ goto out;
+ ret = fdt_delprop(fdt, chosen_node, FDT_PROP_MEM_RANGE);
+ if (ret && ret != -FDT_ERR_NOTFOUND)
+ goto out;
+
+ /* Did we boot using an initrd? */
+ prop = fdt_getprop(fdt, chosen_node, "linux,initrd-start", NULL);
+ if (prop) {
+ u64 tmp_start, tmp_end, tmp_size;
+
+ tmp_start = fdt64_to_cpu(*((const fdt64_t *) prop));
+
+ prop = fdt_getprop(fdt, chosen_node, "linux,initrd-end", NULL);
+ if (!prop)
+ return -EINVAL;
+
+ tmp_end = fdt64_to_cpu(*((const fdt64_t *) prop));
+
+ /*
+ * kexec reserves exact initrd size, while firmware may
+ * reserve a multiple of PAGE_SIZE, so check for both.
+ */
+ tmp_size = tmp_end - tmp_start;
+ ret = fdt_find_and_del_mem_rsv(fdt, tmp_start, tmp_size);
+ if (ret == -ENOENT)
+ ret = fdt_find_and_del_mem_rsv(fdt, tmp_start,
+ round_up(tmp_size, PAGE_SIZE));
+ if (ret == -EINVAL)
+ return ret;
+ }
+
+ /* add initrd-* */
+ if (initrd_load_addr) {
+ ret = fdt_setprop_u64(fdt, chosen_node, FDT_PROP_INITRD_START,
+ initrd_load_addr);
+ if (ret)
+ goto out;
+
+ ret = fdt_setprop_u64(fdt, chosen_node, FDT_PROP_INITRD_END,
+ initrd_load_addr + initrd_len);
+ if (ret)
+ goto out;
+
+ ret = fdt_add_mem_rsv(fdt, initrd_load_addr, initrd_len);
+ if (ret)
+ goto out;
+
+ } else {
+ ret = fdt_delprop(fdt, chosen_node, FDT_PROP_INITRD_START);
+ if (ret && (ret != -FDT_ERR_NOTFOUND))
+ goto out;
+
+ ret = fdt_delprop(fdt, chosen_node, FDT_PROP_INITRD_END);
+ if (ret && (ret != -FDT_ERR_NOTFOUND))
+ goto out;
+ }
+
+ if (image->type == KEXEC_TYPE_CRASH) {
+ /* add linux,elfcorehdr */
+ ret = fdt_appendprop_addrrange(fdt, 0, chosen_node,
+ FDT_PROP_KEXEC_ELFHDR,
+ image->arch.elf_headers_mem,
+ image->arch.elf_headers_sz);
+ if (ret)
+ goto out;
+
+ /*
+ * Avoid elfcorehdr from being stomped on in kdump kernel by
+ * setting up memory reserve map.
+ */
+ ret = fdt_add_mem_rsv(fdt, image->arch.elf_headers_mem,
+ image->arch.elf_headers_sz);
+ if (ret)
+ goto out;
+
+ /* add linux,usable-memory-range */
+ ret = fdt_appendprop_addrrange(fdt, 0, chosen_node,
+ FDT_PROP_MEM_RANGE,
+ crashk_res.start,
+ crashk_res.end - crashk_res.start + 1);
+ if (ret)
+ goto out;
+ }
+
+ /* add bootargs */
+ if (cmdline) {
+ ret = fdt_setprop_string(fdt, chosen_node, FDT_PROP_BOOTARGS, cmdline);
+ if (ret)
+ goto out;
+ } else {
+ ret = fdt_delprop(fdt, chosen_node, FDT_PROP_BOOTARGS);
+ if (ret && (ret != -FDT_ERR_NOTFOUND))
+ goto out;
+ }
+
+ /* add kaslr-seed */
+ ret = fdt_delprop(fdt, chosen_node, FDT_PROP_KASLR_SEED);
+ if (ret == -FDT_ERR_NOTFOUND)
+ ret = 0;
+ else if (ret)
+ goto out;
+
+ if (rng_is_initialized()) {
+ u64 seed = get_random_u64();
+
+ ret = fdt_setprop_u64(fdt, chosen_node, FDT_PROP_KASLR_SEED, seed);
+ if (ret)
+ goto out;
+ } else {
+ pr_notice("RNG is not initialised: omitting \"%s\" property\n",
+ FDT_PROP_KASLR_SEED);
+ }
+
+ /* add rng-seed */
+ if (rng_is_initialized()) {
+ void *rng_seed;
+
+ ret = fdt_setprop_placeholder(fdt, chosen_node, FDT_PROP_RNG_SEED,
+ RNG_SEED_SIZE, &rng_seed);
+ if (ret)
+ goto out;
+ get_random_bytes(rng_seed, RNG_SEED_SIZE);
+ } else {
+ pr_notice("RNG is not initialised: omitting \"%s\" property\n",
+ FDT_PROP_RNG_SEED);
+ }
+
+ ret = fdt_setprop(fdt, chosen_node, "linux,booted-from-kexec", NULL, 0);
+
+out:
+ if (ret)
+ return (ret == -FDT_ERR_NOSPACE) ? -ENOMEM : -EINVAL;
+
+ return 0;
+}
diff --git a/include/linux/of.h b/include/linux/of.h
index 4b27c9a27df3..41e256adf758 100644
--- a/include/linux/of.h
+++ b/include/linux/of.h
@@ -559,6 +559,10 @@ int of_map_id(struct device_node *np, u32 id,
struct device_node **target, u32 *id_out);
phys_addr_t of_dma_get_max_cpu_address(struct device_node *np);
+struct kimage;
+int of_kexec_setup_new_fdt(const struct kimage *image, void *fdt,
+ unsigned long initrd_load_addr, unsigned long initrd_len,
+ const char *cmdline);
#else /* CONFIG_OF */
--
2.30.0
^ permalink raw reply related
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