Kees Cook 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:
>
>
Le 20/08/2021 à 09:49, Michael Ellerman a écrit :
Kees Cook 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() c
在 2021/8/20 下午2:49, Daniel Axtens 写道:
Xianting Tian 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
vi
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
---
arch/powerpc/Kconfig | 5 +-
arch/powerpc/kernel/Makefile | 3 --
arch/powerpc/kernel/audit.c| 84 -
Use is_32bit_task() which already handles CONFIG_COMPAT.
Signed-off-by: Christophe Leroy
---
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..c6
Make use of is_32bit_task() and CONFIG_CPU_LITTLE_ENDIAN
to simplify syscall_get_arch().
Signed-off-by: Christophe Leroy
---
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/
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 wit
Christophe Leroy writes:
> Le 20/08/2021 à 09:49, Michael Ellerman a écrit :
>> Kees Cook 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_grou
Christophe Leroy 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 hav
Christophe Leroy 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 ‘r
Christophe Leroy 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
>> ---
>> arch/powerpc/kvm/book3s.h | 1 +
>> 1 file changed, 1 insertion(+)
>>
>> diff --git a/arch/powerpc/kvm/book3s.h b/arch/powerpc/
Cédric Le Goater writes:
> This fixes a compile error with W=1.
>
> Cc: Christophe Leroy
> Signed-off-by: Cédric Le Goater
> ---
> arch/powerpc/include/asm/syscalls.h | 31 +
> 1 file changed, 31 insertions(+)
>
> diff --git a/arch/powerpc/include/asm/syscalls.h
> b
Daniel Axtens writes:
> Xianting Tian 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
>> vi
On Fri, Aug 20, 2021 at 05:49:35PM +1000, Michael Ellerman wrote:
> Kees Cook 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 s
https://bugzilla.kernel.org/show_bug.cgi?id=213837
--- Comment #2 from Erhard F. (erhar...@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 synci
https://bugzilla.kernel.org/show_bug.cgi?id=213837
--- Comment #3 from Erhard F. (erhar...@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
https://bugzilla.kernel.org/show_bug.cgi?id=213079
--- Comment #18 from Erhard F. (erhar...@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 t
On Fri, Aug 20, 2021 at 10:15:11PM +1000, Michael Ellerman wrote:
> Christophe Leroy 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 i
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 writes:
> > > Copied from commit 89bbe4c798bc ("powerpc/64: indirect function call
> > > use bctrl rather than blrl in ret_from_kernel_thread
- On Aug 19, 2021, at 7:33 PM, Sean Christopherson sea...@google.com wrote:
> On Thu, Aug 19, 2021, Mathieu Desnoyers wrote:
>> - On Aug 17, 2021, at 8:12 PM, Sean Christopherson sea...@google.com
>> wrote:
>>
>> > Add a test to verify an rseq's CPU ID is updated correctly if the task is
- On Aug 19, 2021, at 7:48 PM, Sean Christopherson sea...@google.com wrote:
> On Thu, Aug 19, 2021, Mathieu Desnoyers wrote:
>> - On Aug 17, 2021, at 8:12 PM, Sean Christopherson sea...@google.com
>> wrote:
>> > @@ -250,7 +250,7 @@ static int rseq_ip_fixup(struct pt_regs *regs)
>> > *
On Tue, Jul 20, 2021 at 05:01:45PM +0200, Niklas Schnelle wrote:
> The helper function pci_dev_is_added() from drivers/pci/pci.h is used in
> PCI arch code of both s390 and powerpc leading to awkward relative
> includes. Move it to the global include/linux/pci.h and get rid of these
> includes just
On Fri, Aug 20, 2021, Mathieu Desnoyers wrote:
> 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 cp
On Fri, Aug 20, 2021, Mathieu Desnoyers wrote:
> Without the lazy clear scheme, a rseq c.s. would look like:
>
> * init(rseq_cs)
> * cpu = TLS->rseq::cpu_id_start
> * [1] TLS->rseq::rseq_cs = rseq_cs
> * [start_ip]--
Patch 1 fixes a KVM+rseq bug where KVM's handling of TIF_NOTIFY_RESUME,
e.g. for task migration, clears the flag without informing rseq and leads
to stale data in userspace's rseq struct.
Patch 2 is a cleanup to try and make future bugs less likely. It's also
a baby step towards moving and renami
Invoke rseq's NOTIFY_RESUME handler when processing the flag prior to
transferring to a KVM guest, which is roughly equivalent to an exit to
userspace and processes many of the same pending actions. While the task
cannot be in an rseq critical section as the KVM path is reachable only
by via ioctl
Invoke rseq_handle_notify_resume() from tracehook_notify_resume() now
that the two function are always called back-to-back by architectures
that have rseq. The rseq helper is stubbed out for architectures that
don't support rseq, i.e. this is a nop across the board.
Note, tracehook_notify_resume(
Move unistd_{32,64}.h from x86/include/asm to x86/include/uapi/asm so
that tools/selftests that install kernel headers, e.g. KVM selftests, can
include non-uapi tools headers, e.g. to get 'struct list_head', without
effectively overriding the installed non-tool uapi headers.
Swapping KVM's search
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
witho
Revert the __NR_userfaultfd syscall fallback added for KVM selftests now
that x86's unistd_{32,63}.h overrides are under uapi/ and thus not in
KVM sefltests' search path, i.e. now that KVM gets x86 syscall numbers
from the installed kernel headers.
No functional change intended.
Cc: Ben Gardon
S
config
arm allmodconfig
i386 randconfig-c001-20210816
i386 randconfig-c001-20210820
arm lpc18xx_defconfig
sh ap325rxa_defconfig
mips db1xxx_defconfig
armvexpress_defconf
31 matches
Mail list logo
