From: Andy Lutomirski <luto@kernel.org>
To: Simon Marchi <simon.marchi@polymtl.ca>
Cc: Andy Lutomirski <luto@kernel.org>,
Stefan Metzmacher <metze@samba.org>,
Borislav Petkov <bp@alien8.de>,
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: Thu, 6 May 2021 08:11:24 -0700 [thread overview]
Message-ID: <CALCETrUP1+Vy=PJASbXWgUUFHTrskLb+fO2-1huQT7A_GZpTyA@mail.gmail.com> (raw)
In-Reply-To: <f4d0c304-2fe0-087f-90f4-1ad9c1b32694@polymtl.ca>
On Wed, May 5, 2021 at 6:04 PM Simon Marchi <simon.marchi@polymtl.ca> wrote:
>
> On 2021-05-05 6:11 p.m., Andy Lutomirski wrote:
> I looked at how GDB reads registers from a "64-bit" task and a "32-bit"
> task (I have to quote now, since I now know it's an abuse of
> terminology) side by side. And indeed, GDB reads a full 64-bit state in
> both cases. For the 32-bit case, it picks the 32-bit values from that
> buffer. For example, to get the eax value it picks the low 4 bytes of
> rax (well, ax in user_regs_struct).
>
> So I suppose that if GDB wanted to tell nothing but the truth, it would
> present the full 64-bit register state to the user even when debugging a
> 32-bit program. But at the end of the day, the typical user debugging a
> 32-bit program on a 64-bit probably just wants the illusion that they
> are on i386.
True. I see no reason, especially by default, to show the extra
registers. On the other hand, if the program switches modes, having
gdb notice would be nice. And, if gdb handled this correctly, all
this io_uring stuff would be entirely moot. The made-up register
state of the io_uring thread would have no bearing on the debugging of
other threads.
>
> > Now I realize that the ptrace() API is awful and makes life difficult
> > in several respects for no good reason but, if gdb is ever interested
> > in fixing its ideas about architecture to understand that all tasks,
> > even those that think of themselves as "compat", have full 64-bit
> > state, I would be more than willing to improve the ptrace() API as
> > needed to make this work well.
>
> Just wondering, do you have specific ptrace shortcomings in mind when
> saying this? As I found above, ptrace lets us read the whole 64-bit
> register state. After that it's up to us to analyze the state of the
> program based on its registers and memory. What more could ptrace give
> us?
Two specific issues come to mind:
1. PTRACE_GETREGSET and PTRACE_SETREGSET are terminally broken. See
the comment above task_user_regset_view() in arch/x86/kernel/ptrace.c.
We need a new version of those APIs that takes an e_machine parameter.
(I don't even see how you can call these APIs safely at all, short of
allocating a buffer with a guard page or intentionally over-allocating
and calculating the maximum possible size of buffer that could be used
in case of a screwup.)
2. There should be an API to either read the descriptor table or to
look up a specific descriptor. How else are you supposed to know
whether CS.L is set? (Keep in mind that 0x33 is not necessarily the
only long mode segment that gets used. Linux on Xen PV has an extra
one.)
--Andy
next prev parent reply other threads:[~2021-05-06 15:11 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
2021-05-06 1:04 ` Simon Marchi
2021-05-06 15:11 ` Andy Lutomirski [this message]
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='CALCETrUP1+Vy=PJASbXWgUUFHTrskLb+fO2-1huQT7A_GZpTyA@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 read-only IMAP folder(s) and NNTP newsgroup(s).