Messages in this thread | | | From | Andy Lutomirski <> | Date | Thu, 30 Mar 2017 12:21:13 -0700 | Subject | Re: syscall_get_error() && TS_ checks |
| |
On Thu, Mar 30, 2017 at 12:11 PM, Linus Torvalds <torvalds@linux-foundation.org> wrote: > On Thu, Mar 30, 2017 at 11:59 AM, Andy Lutomirski <luto@amacapital.net> wrote: >>> >>> And then actually run such a kernel on a 32-bit distro, and verifying >>> that things like gdb and strace really work. But it needs real >>> testing, not some kind of handwaving. It's a *big* change. >> >> I'll offer the following handwave: if there are problems, I'd expect >> to see them in mixed-bitness uses, not 32-bit distros. But the 32-bit >> case is worth testing, too. > > I wouldn't worry too much about the mixed case, simply because you > clearly cannot use a 32-bit gdb on a 64-bit process. > > So the mixed case already needs to use a 64-bit gdb, which presumably > would never use the 32-bit ptrace paths in the first place, so this > code never triggers. >
Hah. Hah hah. IIRC 64-bit gdb *does* use the 32-bit paths, or at least it uses some path that can't see the high regs. I don't fully recall, but this is the case that seems more likely to break to me. It's a great big mess.
> Of course, the mroe testing the better, but the thing I'd really want > to check is that there isn't some 32-bit distro that might have a > library that is optimized and notices when it's running on a 64-bit > capable CPU and uses REX prefixes to use special optimized versions.
Huh? Aren't those REX prefixes interpreted as INC instructions or similar in compat mode? You can't just run 64-bit instructions in a compat code segment. You *can* use LAR to find a 64-bit code segment and long-jump to it (and I've written code to do exactly that, and it's even snuck it's way into linux.git, muahaha), but code like this is terminally screwed under 32-bit gdb.
| |