linux-kernel - Re: 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:	Wed, 5 Mar 2014 16:13:25 -0800
From:	Andy Lutomirski <luto@...capital.net>
To:	"H. Peter Anvin" <hpa@...or.com>
Cc:	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	linux-arch <linux-arch@...r.kernel.org>,
	libseccomp-discuss@...ts.sourceforge.net
Subject: Re: Making a universal list of syscalls?

On Tue, Mar 4, 2014 at 11:27 AM, H. Peter Anvin <hpa@...or.com> wrote:
> On 02/27/2014 12:40 PM, 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.
>>
>>  2. There's no clean way to map between syscall argument registers and
>> logical syscall arguments.  Each architecture knows how to do it, as
>> do strace and glibc, but I suspect that *everyone* else gets it wrong.
>>  Especially on ARM.
>>
>>  3. Determining which architectures have which syscalls is a mess.
>> Recent kernel builds love to warn me that finit_module is missing on
>> x86_64.  This is simply not true.  I have no idea why.
>>
>>  4. Actually issuing a nontrivial syscall is annoying.  syscall(2) can
>> do it for the native architecture (only).
>>
>>  5. Decoding ucontext from SIGSYS is a mess.  I have prototype code
>> for libseccomp that can do it, but it gets the arguments wrong due to
>> ABI issues.  See (2).
>>
>> 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.
>>
>
> Hi Andy,
>
> I have brought that up a lot of times, originally dating back from my
> work on klibc.  I have tried to keep the klibc syscall list in a sane
> format with architecture annotations, but it doesn't contain all the
> syscalls in the system.
>
> Extending that work and making it encompass everything the kernel
> exports would be highly useful, but it would take a lot of work.

I think that SYSCALLS.def won't work as is -- SYSCALLS.def
references unistd, which ought to be autogenerated from the syscalls
list.  But a somewhat less magical variant should work.

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