linux-kernel - Re: SYSCALL, ptrace and syscall restart breakages (Re: [RFC] weird crap with vdso on uml/i386)

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: <CAObL_7HY7qFUoqtNju42=BHTR8WuuW-cL_cQh_uUfx_7gFfHRg@mail.gmail.com>
Date:	Sun, 21 Aug 2011 22:26:00 -0400
From:	Andrew Lutomirski <luto@....edu>
To:	Al Viro <viro@...iv.linux.org.uk>
Cc:	"H. Peter Anvin" <hpa@...or.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	mingo@...hat.com, Richard Weinberger <richard@....at>,
	user-mode-linux-devel@...ts.sourceforge.net,
	linux-kernel@...r.kernel.org
Subject: Re: SYSCALL, ptrace and syscall restart breakages (Re: [RFC] weird
 crap with vdso on uml/i386)

On Sun, Aug 21, 2011 at 10:07 PM, Al Viro <viro@...iv.linux.org.uk> wrote:
> On Sun, Aug 21, 2011 at 10:01:40PM -0400, Andrew Lutomirski wrote:
>
>>  3. We're worried that pt_regs-using compat syscalls might want the
>> regs to appear to match the actual arguments (why?)
>
> run strace and you'll see why.
>

I'm talking about the implementations of stub32_rt_sigreturn,
sys32_rt_sigreturn, stub32_sigreturn, stub32_sigaltstack,
stub32_execve, stub32_fork, stub32_clone, stub32_vfork, and stub32_iopl.
I don't know what this has to do with strace or user ABI at all.

>>  4. ptrace expects the "registers" when SYSCALL happens to match the
>> int 0x80 convention.  (This is, IMO, sick.)
>
> That's what ptrace is *for*.  It's there to let debuggers play with
> the program being debugged, including taking a look at the syscall
> arguments and modifying them.  In a predictable way, please.
>

It may be necessary, but I still think it's sick.  Especially in the
case of inlined SYSCALL, where the registers reported to ptrace do not
match any register values that ever actually existed in CPU registers.
 Too late to fix it, though.

Which still leaves the question of how to fix it.  Restarting via an
int 0x80-based helper might be the only option that leaves everything
fully functional.

--Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/