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: Sat, 3 Apr 2021 02:48:26 +0200 From: Stefan Metzmacher <metze@...ba.org> To: Linus Torvalds <torvalds@...ux-foundation.org> Cc: Jens Axboe <axboe@...nel.dk>, io-uring <io-uring@...r.kernel.org>, "Eric W. Biederman" <ebiederm@...ssion.com>, Oleg Nesterov <oleg@...hat.com>, Linux Kernel Mailing List <linux-kernel@...r.kernel.org> Subject: Re: [PATCH 0/6] Allow signals for IO threads Am 01.04.21 um 18:24 schrieb Linus Torvalds: > On Thu, Apr 1, 2021 at 9:00 AM Stefan Metzmacher <metze@...ba.org> wrote: >> >> I haven't tried it, but it seems gdb tries to use PTRACE_PEEKUSR >> against the last thread tid listed under /proc/<pid>/tasks/ in order to >> get the architecture for the userspace application > > Christ, what an odd hack. Why wouldn't it just do it on the initial > thread you actually attached to? > > Are you sure it's not simply because your test-case was to attach to > the io_uring thread? Because the io_uring thread might as well be > considered to be 64-bit. │ └─io_uring-cp,1396 Makefile file │ ├─{iou-mgr-1396},1397 │ ├─{iou-wrk-1396},1398 │ └─{iou-wrk-1396},1399 strace -ttT -o strace-uring-fail.txt gdb --pid 1396 (note strace -f would deadlock gdb with SIGSTOP) The full file can be found here: https://www.samba.org/~metze/strace-uring-fail.txt (I guess there was a race and the workers 1398 and 1399 exited in between, that's it using 1397): 18:46:35.429498 ptrace(PTRACE_PEEKUSER, 1397, 8*CS, [NULL]) = 0 <0.000022> >> so my naive assumption >> would be that it wouldn't allow the detection of a 32-bit application >> using a 64-bit kernel. > > I'm not entirely convinced we want to care about a confused gdb > implementation and somebody debugging a case that I don't believe > happens in practice. > > 32-bit user space is legacy. And legacy isn't io_uring. If somebody > insists on doing odd things, they can live with the odd results. Ok, I'd agree for 32-bit applications, but what about libraries? E.g. distributions ship libraries like libsmbclient or nss modules as 64-bit and 32-bit version, in order to support legacy applications to run. Why shouldn't the 32-bit library builds not support io_uring? (Note libsmbclient don't use io_uring yet, but I guess it will be in future). Any ideas regarding similar problems for other architectures? metze
Powered by blists - more mailing lists