* Re: [PATCH 4/5] KVM: selftests: Add a test for KVM_RUN+rseq to detect task migration bugs
From: Mathieu Desnoyers @ 2021-08-20 18:31 UTC (permalink / raw)
To: Sean Christopherson
Cc: KVM list, Peter Zijlstra, linux-kernel, Will Deacon, Guo Ren,
linux-kselftest, Ben Gardon, shuah, Paul Mackerras, linux-s390,
gor, Russell King, ARM Linux, linux-csky, Christian Borntraeger,
Ingo Molnar, Catalin Marinas, linux-mips, Boqun Feng, paulmck,
Heiko Carstens, rostedt, Shakeel Butt, Andy Lutomirski,
Thomas Gleixner, Peter Foley, linux-arm-kernel,
Thomas Bogendoerfer, Oleg Nesterov, Paolo Bonzini, linuxppc-dev
In-Reply-To: <YR7qXvnI/AQM10gU@google.com>
----- On Aug 19, 2021, at 7:33 PM, Sean Christopherson seanjc@google.com wrote:
> On Thu, Aug 19, 2021, Mathieu Desnoyers wrote:
>> ----- On Aug 17, 2021, at 8:12 PM, Sean Christopherson seanjc@google.com wrote:
>>
>> > Add a test to verify an rseq's CPU ID is updated correctly if the task is
>> > migrated while the kernel is handling KVM_RUN. This is a regression test
>> > for a bug introduced by commit 72c3c0fe54a3 ("x86/kvm: Use generic xfer
>> > to guest work function"), where TIF_NOTIFY_RESUME would be cleared by KVM
>> > without updating rseq, leading to a stale CPU ID and other badness.
>> >
>> > Signed-off-by: Sean Christopherson <seanjc@google.com>
>> > ---
>>
>> [...]
>>
>> > + while (!done) {
>> > + vcpu_run(vm, VCPU_ID);
>> > + TEST_ASSERT(get_ucall(vm, VCPU_ID, NULL) == UCALL_SYNC,
>> > + "Guest failed?");
>> > +
>> > + cpu = sched_getcpu();
>> > + rseq_cpu = READ_ONCE(__rseq.cpu_id);
>> > +
>> > + /*
>> > + * Verify rseq's CPU matches sched's CPU, and that sched's CPU
>> > + * is stable. This doesn't handle the case where the task is
>> > + * migrated between sched_getcpu() and reading rseq, and again
>> > + * between reading rseq and sched_getcpu(), but in practice no
>> > + * false positives have been observed, while on the other hand
>> > + * blocking migration while this thread reads CPUs messes with
>> > + * the timing and prevents hitting failures on a buggy kernel.
>> > + */
>>
>> I think you could get a stable cpu id between sched_getcpu and __rseq_abi.cpu_id
>> if you add a pthread mutex to protect:
>>
>> sched_getcpu and __rseq_abi.cpu_id reads
>>
>> vs
>>
>> sched_setaffinity calls within the migration thread.
>>
>> Thoughts ?
>
> I tried that and couldn't reproduce the bug. That's what I attempted to call
> out
> in the blurb "blocking migration while this thread reads CPUs ... prevents
> hitting
> failures on a buggy kernel".
>
> I considered adding arbitrary delays around the mutex to try and hit the bug,
> but
> I was worried that even if I got it "working" for this bug, the test would be
> too
> tailored to this bug and potentially miss future regression. Letting the two
> threads run wild seemed like it would provide the best coverage, at the cost of
> potentially causing to false failures.
OK, so your point is that using mutual exclusion to ensure stability of the cpu id
changes the timings too much, to a point where the issues don't reproduce. I understand
that this mutex ties the migration thread timings to the vcpu thread's use of the mutex,
which will reduce timings randomness, which is unwanted here.
I still really hate flakiness in tests, because then people stop caring when they
fail once in a while. And with the nature of rseq, a once-in-a-while failure is a
big deal. Let's see if we can use other tricks to ensure stability of the cpu id
without changing timings too much.
One idea would be to use a seqcount lock. But even if we use that, I'm concerned that
the very long writer critical section calling sched_setaffinity would need to be
alternated with a sleep to ensure the read-side progresses. The sleep delay could be
relatively small compared to the duration of the sched_setaffinity call, e.g. ratio
1:10.
static volatile uint64_t seqcnt;
The thread responsible for setting the affinity would do something like:
for (;;) {
atomic_inc_seq_cst(&seqcnt);
sched_setaffinity(..., n++ % nr_cpus);
atomic_inc_seq_cst(&seqcnt);
usleep(1); /* this is where read-side is allowed to progress. */
}
And the thread reading the rseq cpu id and calling sched_getcpu():
uint64_t snapshot;
do {
snapshot = atomic_load(&seqcnt) & ~1; /* force retry if odd */
smp_rmb();
cpu = sched_getcpu();
rseq_cpu = READ_ONCE(__rseq.cpu_id);
smp_rmb();
} while (snapshot != atomic_load(&seqcnt));
So the reader retry the cpu id reads whenever sched_setaffinity is being
called by the migration thread, and whenever it is preempted for more
than one migration thread loop.
That should achieve our goal of providing cpu id stability without significantly
changing the timings of the migration thread, given that it never blocks waiting
for the reader.
Thoughts ?
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
^ permalink raw reply
* Re: [PATCH] powerpc/32: indirect function call use bctrl rather than blrl in ret_from_kernel_thread
From: Segher Boessenkool @ 2021-08-20 18:12 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev, Paul Mackerras, linux-kernel
In-Reply-To: <20210820171845.GS1583@gate.crashing.org>
On Fri, Aug 20, 2021 at 12:18:45PM -0500, Segher Boessenkool wrote:
> On Fri, Aug 20, 2021 at 10:15:11PM +1000, Michael Ellerman wrote:
> > Christophe Leroy <christophe.leroy@csgroup.eu> writes:
> > > Copied from commit 89bbe4c798bc ("powerpc/64: indirect function call
> > > use bctrl rather than blrl in ret_from_kernel_thread")
> > >
> > > blrl is not recommended to use as an indirect function call, as it may
> > > corrupt the link stack predictor.
> >
> > Do we know if any 32-bit CPUs have a link stack predictor or similar?
>
> 74xx do.
7450 and later, that is. Will I ever get that right, sigh.
Segher
^ permalink raw reply
* Re: [PATCH] powerpc/32: indirect function call use bctrl rather than blrl in ret_from_kernel_thread
From: Segher Boessenkool @ 2021-08-20 17:18 UTC (permalink / raw)
To: Michael Ellerman; +Cc: Paul Mackerras, linuxppc-dev, linux-kernel
In-Reply-To: <871r6oe2i8.fsf@mpe.ellerman.id.au>
On Fri, Aug 20, 2021 at 10:15:11PM +1000, Michael Ellerman wrote:
> Christophe Leroy <christophe.leroy@csgroup.eu> writes:
> > Copied from commit 89bbe4c798bc ("powerpc/64: indirect function call
> > use bctrl rather than blrl in ret_from_kernel_thread")
> >
> > blrl is not recommended to use as an indirect function call, as it may
> > corrupt the link stack predictor.
>
> Do we know if any 32-bit CPUs have a link stack predictor or similar?
74xx do.
Segher
^ permalink raw reply
* [Bug 213079] [bisected] IRQ problems and crashes on a PowerMac G5 with 5.12.3
From: bugzilla-daemon @ 2021-08-20 16:39 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <bug-213079-206035@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=213079
--- Comment #18 from Erhard F. (erhard_f@mailbox.org) ---
The 'hackfix for MSI init' patch also applies on top of v5.14-rc6.
But unchanged the G5 runs later into bug #213837.
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are watching the assignee of the bug.
^ permalink raw reply
* [Bug 213837] "Kernel panic - not syncing: corrupted stack end detected inside scheduler" at building via distcc on a G5
From: bugzilla-daemon @ 2021-08-20 16:35 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <bug-213837-206035@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=213837
--- Comment #3 from Erhard F. (erhard_f@mailbox.org) ---
Created attachment 298395
--> https://bugzilla.kernel.org/attachment.cgi?id=298395&action=edit
kernel .config (5.14-rc6, PowerMac G5 11,2)
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are watching someone on the CC list of the bug.
^ permalink raw reply
* [Bug 213837] "Kernel panic - not syncing: corrupted stack end detected inside scheduler" at building via distcc on a G5
From: bugzilla-daemon @ 2021-08-20 16:34 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <bug-213837-206035@https.bugzilla.kernel.org/>
https://bugzilla.kernel.org/show_bug.cgi?id=213837
--- Comment #2 from Erhard F. (erhard_f@mailbox.org) ---
Created attachment 298393
--> https://bugzilla.kernel.org/attachment.cgi?id=298393&action=edit
dmesg (5.14-rc6, PowerMac G5 11,2)
Happens also on 5.14-rc6:
[...]
Kernel panic - not syncing: corrupted stack end detected inside scheduler
CPU: 1 PID: 32354 Comm: powerpc64-unkno Tainted: G W
5.14.0-rc6-PowerMacG5+ #3
Call Trace:
[c000000062feb4c0] [c00000000054de04] .dump_stack_lvl+0x98/0xe0 (unreliable)
[c000000062feb550] [c000000000068f4c] .panic+0x160/0x40c
[c000000062feb600] [c000000000818d3c] .__schedule+0x7c/0x840
[c000000062feb6d0] [c00000000081964c] .preempt_schedule_common+0x28/0x48
[c000000062feb750] [c00000000081969c] .__cond_resched+0x30/0x4c
[c000000062feb7d0] [c0000000004ee8f8] .copy_page_to_iter+0xbc/0x32c
[c000000062feb8a0] [c0000000001c9c20] .filemap_read+0x574/0x618
[c000000062feba60] [c000000000333c18] .ext4_file_read_iter+0xb8/0x11c
[c000000062febb00] [c000000000275488] .new_sync_read+0x94/0xe0
[c000000062febc00] [c000000000276c2c] .vfs_read+0x128/0x12c
[c000000062febca0] [c000000000276fc4] .ksys_read+0x78/0xc4
[c000000062febd60] [c000000000022808] .system_call_exception+0x1a4/0x1dc
[c000000062febe10] [c00000000000b4cc] system_call_common+0xec/0x250
--- interrupt: c00 at 0x3fff999e0cd0
NIP: 00003fff999e0cd0 LR: 00000001039d3660 CTR: 0000000000000000
REGS: c000000062febe80 TRAP: 0c00 Tainted: G W
(5.14.0-rc6-PowerMacG5+)
MSR: 900000000200f032 <SF,HV,VEC,EE,PR,FP,ME,IR,DR,RI> CR: 24000442 XER:
00000000
IRQMASK: 0
GPR00: 0000000000000003 00003ffff4e23690 00003fff99a0df00 0000000000000004
GPR04: 00003fff99699010 00000000000583ca 00003fff999c1320 0000000000000000
GPR08: 00003fff999c12e0 0000000000000000 0000000000000000 0000000000000000
GPR12: 0000000000000000 00003fff99a93c20 000000011fbcf950 000000017149a1d0
GPR16: 00000001039dec38 00003ffff4e23b78 00000001039deb28 00003ffff4e239c8
GPR20: 00003ffff4e23d80 ffffffffffffffff 000000011fbce540 0000000000000000
GPR24: 000000011fbcf930 000000011fbcfa90 0000000000000005 00003ffff4e238e0
GPR28: 0000000103a268e8 0000000000000004 00003fff99699010 00000000000583ca
NIP [00003fff999e0cd0] 0x3fff999e0cd0
LR [00000001039d3660] 0x1039d3660
--- interrupt: c00
Rebooting in 40 seconds..
--
You may reply to this email to add a comment.
You are receiving this mail because:
You are watching someone on the CC list of the bug.
^ permalink raw reply
* Re: [PATCH v2 57/63] powerpc/signal32: Use struct_group() to zero spe regs
From: Kees Cook @ 2021-08-20 15:55 UTC (permalink / raw)
To: Michael Ellerman
Cc: kernel test robot, Rasmus Villemoes, Greg Kroah-Hartman,
linux-staging, linux-wireless, linux-kernel, Gustavo A. R. Silva,
linux-block, clang-built-linux, netdev, Paul Mackerras, dri-devel,
Sudeep Holla, Andrew Morton, linuxppc-dev, linux-kbuild,
linux-hardening
In-Reply-To: <877dggeesw.fsf@mpe.ellerman.id.au>
On Fri, Aug 20, 2021 at 05:49:35PM +1000, Michael Ellerman wrote:
> Kees Cook <keescook@chromium.org> writes:
> > In preparation for FORTIFY_SOURCE performing compile-time and run-time
> > field bounds checking for memset(), avoid intentionally writing across
> > neighboring fields.
> >
> > Add a struct_group() for the spe registers so that memset() can correctly reason
> > about the size:
> >
> > In function 'fortify_memset_chk',
> > inlined from 'restore_user_regs.part.0' at arch/powerpc/kernel/signal_32.c:539:3:
> >>> include/linux/fortify-string.h:195:4: error: call to '__write_overflow_field' declared with attribute warning: detected write beyond size of field (1st parameter); maybe use struct_group()? [-Werror=attribute-warning]
> > 195 | __write_overflow_field();
> > | ^~~~~~~~~~~~~~~~~~~~~~~~
> >
> > Cc: Michael Ellerman <mpe@ellerman.id.au>
> > Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> > Cc: Paul Mackerras <paulus@samba.org>
> > Cc: Christophe Leroy <christophe.leroy@csgroup.eu>
> > Cc: Sudeep Holla <sudeep.holla@arm.com>
> > Cc: linuxppc-dev@lists.ozlabs.org
> > Reported-by: kernel test robot <lkp@intel.com>
> > Signed-off-by: Kees Cook <keescook@chromium.org>
> > ---
> > arch/powerpc/include/asm/processor.h | 6 ++++--
> > arch/powerpc/kernel/signal_32.c | 6 +++---
> > 2 files changed, 7 insertions(+), 5 deletions(-)
> >
> > diff --git a/arch/powerpc/include/asm/processor.h b/arch/powerpc/include/asm/processor.h
> > index f348e564f7dd..05dc567cb9a8 100644
> > --- a/arch/powerpc/include/asm/processor.h
> > +++ b/arch/powerpc/include/asm/processor.h
> > @@ -191,8 +191,10 @@ struct thread_struct {
> > int used_vsr; /* set if process has used VSX */
> > #endif /* CONFIG_VSX */
> > #ifdef CONFIG_SPE
> > - unsigned long evr[32]; /* upper 32-bits of SPE regs */
> > - u64 acc; /* Accumulator */
> > + struct_group(spe,
> > + unsigned long evr[32]; /* upper 32-bits of SPE regs */
> > + u64 acc; /* Accumulator */
> > + );
> > unsigned long spefscr; /* SPE & eFP status */
> > unsigned long spefscr_last; /* SPEFSCR value on last prctl
> > call or trap return */
> > diff --git a/arch/powerpc/kernel/signal_32.c b/arch/powerpc/kernel/signal_32.c
> > index 0608581967f0..77b86caf5c51 100644
> > --- a/arch/powerpc/kernel/signal_32.c
> > +++ b/arch/powerpc/kernel/signal_32.c
> > @@ -532,11 +532,11 @@ static long restore_user_regs(struct pt_regs *regs,
> > regs_set_return_msr(regs, regs->msr & ~MSR_SPE);
> > if (msr & MSR_SPE) {
> > /* restore spe registers from the stack */
> > - unsafe_copy_from_user(current->thread.evr, &sr->mc_vregs,
> > - ELF_NEVRREG * sizeof(u32), failed);
> > + unsafe_copy_from_user(¤t->thread.spe, &sr->mc_vregs,
> > + sizeof(current->thread.spe), failed);
>
> This makes me nervous, because the ABI is that we copy ELF_NEVRREG *
> sizeof(u32) bytes, not whatever sizeof(current->thread.spe) happens to
> be.
>
> ie. if we use sizeof an inadvertent change to the fields in
> thread_struct could change how many bytes we copy out to userspace,
> which would be an ABI break.
>
> And that's not that hard to do, because it's not at all obvious that the
> size and layout of fields in thread_struct affects the user ABI.
>
> At the same time we don't want to copy the right number of bytes but
> the wrong content, so from that point of view using sizeof is good :)
>
> The way we handle it in ptrace is to have BUILD_BUG_ON()s to verify that
> things match up, so maybe we should do that here too.
>
> ie. add:
>
> BUILD_BUG_ON(sizeof(current->thread.spe) == ELF_NEVRREG * sizeof(u32));
>
> Not sure if you are happy doing that as part of this patch. I can always
> do it later if not.
Sounds good to me; I did that in a few other cases in the series where
the relationships between things seemed tenuous. :) I'll add this (as
!=) in v3.
Thanks!
--
Kees Cook
^ permalink raw reply
* Re: [PATCH v8 2/3] tty: hvc: pass DMA capable memory to put_chars()
From: Michael Ellerman @ 2021-08-20 12:34 UTC (permalink / raw)
To: Daniel Axtens, Xianting Tian, gregkh, jirislaby, amit, arnd,
osandov
Cc: Xianting Tian, shile.zhang, linuxppc-dev, linux-kernel,
virtualization
In-Reply-To: <87pmu8ehkk.fsf@linkitivity.dja.id.au>
Daniel Axtens <dja@axtens.net> writes:
> Xianting Tian <xianting.tian@linux.alibaba.com> writes:
>
>> As well known, hvc backend driver(eg, virtio-console) can register its
>> operations to hvc framework. The operations can contain put_chars(),
>> get_chars() and so on.
>>
>> Some hvc backend may do dma in its operations. eg, put_chars() of
>> virtio-console. But in the code of hvc framework, it may pass DMA
>> incapable memory to put_chars() under a specific configuration, which
>> is explained in commit c4baad5029(virtio-console: avoid DMA from stack):
>
> We could also run into issues on powerpc where Andrew is working on
> adding vmap-stack but the opal hvc driver assumes that it is passed a
> buffer which is not in vmalloc space but in the linear mapping.
The right fix for that is our code that calls opal has to be careful
that it's not passing vmalloc addresses.
We have many cases where we pass stack variables to opal, they'll all
have to be fixed to pass the underlying phyiscal/linear map address. The
opal hvc code will just be one more case of that.
cheers
^ permalink raw reply
* Re: [PATCH 6/6] powerpc/compat_sys: Declare syscalls
From: Michael Ellerman @ 2021-08-20 12:25 UTC (permalink / raw)
To: Cédric Le Goater, linuxppc-dev
Cc: Christophe Leroy, Cédric Le Goater
In-Reply-To: <20210819125656.14498-7-clg@kaod.org>
Cédric Le Goater <clg@kaod.org> writes:
> This fixes a compile error with W=1.
>
> Cc: Christophe Leroy <christophe.leroy@c-s.fr>
> Signed-off-by: Cédric Le Goater <clg@kaod.org>
> ---
> arch/powerpc/include/asm/syscalls.h | 31 +++++++++++++++++++++++++++++
> 1 file changed, 31 insertions(+)
>
> diff --git a/arch/powerpc/include/asm/syscalls.h b/arch/powerpc/include/asm/syscalls.h
> index 398171fdcd9f..1d5f2abaa38a 100644
> --- a/arch/powerpc/include/asm/syscalls.h
> +++ b/arch/powerpc/include/asm/syscalls.h
> @@ -6,6 +6,7 @@
> #include <linux/compiler.h>
> #include <linux/linkage.h>
> #include <linux/types.h>
> +#include <linux/compat.h>
>
> struct rtas_args;
>
> @@ -18,5 +19,35 @@ asmlinkage long sys_mmap2(unsigned long addr, size_t len,
> asmlinkage long ppc64_personality(unsigned long personality);
> asmlinkage long sys_rtas(struct rtas_args __user *uargs);
>
> +#ifdef CONFIG_COMPAT
> +unsigned long compat_sys_mmap2(unsigned long addr, size_t len,
> + unsigned long prot, unsigned long flags,
> + unsigned long fd, unsigned long pgoff);
> +
> +compat_ssize_t compat_sys_pread64(unsigned int fd, char __user *ubuf, compat_size_t count,
> + u32 reg6, u32 pos1, u32 pos2);
> +
> +compat_ssize_t compat_sys_pwrite64(unsigned int fd, const char __user *ubuf, compat_size_t count,
> + u32 reg6, u32 pos1, u32 pos2);
> +
> +compat_ssize_t compat_sys_readahead(int fd, u32 r4, u32 offset1, u32 offset2, u32 count);
> +
> +asmlinkage int compat_sys_truncate64(const char __user *path, u32 reg4,
> + unsigned long len1, unsigned long len2);
asmlinkage does nothing, ie. it's an empty macro. Let's not add new uses
of it.
cheers
^ permalink raw reply
* Re: [PATCH 3/6] KVM: PPC: Book3S PR: Declare kvmppc_handle_exit_pr()
From: Michael Ellerman @ 2021-08-20 12:22 UTC (permalink / raw)
To: Christophe Leroy, Cédric Le Goater, linuxppc-dev; +Cc: Christophe Leroy
In-Reply-To: <59d11f91-c235-6b7d-6d9a-de8d852aba35@csgroup.eu>
Christophe Leroy <christophe.leroy@csgroup.eu> writes:
> Le 19/08/2021 à 14:56, Cédric Le Goater a écrit :
>> This fixes a compile error with W=1.
>>
>> Signed-off-by: Cédric Le Goater <clg@kaod.org>
>> ---
>> arch/powerpc/kvm/book3s.h | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/arch/powerpc/kvm/book3s.h b/arch/powerpc/kvm/book3s.h
>> index 740e51def5a5..c08f93b7f523 100644
>> --- a/arch/powerpc/kvm/book3s.h
>> +++ b/arch/powerpc/kvm/book3s.h
>> @@ -24,6 +24,7 @@ extern int kvmppc_core_emulate_mfspr_pr(struct kvm_vcpu *vcpu,
>> int sprn, ulong *spr_val);
>> extern int kvmppc_book3s_init_pr(void);
>> extern void kvmppc_book3s_exit_pr(void);
>> +extern int kvmppc_handle_exit_pr(struct kvm_vcpu *vcpu, unsigned int exit_nr);
>
> Don't add new 'extern' keywords, they are useless and pointless for functions prototypes.
I dropped it when applying.
cheers
^ permalink raw reply
* Re: [PATCH 1/6] powerpc/prom: Introduce early_reserve_mem_old()
From: Michael Ellerman @ 2021-08-20 12:22 UTC (permalink / raw)
To: Christophe Leroy, Cédric Le Goater, linuxppc-dev; +Cc: Christophe Leroy
In-Reply-To: <d79611e0-b42b-e74b-d628-5db718e6ebfa@csgroup.eu>
Christophe Leroy <christophe.leroy@csgroup.eu> writes:
> Le 19/08/2021 à 14:56, Cédric Le Goater a écrit :
>> and condition its call with IS_ENABLED(CONFIG_PPC32). This fixes a
>> compile error with W=1.
>>
>> arch/powerpc/kernel/prom.c: In function ‘early_reserve_mem’:
>> arch/powerpc/kernel/prom.c:625:10: error: variable ‘reserve_map’ set but not used [-Werror=unused-but-set-variable]
>> __be64 *reserve_map;
>> ^~~~~~~~~~~
>> cc1: all warnings being treated as errors
>>
>> Cc: Christophe Leroy <christophe.leroy@c-s.fr>
>> Signed-off-by: Cédric Le Goater <clg@kaod.org>
>> ---
>>
>> Christophe, I think you had comments on this one ? Yes, I am being a bit lazy.
>
>
> Yeah, my comment was to leave thing almost as is, just drop the #ifdef CONFIG_PPC32 and instead put
> something like:
>
> if (!IS_ENABLED(CONFIG_PPC32))
> return;
Yeah that's cleaner, let's do that.
cheers
^ permalink raw reply
* Re: [PATCH] powerpc/32: indirect function call use bctrl rather than blrl in ret_from_kernel_thread
From: Michael Ellerman @ 2021-08-20 12:15 UTC (permalink / raw)
To: Christophe Leroy, Benjamin Herrenschmidt, Paul Mackerras
Cc: linuxppc-dev, linux-kernel
In-Reply-To: <91b1d242525307ceceec7ef6e832bfbacdd4501b.1629436472.git.christophe.leroy@csgroup.eu>
Christophe Leroy <christophe.leroy@csgroup.eu> writes:
> Copied from commit 89bbe4c798bc ("powerpc/64: indirect function call
> use bctrl rather than blrl in ret_from_kernel_thread")
>
> blrl is not recommended to use as an indirect function call, as it may
> corrupt the link stack predictor.
Do we know if any 32-bit CPUs have a link stack predictor or similar?
cheers
> This is not a performance critical path but this should be fixed for
> consistency.
>
> Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
> ---
> arch/powerpc/kernel/entry_32.S | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/powerpc/kernel/entry_32.S b/arch/powerpc/kernel/entry_32.S
> index 0273a1349006..61fdd53cdd9a 100644
> --- a/arch/powerpc/kernel/entry_32.S
> +++ b/arch/powerpc/kernel/entry_32.S
> @@ -161,10 +161,10 @@ ret_from_fork:
> ret_from_kernel_thread:
> REST_NVGPRS(r1)
> bl schedule_tail
> - mtlr r14
> + mtctr r14
> mr r3,r15
> PPC440EP_ERR42
> - blrl
> + bctrl
> li r3,0
> b ret_from_syscall
>
> --
> 2.25.0
^ permalink raw reply
* Re: [PATCH v2 57/63] powerpc/signal32: Use struct_group() to zero spe regs
From: Michael Ellerman @ 2021-08-20 12:13 UTC (permalink / raw)
To: Christophe Leroy, Kees Cook, linux-kernel
Cc: kernel test robot, Rasmus Villemoes, Greg Kroah-Hartman,
linux-staging, linux-wireless, Gustavo A. R. Silva, dri-devel,
linux-block, clang-built-linux, netdev, Paul Mackerras,
linux-hardening, Sudeep Holla, Andrew Morton, linuxppc-dev,
linux-kbuild
In-Reply-To: <0f6e508e-62b6-3840-5ff4-eb5a77635bd1@csgroup.eu>
Christophe Leroy <christophe.leroy@csgroup.eu> writes:
> Le 20/08/2021 à 09:49, Michael Ellerman a écrit :
>> Kees Cook <keescook@chromium.org> writes:
>>> In preparation for FORTIFY_SOURCE performing compile-time and run-time
>>> field bounds checking for memset(), avoid intentionally writing across
>>> neighboring fields.
>>>
>>> Add a struct_group() for the spe registers so that memset() can correctly reason
>>> about the size:
>>>
>>> In function 'fortify_memset_chk',
>>> inlined from 'restore_user_regs.part.0' at arch/powerpc/kernel/signal_32.c:539:3:
>>>>> include/linux/fortify-string.h:195:4: error: call to '__write_overflow_field' declared with attribute warning: detected write beyond size of field (1st parameter); maybe use struct_group()? [-Werror=attribute-warning]
>>> 195 | __write_overflow_field();
>>> | ^~~~~~~~~~~~~~~~~~~~~~~~
>>>
>>> Cc: Michael Ellerman <mpe@ellerman.id.au>
>>> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
>>> Cc: Paul Mackerras <paulus@samba.org>
>>> Cc: Christophe Leroy <christophe.leroy@csgroup.eu>
>>> Cc: Sudeep Holla <sudeep.holla@arm.com>
>>> Cc: linuxppc-dev@lists.ozlabs.org
>>> Reported-by: kernel test robot <lkp@intel.com>
>>> Signed-off-by: Kees Cook <keescook@chromium.org>
>>> ---
>>> arch/powerpc/include/asm/processor.h | 6 ++++--
>>> arch/powerpc/kernel/signal_32.c | 6 +++---
>>> 2 files changed, 7 insertions(+), 5 deletions(-)
>>>
>>> diff --git a/arch/powerpc/include/asm/processor.h b/arch/powerpc/include/asm/processor.h
>>> index f348e564f7dd..05dc567cb9a8 100644
>>> --- a/arch/powerpc/include/asm/processor.h
>>> +++ b/arch/powerpc/include/asm/processor.h
>>> @@ -191,8 +191,10 @@ struct thread_struct {
>>> int used_vsr; /* set if process has used VSX */
>>> #endif /* CONFIG_VSX */
>>> #ifdef CONFIG_SPE
>>> - unsigned long evr[32]; /* upper 32-bits of SPE regs */
>>> - u64 acc; /* Accumulator */
>>> + struct_group(spe,
>>> + unsigned long evr[32]; /* upper 32-bits of SPE regs */
>>> + u64 acc; /* Accumulator */
>>> + );
>>> unsigned long spefscr; /* SPE & eFP status */
>>> unsigned long spefscr_last; /* SPEFSCR value on last prctl
>>> call or trap return */
>>> diff --git a/arch/powerpc/kernel/signal_32.c b/arch/powerpc/kernel/signal_32.c
>>> index 0608581967f0..77b86caf5c51 100644
>>> --- a/arch/powerpc/kernel/signal_32.c
>>> +++ b/arch/powerpc/kernel/signal_32.c
>>> @@ -532,11 +532,11 @@ static long restore_user_regs(struct pt_regs *regs,
>>> regs_set_return_msr(regs, regs->msr & ~MSR_SPE);
>>> if (msr & MSR_SPE) {
>>> /* restore spe registers from the stack */
>>> - unsafe_copy_from_user(current->thread.evr, &sr->mc_vregs,
>>> - ELF_NEVRREG * sizeof(u32), failed);
>>> + unsafe_copy_from_user(¤t->thread.spe, &sr->mc_vregs,
>>> + sizeof(current->thread.spe), failed);
>>
>> This makes me nervous, because the ABI is that we copy ELF_NEVRREG *
>> sizeof(u32) bytes, not whatever sizeof(current->thread.spe) happens to
>> be.
>>
>> ie. if we use sizeof an inadvertent change to the fields in
>> thread_struct could change how many bytes we copy out to userspace,
>> which would be an ABI break.
>>
>> And that's not that hard to do, because it's not at all obvious that the
>> size and layout of fields in thread_struct affects the user ABI.
>>
>> At the same time we don't want to copy the right number of bytes but
>> the wrong content, so from that point of view using sizeof is good :)
>>
>> The way we handle it in ptrace is to have BUILD_BUG_ON()s to verify that
>> things match up, so maybe we should do that here too.
>>
>> ie. add:
>>
>> BUILD_BUG_ON(sizeof(current->thread.spe) == ELF_NEVRREG * sizeof(u32));
>
> You mean != I guess ?
Gah. Yes I do :)
cheers
^ permalink raw reply
* [PATCH v1] powerpc/64s: Fix scv implicit soft-mask table for relocated kernels
From: Nicholas Piggin @ 2021-08-20 10:34 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Hari Bathini, Nicholas Piggin
The implict soft-mask table addresses get relocated if they use a
relative symbol like a label. This is right for code that runs relocated
but not for unrelocated. The scv interrupt vectors run unrelocated, so
absolute addresses are required for their soft-mask table entry.
This fixes crashing with relocated kernels, usually an asynchronous
interrupt hitting in the scv handler, then hitting the trap that checks
whether r1 is in userspace.
Cc: Hari Bathini <hbathini@linux.ibm.com>
Fixes: 325678fd0522 ("powerpc/64s: add a table of implicit soft-masked addresses")
Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
---
arch/powerpc/kernel/exceptions-64s.S | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/kernel/exceptions-64s.S b/arch/powerpc/kernel/exceptions-64s.S
index 4aec59a77d4c..37859e62a8dc 100644
--- a/arch/powerpc/kernel/exceptions-64s.S
+++ b/arch/powerpc/kernel/exceptions-64s.S
@@ -812,7 +812,6 @@ __start_interrupts:
* syscall register convention is in Documentation/powerpc/syscall64-abi.rst
*/
EXC_VIRT_BEGIN(system_call_vectored, 0x3000, 0x1000)
-1:
/* SCV 0 */
mr r9,r13
GET_PACA(r13)
@@ -842,10 +841,12 @@ EXC_VIRT_BEGIN(system_call_vectored, 0x3000, 0x1000)
b system_call_vectored_sigill
#endif
.endr
-2:
EXC_VIRT_END(system_call_vectored, 0x3000, 0x1000)
-SOFT_MASK_TABLE(1b, 2b) // Treat scv vectors as soft-masked, see comment above.
+// Treat scv vectors as soft-masked, see comment above.
+// Use absolute values rather than labels here, so they don't get relocated,
+// because this code runs unrelocated.
+SOFT_MASK_TABLE(0xc000000000003000, 0xc000000000004000)
#ifdef CONFIG_RELOCATABLE
TRAMP_VIRT_BEGIN(system_call_vectored_tramp)
--
2.23.0
^ permalink raw reply related
* [PATCH] powerpc/audit: Simplify syscall_get_arch()
From: Christophe Leroy @ 2021-08-20 9:39 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman
Cc: linuxppc-dev, linux-kernel
Make use of is_32bit_task() and CONFIG_CPU_LITTLE_ENDIAN
to simplify syscall_get_arch().
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
---
arch/powerpc/include/asm/syscall.h | 15 +++++----------
1 file changed, 5 insertions(+), 10 deletions(-)
diff --git a/arch/powerpc/include/asm/syscall.h b/arch/powerpc/include/asm/syscall.h
index ba0f88f3a30d..ac766037e8a1 100644
--- a/arch/powerpc/include/asm/syscall.h
+++ b/arch/powerpc/include/asm/syscall.h
@@ -116,16 +116,11 @@ static inline void syscall_set_arguments(struct task_struct *task,
static inline int syscall_get_arch(struct task_struct *task)
{
- int arch;
-
- if (IS_ENABLED(CONFIG_PPC64) && !test_tsk_thread_flag(task, TIF_32BIT))
- arch = AUDIT_ARCH_PPC64;
+ if (is_32bit_task())
+ return AUDIT_ARCH_PPC;
+ else if (IS_ENABLED(CONFIG_CPU_LITTLE_ENDIAN))
+ return AUDIT_ARCH_PPC64LE;
else
- arch = AUDIT_ARCH_PPC;
-
-#ifdef __LITTLE_ENDIAN__
- arch |= __AUDIT_ARCH_LE;
-#endif
- return arch;
+ return AUDIT_ARCH_PPC64;
}
#endif /* _ASM_SYSCALL_H */
--
2.25.0
^ permalink raw reply related
* [PATCH] powerpc/audit: Avoid unneccessary #ifdef in syscall_get_arguments()
From: Christophe Leroy @ 2021-08-20 9:28 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman
Cc: linuxppc-dev, linux-kernel
Use is_32bit_task() which already handles CONFIG_COMPAT.
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
---
arch/powerpc/include/asm/syscall.h | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/include/asm/syscall.h b/arch/powerpc/include/asm/syscall.h
index ac766037e8a1..c60ebd04b2ed 100644
--- a/arch/powerpc/include/asm/syscall.h
+++ b/arch/powerpc/include/asm/syscall.h
@@ -90,10 +90,9 @@ static inline void syscall_get_arguments(struct task_struct *task,
unsigned long val, mask = -1UL;
unsigned int n = 6;
-#ifdef CONFIG_COMPAT
- if (test_tsk_thread_flag(task, TIF_32BIT))
+ if (is_32bit_task())
mask = 0xffffffff;
-#endif
+
while (n--) {
if (n == 0)
val = regs->orig_gpr3;
--
2.25.0
^ permalink raw reply related
* [RFC PATCH] powerpc/audit: Convert powerpc to AUDIT_ARCH_COMPAT_GENERIC
From: Christophe Leroy @ 2021-08-20 9:26 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman
Cc: linuxppc-dev, linux-kernel
No time to finalise commit description and testing before the
weekend, sending out as RFC to eventually get some feedback.
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
---
arch/powerpc/Kconfig | 5 +-
arch/powerpc/kernel/Makefile | 3 --
arch/powerpc/kernel/audit.c | 84 ------------------------------
arch/powerpc/kernel/compat_audit.c | 44 ----------------
4 files changed, 1 insertion(+), 135 deletions(-)
delete mode 100644 arch/powerpc/kernel/audit.c
delete mode 100644 arch/powerpc/kernel/compat_audit.c
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 663766fbf505..5472358609d2 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -163,6 +163,7 @@ config PPC
select ARCH_WANT_IRQS_OFF_ACTIVATE_MM
select ARCH_WANT_LD_ORPHAN_WARN
select ARCH_WEAK_RELEASE_ACQUIRE
+ select AUDIT_ARCH_COMPAT_GENERIC
select BINFMT_ELF
select BUILDTIME_TABLE_SORT
select CLONE_BACKWARDS
@@ -316,10 +317,6 @@ config GENERIC_TBSYNC
bool
default y if PPC32 && SMP
-config AUDIT_ARCH
- bool
- default y
-
config GENERIC_BUG
bool
default y
diff --git a/arch/powerpc/kernel/Makefile b/arch/powerpc/kernel/Makefile
index 7be36c1e1db6..825121eba3c2 100644
--- a/arch/powerpc/kernel/Makefile
+++ b/arch/powerpc/kernel/Makefile
@@ -125,9 +125,6 @@ obj-$(CONFIG_PCI) += pci_$(BITS).o $(pci64-y) \
pci-common.o pci_of_scan.o
obj-$(CONFIG_PCI_MSI) += msi.o
-obj-$(CONFIG_AUDIT) += audit.o
-obj64-$(CONFIG_AUDIT) += compat_audit.o
-
obj-$(CONFIG_PPC_IO_WORKAROUNDS) += io-workarounds.o
obj-y += trace/
diff --git a/arch/powerpc/kernel/audit.c b/arch/powerpc/kernel/audit.c
deleted file mode 100644
index a2dddd7f3d09..000000000000
--- a/arch/powerpc/kernel/audit.c
+++ /dev/null
@@ -1,84 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0
-#include <linux/init.h>
-#include <linux/types.h>
-#include <linux/audit.h>
-#include <asm/unistd.h>
-
-static unsigned dir_class[] = {
-#include <asm-generic/audit_dir_write.h>
-~0U
-};
-
-static unsigned read_class[] = {
-#include <asm-generic/audit_read.h>
-~0U
-};
-
-static unsigned write_class[] = {
-#include <asm-generic/audit_write.h>
-~0U
-};
-
-static unsigned chattr_class[] = {
-#include <asm-generic/audit_change_attr.h>
-~0U
-};
-
-static unsigned signal_class[] = {
-#include <asm-generic/audit_signal.h>
-~0U
-};
-
-int audit_classify_arch(int arch)
-{
-#ifdef CONFIG_PPC64
- if (arch == AUDIT_ARCH_PPC)
- return 1;
-#endif
- return 0;
-}
-
-int audit_classify_syscall(int abi, unsigned syscall)
-{
-#ifdef CONFIG_PPC64
- extern int ppc32_classify_syscall(unsigned);
- if (abi == AUDIT_ARCH_PPC)
- return ppc32_classify_syscall(syscall);
-#endif
- switch(syscall) {
- case __NR_open:
- return 2;
- case __NR_openat:
- return 3;
- case __NR_socketcall:
- return 4;
- case __NR_execve:
- return 5;
- default:
- return 0;
- }
-}
-
-static int __init audit_classes_init(void)
-{
-#ifdef CONFIG_PPC64
- extern __u32 ppc32_dir_class[];
- extern __u32 ppc32_write_class[];
- extern __u32 ppc32_read_class[];
- extern __u32 ppc32_chattr_class[];
- extern __u32 ppc32_signal_class[];
- audit_register_class(AUDIT_CLASS_WRITE_32, ppc32_write_class);
- audit_register_class(AUDIT_CLASS_READ_32, ppc32_read_class);
- audit_register_class(AUDIT_CLASS_DIR_WRITE_32, ppc32_dir_class);
- audit_register_class(AUDIT_CLASS_CHATTR_32, ppc32_chattr_class);
- audit_register_class(AUDIT_CLASS_SIGNAL_32, ppc32_signal_class);
-#endif
- audit_register_class(AUDIT_CLASS_WRITE, write_class);
- audit_register_class(AUDIT_CLASS_READ, read_class);
- audit_register_class(AUDIT_CLASS_DIR_WRITE, dir_class);
- audit_register_class(AUDIT_CLASS_CHATTR, chattr_class);
- audit_register_class(AUDIT_CLASS_SIGNAL, signal_class);
- return 0;
-}
-
-__initcall(audit_classes_init);
diff --git a/arch/powerpc/kernel/compat_audit.c b/arch/powerpc/kernel/compat_audit.c
deleted file mode 100644
index 55c6ccda0a85..000000000000
--- a/arch/powerpc/kernel/compat_audit.c
+++ /dev/null
@@ -1,44 +0,0 @@
-// SPDX-License-Identifier: GPL-2.0
-#undef __powerpc64__
-#include <asm/unistd.h>
-
-unsigned ppc32_dir_class[] = {
-#include <asm-generic/audit_dir_write.h>
-~0U
-};
-
-unsigned ppc32_chattr_class[] = {
-#include <asm-generic/audit_change_attr.h>
-~0U
-};
-
-unsigned ppc32_write_class[] = {
-#include <asm-generic/audit_write.h>
-~0U
-};
-
-unsigned ppc32_read_class[] = {
-#include <asm-generic/audit_read.h>
-~0U
-};
-
-unsigned ppc32_signal_class[] = {
-#include <asm-generic/audit_signal.h>
-~0U
-};
-
-int ppc32_classify_syscall(unsigned syscall)
-{
- switch(syscall) {
- case __NR_open:
- return 2;
- case __NR_openat:
- return 3;
- case __NR_socketcall:
- return 4;
- case __NR_execve:
- return 5;
- default:
- return 1;
- }
-}
--
2.25.0
^ permalink raw reply related
* Re: [PATCH v8 2/3] tty: hvc: pass DMA capable memory to put_chars()
From: Xianting TIan @ 2021-08-20 8:43 UTC (permalink / raw)
To: Daniel Axtens, gregkh, jirislaby, amit, arnd, osandov
Cc: shile.zhang, linuxppc-dev, linux-kernel, virtualization
In-Reply-To: <87pmu8ehkk.fsf@linkitivity.dja.id.au>
在 2021/8/20 下午2:49, Daniel Axtens 写道:
> Xianting Tian <xianting.tian@linux.alibaba.com> writes:
>
>> As well known, hvc backend driver(eg, virtio-console) can register its
>> operations to hvc framework. The operations can contain put_chars(),
>> get_chars() and so on.
>>
>> Some hvc backend may do dma in its operations. eg, put_chars() of
>> virtio-console. But in the code of hvc framework, it may pass DMA
>> incapable memory to put_chars() under a specific configuration, which
>> is explained in commit c4baad5029(virtio-console: avoid DMA from stack):
> We could also run into issues on powerpc where Andrew is working on
> adding vmap-stack but the opal hvc driver assumes that it is passed a
> buffer which is not in vmalloc space but in the linear mapping. So it
> would be good to fix this (or more clearly document what drivers can
> expect).
>
>> 1, c[] is on stack,
>> hvc_console_print():
>> char c[N_OUTBUF] __ALIGNED__;
>> cons_ops[index]->put_chars(vtermnos[index], c, i);
>> 2, ch is on stack,
>> static void hvc_poll_put_char(,,char ch)
>> {
>> struct tty_struct *tty = driver->ttys[0];
>> struct hvc_struct *hp = tty->driver_data;
>> int n;
>>
>> do {
>> n = hp->ops->put_chars(hp->vtermno, &ch, 1);
>> } while (n <= 0);
>> }
>>
>> Commit c4baad5029 is just the fix to avoid DMA from stack memory, which
>> is passed to virtio-console by hvc framework in above code. But I think
>> the fix is aggressive, it directly uses kmemdup() to alloc new buffer
>> from kmalloc area and do memcpy no matter the memory is in kmalloc area
>> or not. But most importantly, it should better be fixed in the hvc
>> framework, by changing it to never pass stack memory to the put_chars()
>> function in the first place. Otherwise, we still face the same issue if
>> a new hvc backend using dma added in the future.
>>
>> In this patch, we make 'char out_buf[N_OUTBUF]' and 'chat out_ch' part
>> of 'struct hvc_struct', so both two buf are no longer the stack memory.
>> we can use it in above two cases separately.
>>
>> Introduce another array(cons_outbufs[]) for buffer pointers next to
>> the cons_ops[] and vtermnos[] arrays. With the array, we can easily find
>> the buffer, instead of traversing hp list.
>>
>> With the patch, we can remove the fix c4baad5029.
>>
>> Signed-off-by: Xianting Tian <xianting.tian@linux.alibaba.com>
>> Reviewed-by: Shile Zhang <shile.zhang@linux.alibaba.com>
>> struct hvc_struct {
>> struct tty_port port;
>> spinlock_t lock;
>> int index;
>> int do_wakeup;
>> - char *outbuf;
>> - int outbuf_size;
>> int n_outbuf;
>> uint32_t vtermno;
>> const struct hv_ops *ops;
>> @@ -48,6 +56,10 @@ struct hvc_struct {
>> struct work_struct tty_resize;
>> struct list_head next;
>> unsigned long flags;
>> + char out_ch;
>> + char out_buf[N_OUTBUF] __ALIGNED__;
>> + int outbuf_size;
>> + char outbuf[0] __ALIGNED__;
> I'm trying to understand this patch but I am finding it very difficult
> to understand what the difference between `out_buf` and `outbuf`
> (without the underscore) is supposed to be. `out_buf` is statically
> sized and the size of `outbuf` is supposed to depend on the arguments to
> hvc_alloc(), but I can't quite figure out what the roles of each one are
> and their names are confusingly similiar!
>
> I looked briefly at the older revisions of the series but it didn't make
> things much clearer.
>
> Could you give them clearer names?
thanks for the comments,
It is indeed not easy to understand by the name. I will change it to a
proper name if we have next version patch.
Jiri Slaby is worring about the performance, because we need add two
locks to protect 'out_ch' and 'out_buf' separately, the origin on-stack
buffer is lockless.
I don't know whether this solution can be accepted, just waiting for
Jiri's further commtents.
>
> Also, looking at Documentation/process/deprecated.rst, it looks like
> maybe we want to use a 'flexible array member' instead:
>
> .. note:: If you are using struct_size() on a structure containing a zero-length
> or a one-element array as a trailing array member, please refactor such
> array usage and switch to a `flexible array member
> <#zero-length-and-one-element-arrays>`_ instead.
>
> I think we want:
thanks, we should use [], not [0].
>
>> + char outbuf[] __ALIGNED__;
> Kind regards,
> Daniel
^ permalink raw reply
* Re: [PATCH v2 57/63] powerpc/signal32: Use struct_group() to zero spe regs
From: Christophe Leroy @ 2021-08-20 7:53 UTC (permalink / raw)
To: Michael Ellerman, Kees Cook, linux-kernel
Cc: kernel test robot, Rasmus Villemoes, Greg Kroah-Hartman,
linux-staging, linux-wireless, Gustavo A. R. Silva, dri-devel,
linux-block, clang-built-linux, netdev, Paul Mackerras,
linux-hardening, Sudeep Holla, Andrew Morton, linuxppc-dev,
linux-kbuild
In-Reply-To: <877dggeesw.fsf@mpe.ellerman.id.au>
Le 20/08/2021 à 09:49, Michael Ellerman a écrit :
> Kees Cook <keescook@chromium.org> writes:
>> In preparation for FORTIFY_SOURCE performing compile-time and run-time
>> field bounds checking for memset(), avoid intentionally writing across
>> neighboring fields.
>>
>> Add a struct_group() for the spe registers so that memset() can correctly reason
>> about the size:
>>
>> In function 'fortify_memset_chk',
>> inlined from 'restore_user_regs.part.0' at arch/powerpc/kernel/signal_32.c:539:3:
>>>> include/linux/fortify-string.h:195:4: error: call to '__write_overflow_field' declared with attribute warning: detected write beyond size of field (1st parameter); maybe use struct_group()? [-Werror=attribute-warning]
>> 195 | __write_overflow_field();
>> | ^~~~~~~~~~~~~~~~~~~~~~~~
>>
>> Cc: Michael Ellerman <mpe@ellerman.id.au>
>> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
>> Cc: Paul Mackerras <paulus@samba.org>
>> Cc: Christophe Leroy <christophe.leroy@csgroup.eu>
>> Cc: Sudeep Holla <sudeep.holla@arm.com>
>> Cc: linuxppc-dev@lists.ozlabs.org
>> Reported-by: kernel test robot <lkp@intel.com>
>> Signed-off-by: Kees Cook <keescook@chromium.org>
>> ---
>> arch/powerpc/include/asm/processor.h | 6 ++++--
>> arch/powerpc/kernel/signal_32.c | 6 +++---
>> 2 files changed, 7 insertions(+), 5 deletions(-)
>>
>> diff --git a/arch/powerpc/include/asm/processor.h b/arch/powerpc/include/asm/processor.h
>> index f348e564f7dd..05dc567cb9a8 100644
>> --- a/arch/powerpc/include/asm/processor.h
>> +++ b/arch/powerpc/include/asm/processor.h
>> @@ -191,8 +191,10 @@ struct thread_struct {
>> int used_vsr; /* set if process has used VSX */
>> #endif /* CONFIG_VSX */
>> #ifdef CONFIG_SPE
>> - unsigned long evr[32]; /* upper 32-bits of SPE regs */
>> - u64 acc; /* Accumulator */
>> + struct_group(spe,
>> + unsigned long evr[32]; /* upper 32-bits of SPE regs */
>> + u64 acc; /* Accumulator */
>> + );
>> unsigned long spefscr; /* SPE & eFP status */
>> unsigned long spefscr_last; /* SPEFSCR value on last prctl
>> call or trap return */
>> diff --git a/arch/powerpc/kernel/signal_32.c b/arch/powerpc/kernel/signal_32.c
>> index 0608581967f0..77b86caf5c51 100644
>> --- a/arch/powerpc/kernel/signal_32.c
>> +++ b/arch/powerpc/kernel/signal_32.c
>> @@ -532,11 +532,11 @@ static long restore_user_regs(struct pt_regs *regs,
>> regs_set_return_msr(regs, regs->msr & ~MSR_SPE);
>> if (msr & MSR_SPE) {
>> /* restore spe registers from the stack */
>> - unsafe_copy_from_user(current->thread.evr, &sr->mc_vregs,
>> - ELF_NEVRREG * sizeof(u32), failed);
>> + unsafe_copy_from_user(¤t->thread.spe, &sr->mc_vregs,
>> + sizeof(current->thread.spe), failed);
>
> This makes me nervous, because the ABI is that we copy ELF_NEVRREG *
> sizeof(u32) bytes, not whatever sizeof(current->thread.spe) happens to
> be.
>
> ie. if we use sizeof an inadvertent change to the fields in
> thread_struct could change how many bytes we copy out to userspace,
> which would be an ABI break.
>
> And that's not that hard to do, because it's not at all obvious that the
> size and layout of fields in thread_struct affects the user ABI.
>
> At the same time we don't want to copy the right number of bytes but
> the wrong content, so from that point of view using sizeof is good :)
>
> The way we handle it in ptrace is to have BUILD_BUG_ON()s to verify that
> things match up, so maybe we should do that here too.
>
> ie. add:
>
> BUILD_BUG_ON(sizeof(current->thread.spe) == ELF_NEVRREG * sizeof(u32));
You mean != I guess ?
>
>
> Not sure if you are happy doing that as part of this patch. I can always
> do it later if not.
>
> cheers
>
^ permalink raw reply
* Re: [PATCH v2 57/63] powerpc/signal32: Use struct_group() to zero spe regs
From: Michael Ellerman @ 2021-08-20 7:49 UTC (permalink / raw)
To: Kees Cook, linux-kernel
Cc: Kees Cook, Rasmus Villemoes, Greg Kroah-Hartman, linux-staging,
linux-wireless, Gustavo A. R. Silva, linux-hardening, linux-block,
clang-built-linux, netdev, Paul Mackerras, dri-devel,
Sudeep Holla, Andrew Morton, linuxppc-dev, linux-kbuild,
kernel test robot
In-Reply-To: <20210818060533.3569517-58-keescook@chromium.org>
Kees Cook <keescook@chromium.org> writes:
> In preparation for FORTIFY_SOURCE performing compile-time and run-time
> field bounds checking for memset(), avoid intentionally writing across
> neighboring fields.
>
> Add a struct_group() for the spe registers so that memset() can correctly reason
> about the size:
>
> In function 'fortify_memset_chk',
> inlined from 'restore_user_regs.part.0' at arch/powerpc/kernel/signal_32.c:539:3:
>>> include/linux/fortify-string.h:195:4: error: call to '__write_overflow_field' declared with attribute warning: detected write beyond size of field (1st parameter); maybe use struct_group()? [-Werror=attribute-warning]
> 195 | __write_overflow_field();
> | ^~~~~~~~~~~~~~~~~~~~~~~~
>
> Cc: Michael Ellerman <mpe@ellerman.id.au>
> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Cc: Paul Mackerras <paulus@samba.org>
> Cc: Christophe Leroy <christophe.leroy@csgroup.eu>
> Cc: Sudeep Holla <sudeep.holla@arm.com>
> Cc: linuxppc-dev@lists.ozlabs.org
> Reported-by: kernel test robot <lkp@intel.com>
> Signed-off-by: Kees Cook <keescook@chromium.org>
> ---
> arch/powerpc/include/asm/processor.h | 6 ++++--
> arch/powerpc/kernel/signal_32.c | 6 +++---
> 2 files changed, 7 insertions(+), 5 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/processor.h b/arch/powerpc/include/asm/processor.h
> index f348e564f7dd..05dc567cb9a8 100644
> --- a/arch/powerpc/include/asm/processor.h
> +++ b/arch/powerpc/include/asm/processor.h
> @@ -191,8 +191,10 @@ struct thread_struct {
> int used_vsr; /* set if process has used VSX */
> #endif /* CONFIG_VSX */
> #ifdef CONFIG_SPE
> - unsigned long evr[32]; /* upper 32-bits of SPE regs */
> - u64 acc; /* Accumulator */
> + struct_group(spe,
> + unsigned long evr[32]; /* upper 32-bits of SPE regs */
> + u64 acc; /* Accumulator */
> + );
> unsigned long spefscr; /* SPE & eFP status */
> unsigned long spefscr_last; /* SPEFSCR value on last prctl
> call or trap return */
> diff --git a/arch/powerpc/kernel/signal_32.c b/arch/powerpc/kernel/signal_32.c
> index 0608581967f0..77b86caf5c51 100644
> --- a/arch/powerpc/kernel/signal_32.c
> +++ b/arch/powerpc/kernel/signal_32.c
> @@ -532,11 +532,11 @@ static long restore_user_regs(struct pt_regs *regs,
> regs_set_return_msr(regs, regs->msr & ~MSR_SPE);
> if (msr & MSR_SPE) {
> /* restore spe registers from the stack */
> - unsafe_copy_from_user(current->thread.evr, &sr->mc_vregs,
> - ELF_NEVRREG * sizeof(u32), failed);
> + unsafe_copy_from_user(¤t->thread.spe, &sr->mc_vregs,
> + sizeof(current->thread.spe), failed);
This makes me nervous, because the ABI is that we copy ELF_NEVRREG *
sizeof(u32) bytes, not whatever sizeof(current->thread.spe) happens to
be.
ie. if we use sizeof an inadvertent change to the fields in
thread_struct could change how many bytes we copy out to userspace,
which would be an ABI break.
And that's not that hard to do, because it's not at all obvious that the
size and layout of fields in thread_struct affects the user ABI.
At the same time we don't want to copy the right number of bytes but
the wrong content, so from that point of view using sizeof is good :)
The way we handle it in ptrace is to have BUILD_BUG_ON()s to verify that
things match up, so maybe we should do that here too.
ie. add:
BUILD_BUG_ON(sizeof(current->thread.spe) == ELF_NEVRREG * sizeof(u32));
Not sure if you are happy doing that as part of this patch. I can always
do it later if not.
cheers
^ permalink raw reply
* Re: [PATCH v8 2/3] tty: hvc: pass DMA capable memory to put_chars()
From: Daniel Axtens @ 2021-08-20 6:49 UTC (permalink / raw)
To: Xianting Tian, gregkh, jirislaby, amit, arnd, osandov
Cc: Xianting Tian, shile.zhang, linuxppc-dev, linux-kernel,
virtualization
In-Reply-To: <20210818082122.166881-3-xianting.tian@linux.alibaba.com>
Xianting Tian <xianting.tian@linux.alibaba.com> writes:
> As well known, hvc backend driver(eg, virtio-console) can register its
> operations to hvc framework. The operations can contain put_chars(),
> get_chars() and so on.
>
> Some hvc backend may do dma in its operations. eg, put_chars() of
> virtio-console. But in the code of hvc framework, it may pass DMA
> incapable memory to put_chars() under a specific configuration, which
> is explained in commit c4baad5029(virtio-console: avoid DMA from stack):
We could also run into issues on powerpc where Andrew is working on
adding vmap-stack but the opal hvc driver assumes that it is passed a
buffer which is not in vmalloc space but in the linear mapping. So it
would be good to fix this (or more clearly document what drivers can
expect).
> 1, c[] is on stack,
> hvc_console_print():
> char c[N_OUTBUF] __ALIGNED__;
> cons_ops[index]->put_chars(vtermnos[index], c, i);
> 2, ch is on stack,
> static void hvc_poll_put_char(,,char ch)
> {
> struct tty_struct *tty = driver->ttys[0];
> struct hvc_struct *hp = tty->driver_data;
> int n;
>
> do {
> n = hp->ops->put_chars(hp->vtermno, &ch, 1);
> } while (n <= 0);
> }
>
> Commit c4baad5029 is just the fix to avoid DMA from stack memory, which
> is passed to virtio-console by hvc framework in above code. But I think
> the fix is aggressive, it directly uses kmemdup() to alloc new buffer
> from kmalloc area and do memcpy no matter the memory is in kmalloc area
> or not. But most importantly, it should better be fixed in the hvc
> framework, by changing it to never pass stack memory to the put_chars()
> function in the first place. Otherwise, we still face the same issue if
> a new hvc backend using dma added in the future.
>
> In this patch, we make 'char out_buf[N_OUTBUF]' and 'chat out_ch' part
> of 'struct hvc_struct', so both two buf are no longer the stack memory.
> we can use it in above two cases separately.
>
> Introduce another array(cons_outbufs[]) for buffer pointers next to
> the cons_ops[] and vtermnos[] arrays. With the array, we can easily find
> the buffer, instead of traversing hp list.
>
> With the patch, we can remove the fix c4baad5029.
>
> Signed-off-by: Xianting Tian <xianting.tian@linux.alibaba.com>
> Reviewed-by: Shile Zhang <shile.zhang@linux.alibaba.com>
> struct hvc_struct {
> struct tty_port port;
> spinlock_t lock;
> int index;
> int do_wakeup;
> - char *outbuf;
> - int outbuf_size;
> int n_outbuf;
> uint32_t vtermno;
> const struct hv_ops *ops;
> @@ -48,6 +56,10 @@ struct hvc_struct {
> struct work_struct tty_resize;
> struct list_head next;
> unsigned long flags;
> + char out_ch;
> + char out_buf[N_OUTBUF] __ALIGNED__;
> + int outbuf_size;
> + char outbuf[0] __ALIGNED__;
I'm trying to understand this patch but I am finding it very difficult
to understand what the difference between `out_buf` and `outbuf`
(without the underscore) is supposed to be. `out_buf` is statically
sized and the size of `outbuf` is supposed to depend on the arguments to
hvc_alloc(), but I can't quite figure out what the roles of each one are
and their names are confusingly similiar!
I looked briefly at the older revisions of the series but it didn't make
things much clearer.
Could you give them clearer names?
Also, looking at Documentation/process/deprecated.rst, it looks like
maybe we want to use a 'flexible array member' instead:
.. note:: If you are using struct_size() on a structure containing a zero-length
or a one-element array as a trailing array member, please refactor such
array usage and switch to a `flexible array member
<#zero-length-and-one-element-arrays>`_ instead.
I think we want:
> + char outbuf[] __ALIGNED__;
Kind regards,
Daniel
^ permalink raw reply
* [PATCH] powerpc: Avoid link stack corruption in {add_}reloc_offset
From: Christophe Leroy @ 2021-08-20 5:16 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman
Cc: linuxppc-dev, linux-kernel
reloc_offset() / add_reloc_offset() used bl;mflr to get code
position.
Use bcl 20,31,+4 instead of bl in order to preserve link stack.
See commit c974809a26a1 ("powerpc/vdso: Avoid link stack corruption
in __get_datapage()") for details.
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
---
arch/powerpc/kernel/misc.S | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/kernel/misc.S b/arch/powerpc/kernel/misc.S
index 5be96feccb55..acd557637a3c 100644
--- a/arch/powerpc/kernel/misc.S
+++ b/arch/powerpc/kernel/misc.S
@@ -29,7 +29,7 @@ _GLOBAL(reloc_offset)
li r3, 0
_GLOBAL(add_reloc_offset)
mflr r0
- bl 1f
+ bcl 20,31,1f
1: mflr r5
PPC_LL r4,(2f-1b)(r5)
subf r5,r4,r5
--
2.25.0
^ permalink raw reply related
* [PATCH] powerpc/32: indirect function call use bctrl rather than blrl in ret_from_kernel_thread
From: Christophe Leroy @ 2021-08-20 5:16 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman
Cc: linuxppc-dev, linux-kernel
Copied from commit 89bbe4c798bc ("powerpc/64: indirect function call
use bctrl rather than blrl in ret_from_kernel_thread")
blrl is not recommended to use as an indirect function call, as it may
corrupt the link stack predictor.
This is not a performance critical path but this should be fixed for
consistency.
Signed-off-by: Christophe Leroy <christophe.leroy@csgroup.eu>
---
arch/powerpc/kernel/entry_32.S | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/kernel/entry_32.S b/arch/powerpc/kernel/entry_32.S
index 0273a1349006..61fdd53cdd9a 100644
--- a/arch/powerpc/kernel/entry_32.S
+++ b/arch/powerpc/kernel/entry_32.S
@@ -161,10 +161,10 @@ ret_from_fork:
ret_from_kernel_thread:
REST_NVGPRS(r1)
bl schedule_tail
- mtlr r14
+ mtctr r14
mr r3,r15
PPC440EP_ERR42
- blrl
+ bctrl
li r3,0
b ret_from_syscall
--
2.25.0
^ permalink raw reply related
* Re: [PATCH v2 2/2] powerpc: rectify selection to ARCH_ENABLE_SPLIT_PMD_PTLOCK
From: Michael Ellerman @ 2021-08-20 4:25 UTC (permalink / raw)
To: Daniel Axtens, Lukas Bulwahn, Paul Mackerras,
Benjamin Herrenschmidt, Michael Neuling, Anshuman Khandual,
kvm-ppc, linuxppc-dev
Cc: Lukas Bulwahn, kernel-janitors, linux-kernel, stable
In-Reply-To: <87pmu99e4j.fsf@dja-thinkpad.axtens.net>
Daniel Axtens <dja@axtens.net> writes:
> Lukas Bulwahn <lukas.bulwahn@gmail.com> writes:
>
>> Commit 66f24fa766e3 ("mm: drop redundant ARCH_ENABLE_SPLIT_PMD_PTLOCK")
>> selects the non-existing config ARCH_ENABLE_PMD_SPLIT_PTLOCK in
>> ./arch/powerpc/platforms/Kconfig.cputype, but clearly it intends to select
>> ARCH_ENABLE_SPLIT_PMD_PTLOCK here (notice the word swapping!), as this
>> commit does select that for all other architectures.
>>
>> Rectify selection to ARCH_ENABLE_SPLIT_PMD_PTLOCK instead.
>>
>
> Yikes, yes, 66f24fa766e3 does seem to have got that wrong. It looks like
> that went into 5.13.
>
> I think we want to specifically target this for stable so that we don't
> lose the perfomance and scalability benefits of split pmd ptlocks:
>
> Cc: stable@vger.kernel.org # v5.13+
>
> (I don't think you need to do another revision for this, I think mpe
> could add it when merging.)
Yeah. I rewrote the change log a bit to make it clear this is a bug fix,
not a harmless cleanup.
cheers
powerpc: Re-enable ARCH_ENABLE_SPLIT_PMD_PTLOCK
Commit 66f24fa766e3 ("mm: drop redundant ARCH_ENABLE_SPLIT_PMD_PTLOCK")
broke PMD split page table lock for powerpc.
It selects the non-existent config ARCH_ENABLE_PMD_SPLIT_PTLOCK in
arch/powerpc/platforms/Kconfig.cputype, but clearly intended to
select ARCH_ENABLE_SPLIT_PMD_PTLOCK (notice the word swapping!), as
that commit did for all other architectures.
Fix it by selecting the correct symbol ARCH_ENABLE_SPLIT_PMD_PTLOCK.
Fixes: 66f24fa766e3 ("mm: drop redundant ARCH_ENABLE_SPLIT_PMD_PTLOCK")
Cc: stable@vger.kernel.org # v5.13+
Signed-off-by: Lukas Bulwahn <lukas.bulwahn@gmail.com>
Reviewed-by: Daniel Axtens <dja@axtens.net>
[mpe: Reword change log to make it clear this is a bug fix]
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/20210819113954.17515-3-lukas.bulwahn@gmail.com
^ permalink raw reply
* [PATCH linux-next] ps3: remove unneeded semicolon
From: jing yangyang @ 2021-08-20 2:49 UTC (permalink / raw)
To: Geoff Levand
Cc: jing yangyang, Zeal Robot, linux-kernel, Paul Mackerras,
linuxppc-dev
Eliminate the following coccicheck warning:
./arch/powerpc/platforms/ps3/system-bus.c:606:2-3: Unneeded semicolon
./arch/powerpc/platforms/ps3/system-bus.c:765:2-3: Unneeded semicolon
Reported-by: Zeal Robot <zealci@zte.com.cn>
Signed-off-by: jing yangyang <jing.yangyang@zte.com.cn>
---
arch/powerpc/platforms/ps3/system-bus.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/platforms/ps3/system-bus.c b/arch/powerpc/platforms/ps3/system-bus.c
index c8b50fe..b637bf2 100644
--- a/arch/powerpc/platforms/ps3/system-bus.c
+++ b/arch/powerpc/platforms/ps3/system-bus.c
@@ -603,7 +603,7 @@ static dma_addr_t ps3_ioc0_map_page(struct device *_dev, struct page *page,
default:
/* not happned */
BUG();
- };
+ }
result = ps3_dma_map(dev->d_region, (unsigned long)ptr, size,
&bus_addr, iopte_flag);
@@ -762,7 +762,7 @@ int ps3_system_bus_device_register(struct ps3_system_bus_device *dev)
break;
default:
BUG();
- };
+ }
dev->core.of_node = NULL;
set_dev_node(&dev->core, 0);
--
1.8.3.1
^ 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