From: Andy Lutomirski <luto@kernel.org>
To: Borislav Petkov <bp@alien8.de>
Cc: Andy Lutomirski <luto@kernel.org>,
Simon Marchi <simon.marchi@polymtl.ca>,
Stefan Metzmacher <metze@samba.org>,
Peter Zijlstra <peterz@infradead.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
Thomas Gleixner <tglx@linutronix.de>,
Jens Axboe <axboe@kernel.dk>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
io-uring <io-uring@vger.kernel.org>,
"the arch/x86 maintainers" <x86@kernel.org>,
linux-toolchains@vger.kernel.org
Subject: Re: [PATCH] io_thread/x86: don't reset 'cs', 'ss', 'ds' and 'es' registers for io_threads
Date: Wed, 5 May 2021 16:22:29 -0700 [thread overview]
Message-ID: <CALCETrXieCM3f2sYQLk36horw1Cgt9OrZyDqCYrN71VgGusdVg@mail.gmail.com> (raw)
In-Reply-To: <YJMmVHGn33W2n2Ux@zn.tnic>
On Wed, May 5, 2021 at 4:12 PM Borislav Petkov <bp@alien8.de> wrote:
>
> On Wed, May 05, 2021 at 03:11:18PM -0700, Andy Lutomirski wrote:
> > Since I'm not holding my breath, please at least keep in mind that
> > anything you do here is merely a heuristic, cannot be fully correct,
> > and then whenever gdb determines that a thread group or a thread is
> > "32-bit", gdb is actually deciding to operate in a degraded mode for
> > that task, is not accurately representing the task state, and is at
> > risk of crashing, malfunctioning, or crashing the inferior due to its
> > incorrect assumptions. If you have ever attached gdb to QEMU's
> > gdbserver and tried to debug the early boot process of a 64-bit Linux
> > kernel, you may have encountered this class of bugs. gdb works very,
> > very poorly for this use case.
>
> So we were talking about this with toolchain folks today and they gave
> me this example:
>
> Imagine you've stopped the target this way:
>
> <insn><-- stopped here
> <insn>
> <mode changing insn>
> <insn>
> <insn>
> ...
>
> now, if you dump rIP and say, rIP + the 10 following insns at the place
> you've stopped it, gdb cannot know that 2 insns further into the stream
> a
>
> <mode changing insn>
>
> is coming and it should change the disassembly of the insns after that
> <mode changing insn> to the new mode. Unless it goes and inspects all
> further instructions and disassembles them and analyzes the flow...
That's fine. x86 machine code is like this. You also can't
disassemble instructions before rIP accurately either.
>
> So what you can do is
>
> (gdb) set arch ...
>
> at the <mode changing insn> to the mode you're changing to.
>
> Dunno, maybe I'm missing something but this sounds like without user
> help gdb can only assume things.
In the tools/testing/x86/selftests directory, edited slightly for brevity:
$ gdb ./test_syscall_vdso_32
(gdb) b call64_from_32
Breakpoint 1 at 0x80499ef: file thunks_32.S, line 19.
(gdb) display/i $pc
1: x/i $pc
<error: No registers.>
(gdb) r
Starting program:
/home/luto/apps/linux/tools/testing/selftests/x86/test_syscall_vdso_32
...
[RUN] Executing 6-argument 32-bit syscall via VDSO
Breakpoint 1, call64_from_32 () at thunks_32.S:19
19 mov 4(%esp), %eax
1: x/i $pc
=> 0x80499ef <call64_from_32>: mov 0x4(%esp),%eax
(gdb) si
22 push %ecx
1: x/i $pc
=> 0x80499f3 <call64_from_32+4>: push %ecx
(gdb)
call64_from_32 () at thunks_32.S:23
23 push %edx
1: x/i $pc
=> 0x80499f4 <call64_from_32+5>: push %edx
(gdb)
call64_from_32 () at thunks_32.S:24
24 push %esi
1: x/i $pc
=> 0x80499f5 <call64_from_32+6>: push %esi
(gdb)
call64_from_32 () at thunks_32.S:25
25 push %edi
1: x/i $pc
=> 0x80499f6 <call64_from_32+7>: push %edi
(gdb)
call64_from_32 () at thunks_32.S:28
28 jmp $0x33,$1f
1: x/i $pc
=> 0x80499f7 <call64_from_32+8>: ljmp $0x33,$0x80499fe
(gdb) info registers
eax 0x80492e8 134517480
ecx 0x3f 63
edx 0x1 1
ebx 0xf7fc8550 -134445744
esp 0xffffc57c 0xffffc57c
ebp 0xffffc5e8 0xffffc5e8
esi 0x0 0
edi 0x8049180 134517120
eip 0x80499f7 0x80499f7 <call64_from_32+8>
eflags 0x292 [ AF SF IF ]
cs 0x23 35
ss 0x2b 43
ds 0x2b 43
es 0x2b 43
fs 0x0 0
gs 0x63 99
(gdb) si
32 call *%rax
1: x/i $pc
=> 0x80499fe <call64_from_32+15>: call *%eax
(gdb) info registers
eax 0x80492e8 134517480
^^^ Should be rax
ecx 0x3f 63
edx 0x1 1
ebx 0xf7fc8550 -134445744
esp 0xffffc57c 0xffffc57c
ebp 0xffffc5e8 0xffffc5e8
esi 0x0 0
edi 0x8049180 134517120
eip 0x80499fe 0x80499fe <call64_from_32+15>
^^^ r8, etc are all missing
eflags 0x292 [ AF SF IF ]
cs 0x33 51
^^^ 64-bit!
ss 0x2b 43
ds 0x2b 43
es 0x2b 43
fs 0x0 0
gs 0x63 99
(gdb) si
poison_regs64 () at test_syscall_vdso.c:35
35 long syscall_addr;
1: x/i $pc
=> 0x80492e8 <poison_regs64>: dec %ecx
(gdb) si
36 long get_syscall(char **envp)
1: x/i $pc
=> 0x80492ef <poison_regs64+7>: dec %ecx
(gdb) set arch i386:x86-64
warning: Selected architecture i386:x86-64 is not compatible with
reported target architecture i386
Architecture `i386:x86-64' not recognized.
The target architecture is set to "auto" (currently "i386").
(gdb) set arch i386:x86-64:intel
warning: Selected architecture i386:x86-64:intel is not compatible
with reported target architecture i386
Architecture `i386:x86-64:intel' not recognized.
The target architecture is set to "auto" (currently "i386").
I don't know enough about gdb internals to know precisely what failed
here, but this did not work the way it should have.
Sure, ptrace should provide a nice API to figure out that CS == 0x33
means long mode, but gdb could do a whole lot better here.
next prev parent reply other threads:[~2021-05-05 23:22 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <8735v3ex3h.ffs@nanos.tec.linutronix.de>
[not found] ` <3C41339D-29A2-4AB1-958F-19DB0A92D8D7@amacapital.net>
[not found] ` <CAHk-=wh0KoEZXPYMGkfkeVEerSCEF1AiCZSvz9TRrx=Kj74D+Q@mail.gmail.com>
2021-05-04 8:39 ` [PATCH] io_thread/x86: don't reset 'cs', 'ss', 'ds' and 'es' registers for io_threads Peter Zijlstra
2021-05-04 15:35 ` Borislav Petkov
2021-05-04 15:55 ` Simon Marchi
2021-05-05 11:29 ` Stefan Metzmacher
2021-05-05 21:59 ` Simon Marchi
2021-05-05 22:11 ` Andy Lutomirski
2021-05-05 23:12 ` Borislav Petkov
2021-05-05 23:22 ` Andy Lutomirski [this message]
2021-05-06 1:04 ` Simon Marchi
2021-05-06 15:11 ` Andy Lutomirski
2021-05-06 9:47 ` David Laight
2021-05-06 9:53 ` David Laight
2021-05-05 22:21 ` Stefan Metzmacher
2021-05-05 23:15 ` Simon Marchi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CALCETrXieCM3f2sYQLk36horw1Cgt9OrZyDqCYrN71VgGusdVg@mail.gmail.com \
--to=luto@kernel.org \
--cc=axboe@kernel.dk \
--cc=bp@alien8.de \
--cc=io-uring@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-toolchains@vger.kernel.org \
--cc=metze@samba.org \
--cc=peterz@infradead.org \
--cc=simon.marchi@polymtl.ca \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).