linux-kernel - Re: Compat 32-bit syscall entry from 64-bit task!?

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]

Date:	Thu, 26 Jan 2012 06:57:18 +0100
From:	"Indan Zupancic" <indan@....nu>
To:	"Denys Vlasenko" <vda.linux@...glemail.com>
Cc:	"Oleg Nesterov" <oleg@...hat.com>,
	"Linus Torvalds" <torvalds@...ux-foundation.org>,
	"Andi Kleen" <andi@...stfloor.org>,
	"Jamie Lokier" <jamie@...reable.org>,
	"Andrew Lutomirski" <luto@....edu>,
	"Will Drewry" <wad@...omium.org>, linux-kernel@...r.kernel.org,
	keescook@...omium.org, john.johansen@...onical.com,
	serge.hallyn@...onical.com, coreyb@...ux.vnet.ibm.com,
	pmoore@...hat.com, eparis@...hat.com, djm@...drot.org,
	segoon@...nwall.com, rostedt@...dmis.org, jmorris@...ei.org,
	scarybeasts@...il.com, avi@...hat.com, penberg@...helsinki.fi,
	viro@...iv.linux.org.uk, mingo@...e.hu, akpm@...ux-foundation.org,
	khilman@...com, borislav.petkov@....com, amwang@...hat.com,
	ak@...ux.intel.com, eric.dumazet@...il.com, gregkh@...e.de,
	dhowells@...hat.com, daniel.lezcano@...e.fr,
	linux-fsdevel@...r.kernel.org,
	linux-security-module@...r.kernel.org, olofj@...omium.org,
	mhalcrow@...gle.com, dlaor@...hat.com,
	"Roland McGrath" <mcgrathr@...omium.org>
Subject: Re: Compat 32-bit syscall entry from 64-bit task!?

On Thu, January 26, 2012 02:09, Denys Vlasenko wrote:
> Dealt with in Linus tree already: set PTRACE_O_TRACEEXEC option,
> and use PTRACE_GETEVENTMSG in PTRACE_EVENT_EXEC stop to get
> the old TID.

Thanks, getting the old TID is useful, that was the missing bit to
handle execve statelessly.

>
>
>> > To future-proof this scheme we may reserve a few more event values
>> > PTRACE_EVENT_SYSCALL_ENTRY2, PTRACE_EVENT_SYSCALL_ENTRY3, etc,
>> > if we'll ever have arches with more than one non-native syscall
>> > entry. I'm no expert, but looking at strace code, ARM may already have
>> > more than one additional convention how to pass syscall args.
>>
>> Please, no! This way lays madness, just one PTRACE_EVENT_SYSCALL_ENTRY,
>> no PTRACE_EVENT_SYSCALL_ENTRY1 or PTRACE_EVENT_SYSCALL_ENTRY2, that
>> would be horrible. Keep arch specific stuff in arch specific areas,
>> please don't spread it around.
>
> The situation when an architecture has 32- and 64-bit varieties,
> and sometimes different ABIs (parameter passing comventions),
> is rather typical, it's not a quirk of just one unfortunate
> architecture.

The question is how many of those have a different ABI and can not
be reliably detected at system call entry time. If the ABI can't
be changed at runtime then there's no problem either.

x86_64's case is very peculiar because it can execute a 32-bit compat
syscall while the process itself is in 64-bit mode.

> Please look at strace source, get_scno() function, where
> it reads syscall no and parameters. Let's see....
> - POWERPC: has 32-bit and 64-bit mode
> - X86_64: has 32-bit and 64-bit mode
> - IA64: has i386-compat mode
> - ARM: has more than one ABI
> - SPARC: has 32-bit and 64-bit mode

Fow most of them you can reliably check the mode by looking at registers.

x86_64 and apparently ARM are problematic. Others may too in similar subtle
ways as x86_64, but I can't tell that from strace's code.

ARM looks ok when old cruft isn't enabled (much more likely than compat
mode being disabled in x86_64).

Can SPARC change mode on the fly without detection? Otherwise it looks
like it may be slightly problematic too, though it seems that at least
the ABI is pretty much the same between 32 and 64 bit mode. Same for
PA-RISC. So all in all not sure if they have a problem or not.

To be a problem the only way to figure our what mode the system call
will be is by looking at the trapping/syscall instruction itself. If
that isn't needed, or if there isn't much difference between the modes
anyway, then there's no problem.

>
> Do you want to re-invent a different arch-specific way to report
> syscall type for each of these arches?

Thing is, it is not just 32 versus 64 bit mode. So one way or the other,
you do end up with an arch-specific way of saying what syscall type it is.

It doesn't matter much where that info is stuffed, it will always be arch
specific, because depending on that value people have to do different
arch specific things.

It's fine to somehow give that info together with PTRACE_EVENT_SYSCALL_ENTRY,
but I don't think it's a good idea to have different syscall entry events
depending on what type they are. I suppose the only reason to do that would
be because we're running out of bits elsewhere.

>
>> What was wrong with using eflags again? Is it too simple or something?
>
> It's x86-specific, and abuses a bit in a real register.

If the problem is limited to only a couple of archs, and we can stuff this
info in the register set for all of them, then I'm all for it.

So far it's just x86_64 and ARM with OABI enabled, with the rest either
fine or unclear.

Greetings,

Indan

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