lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Wed, 12 Jan 2022 08:55:24 +0100 From: Geert Uytterhoeven <geert@...ux-m68k.org> To: Michael Schmitz <schmitzmic@...il.com> Cc: Finn Thain <fthain@...ux-m68k.org>, Al Viro <viro@...iv.linux.org.uk>, "Eric W. Biederman" <ebiederm@...ssion.com>, Linux Kernel Mailing List <linux-kernel@...r.kernel.org>, Linux-Arch <linux-arch@...r.kernel.org>, Linus Torvalds <torvalds@...ux-foundation.org>, Oleg Nesterov <oleg@...hat.com>, Kees Cook <keescook@...omium.org>, Linux API <linux-api@...r.kernel.org>, linux-m68k <linux-m68k@...ts.linux-m68k.org> Subject: Re: [PATCH 08/17] ptrace/m68k: Stop open coding ptrace_report_syscall Hi Michael, On Wed, Jan 12, 2022 at 1:20 AM Michael Schmitz <schmitzmic@...il.com> wrote: > Am 12.01.2022 um 11:42 schrieb Finn Thain: > > On Tue, 11 Jan 2022, Michael Schmitz wrote: > >>> In fact Michael did so in "[PATCH v7 1/2] m68k/kernel - wire up > >>> syscall_trace_enter/leave for m68k"[1], but that's still stuck... > >>> > >>> [1] > >>> https://lore.kernel.org/r/1624924520-17567-2-git-send-email-schmitzmic@gmail.com/ > >> > >> That patch (for reasons I never found out) did interact badly with > >> Christoph Hellwig's 'remove set_fs' patches (and Al's signal fixes which > >> Christoph's patches are based upon). Caused format errors under memory > >> stress tests quite reliably, on my 030 hardware. > >> > > > > Those patches have since been merged, BTW. > > Yes, that's why I advised caution with mine. > > > > >> Probably needs a fresh look - the signal return path got changed by Al's > >> patches IIRC, and I might have relied on offsets to data on the stack > >> that are no longer correct with these patches. Or there's a race between > >> the syscall trap and signal handling when returning from interrupt > >> context ... > >> > >> Still school hols over here so I won't have much peace and quiet until > >> February. > >> > > > > So the patch works okay with Aranym 68040 but not Motorola 68030? Since > > Correct - I seem to recall we also tested those on your 040 and there > was no regression there, but I may be misremembering that. > > > there is at least one known issue affecting both Motorola 68030 and Hatari > > 68030, perhaps this patch is not the problem. In anycase, Al's suggestion > > I hadn't ever made that connection, but it might be another explanation, > yes. > > > to split the patch into two may help in that testing two smaller patches > > might narrow down the root cause. > > That's certainly true. > > What's the other reason these patches are still stuck, Geert? Did we > ever settle the dispute about what return code ought to abort a syscall > (in the seccomp context)? IIRC, some (self)tests were still failing? Gr{oetje,eeting}s, Geert -- Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@...ux-m68k.org In personal conversations with technical people, I call myself a hacker. But when I'm talking to journalists I just say "programmer" or something like that. -- Linus Torvalds
Powered by blists - more mailing lists