linux-kernel - Re: [PATCH 2/3] vsyscall_64: allow SECCOMP_RET

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 for Android: free password hash cracker in your pocket

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

Date:	Sat, 14 Jul 2012 09:21:50 -0700
From:	Andrew Lutomirski <luto@....edu>
To:	Will Drewry <wad@...omium.org>
Cc:	Kees Cook <keescook@...omium.org>, james.l.morris@...cle.com,
	rob@...dley.net, linux-doc@...r.kernel.org, cevans@...omium.org,
	hpa@...or.com, linux-kernel@...r.kernel.org,
	torvalds@...ux-foundation.org, eparis@...hat.com,
	fengxj325@...il.com
Subject: Re: [PATCH 2/3] vsyscall_64: allow SECCOMP_RET_TRACErs to skip

On Sat, Jul 14, 2012 at 9:15 AM, Andrew Lutomirski <luto@....edu> wrote:
> On Sat, Jul 14, 2012 at 8:57 AM, Will Drewry <wad@...omium.org> wrote:
>> On Sat, Jul 14, 2012 at 10:50 AM, Will Drewry <wad@...omium.org> wrote:
>>> On Sat, Jul 14, 2012 at 10:44 AM, Andrew Lutomirski <luto@....edu> wrote:
>>>> I think I'd prefer if changing to something other than whatever value is
>>>> used to cancel the syscall resulted in a crash rather than just being
>>>> ignored.
>>>
>>> I was trying to keep as much seccomp-ptrace behavior intact rather
>>> than making it terminal in this special case.  Is there a reason why
>>> it'd make more sense to crash?
>>
>> Unless you meant something the tracer could catch?  That may make
>> sense, but they could also use singlestep or whatever else to get
>> similar behavior.  But maybe I'm missing the bigger picture!
>
> I think it would be nice to not introduce any special behavior that
> things might rely on if we do this better in the future.  Similarly,
> for almost all purposes, a tracer could change gettimeofday to write,
> but there would be a silent behavior change if gettimeofday were
> entered via vsyscall.
>
> What's the standard way of skipping a syscall?  sigreturn?  (I don't
> know off the top of my head what sigreturn does.)  sys_ni_syscall?
> I'd be all for making those continue to work but making anything that
> can't be emulated correctly do something sufficiently unpleasant that
> people won't do it.  Is there a syscall that does nothing at all?

Here's my suggestion for now: any attempt by the seccomp filter to do
anything other than executing the syscall unchanged, skipping it
entirely, or killing results in a trap or sigsys with the syscall
number unchanged.

In the RET_TRACE case, the SIGSYS restarts at the mov nr,%rax
instruction.  The tracer can deal with it accordingly (via checking
the rip) -- if the tracer changes rax, it'll get changed right back by
the emulated mov nr,%rax.  If this results in an infinite loop, so be
it.

In the RET_TRAP case, do the same thing but via the special ptrace
event instead of SIGSYS.

This way, the special rip & ~0x0c00 == 0xffffffffff600000 handling
becomes part of the ABI, but it looks like the mov instruction
trapped, which it more or less did.  If we want RET_TRAP to be able to
skip the syscall, let it happen the normal way.

This stuff probably barely matters.  For example, ptrace currently
doesn't work right when vsyscalls are being emulated.  No one appears
to care.

--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/