Re: [libseccomp-discuss] [PATCH v3 0/2] Add support for MIPS BE/LE and O32 ABI

[Ralf Baechle <ralf@linux-mips.org>]

On Thu, Apr 17, 2014 at 12:38:36PM -0700, Andy Lutomirski wrote:

> > I can't imagine any legitimate reason why an application of a particular
> > ABI would want to try a syscall of another ABI, for example why an N64
> > process would want to call the O32 open(2) syscall.
> 
> I've done it for testing.  And x32 does it because it's x32.

So from that perspective x32 isn't even a new ABI, just a castrated 64 bit
app using the 64 bit ABI.

> > For that reason I've long been contemplating to make syscalls of other ABIs
> > unavailable, even without seccomp.  Would that be useful for seccomp?
> 
> It's still possible to execve something else.

Would that other process then have a different syscall filter or is there only
one global one?

> > One exception though - I've seen a non-O32 application using syscall 4000,
> > the indirect syscall syscall.  Some needs to be the first to be taken out
> > and shot ;-)
> >
> 
> Aargh.  Let me guess: the indirect syscall syscall uses seven argument
> registers.  I guess ARM wasn't the only architecture to make the
> mistake of having one of those :(

Yes, seven arguments.  The sole reason why MIPS has an indirect syscall is that
I followed the the example of earlier MIPS UNIX variants.  And it has interesting
issues such as with 64 bit arguments on 32 bit machines.

  Ralf