linux-kernel - RE: [PATCH] io_thread/x86: don't reset 'cs', 'ss', 'ds' and 'es' registers for io

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

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <2119eef25fec413099a13763f8d34bc1@AcuMS.aculab.com>
Date:   Tue, 4 May 2021 08:22:05 +0000
From:   David Laight <David.Laight@...LAB.COM>
To:     'Linus Torvalds' <torvalds@...ux-foundation.org>,
        Stefan Metzmacher <metze@...ba.org>
CC:     Thomas Gleixner <tglx@...utronix.de>,
        Andy Lutomirski <luto@...nel.org>,
        Jens Axboe <axboe@...nel.dk>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        io-uring <io-uring@...r.kernel.org>,
        "the arch/x86 maintainers" <x86@...nel.org>
Subject: RE: [PATCH] io_thread/x86: don't reset 'cs', 'ss', 'ds' and 'es'
 registers for io_threads

From: Linus Torvalds
> Sent: 04 May 2021 00:48
> 
> On Mon, May 3, 2021 at 4:27 PM Stefan Metzmacher <metze@...ba.org> wrote:
> >
> > If I remember correctly gdb showed bogus addresses for the backtraces of the io_threads,
> > as some regs where not cleared.
> 
> Yeah, so that patch will make the IO thread have the user stack
> pointer point to the original user stack, but that stack will
> obviously be used by the original thread which means that it will
> contain random stuff on it.
> 
> Doing a
> 
>         childregs->sp = 0;
> 
> is probably a good idea for that PF_IO_WORKER case, since it really
> doesn't have - or need - a user stack.
> 
> Of course, it doesn't really have - or need - any of the other user
> registers either, but once you fill in the segment stuff to make gdb
> happy, you might as well fill it all in using the same code that the
> regular case does.

Presumably gdb can only read/write the 'user' registers (normally
saved on kernel entry).
Since these will never be loaded it really doesn't matter (to the
kernel) what is returned to gdb or what gdb writes into them.
The same ought to be true of the FP state.

If gdb writes to an FP (etc) register the process doesn't currently
have (eg an AVX512 register) then that is not really different from
doing it to a normal process.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)