linux-kernel - Re: [libseccomp-discuss] Making a universal list of syscalls?

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, 27 Feb 2014 15:53:40 -0500
From:	Eric Paris <eparis@...hat.com>
To:	Andy Lutomirski <luto@...capital.net>
Cc:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	linux-arch <linux-arch@...r.kernel.org>,
	libseccomp-discuss@...ts.sourceforge.net,
	Steve Grubb <sgrubb@...hat.com>
Subject: Re: [libseccomp-discuss] Making a universal list of syscalls?

On Thu, 2014-02-27 at 12:40 -0800, Andy Lutomirski wrote:
> Currently, dealing with Linux syscalls in an architecture-independent
> way is a mess.  Here are some issues:
> 
>  1. There's no clean way to map between syscall names and numbers on
> different architectures.  The kernel contains a number of tables (that
> work differently for different architectures).  strace has some arcane
> mechanism.  libseccomp has another.

userspace audit a 3rd.

> I'd like to see a master list in the kernel that lists, for every
> syscall, the name, the number for each architecture that implements it
> (using the AUDIT_ARCH semantics, probably), and the signature.  The
> build process could parse this table to replace the current per-arch
> mess.

I know for audit it would be huge if userspace didn't try to organically
grow this knowledge on their own!  So +1 from me!

> 
> Issues here: some syscalls have different signatures on different
> architectures.  Maybe we could require that a canonical syscall name
> would have the same signature everywhere, but architectures could
> specify alternate names.  So, for things like clone (?), there could
> actually be a few syscalls that all have alternate names of "clone".
> 
> More importantly, we could add a library in tools that exposes this
> information to userspace.  Useful operations:
> 
>  - For a given (arch, nr), indicate, for each logical argument, which
> physical argument slot is used or, if the argument is split into a
> high and low part, which pair of slots is used.
> 
>  - For a given (nr, logical args), issue the syscall for the
> architecture that build the library.
> 
>  - For a given (arch, nr, logical args), issue the syscall if
> possible.  An x86_32 build could issue x86_64 syscalls with some
> effort, and an x86_64 build could easily issue 32-bit syscalls.
> 
>  - For a given arch, map between name and nr, and give access to the signature.
> 
> If this happened, presumably all architectures that supported it would
> have to have valid AUDIT_ARCH support.  That means that someone would
> have to fix ARM OABI (sigh).
> 
> Thoughts?

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