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] [day] [month] [year] [list]
Date:	Sun, 24 Apr 2016 00:16:50 +0200
From:	Arnd Bergmann <arnd@...db.de>
To:	Andre Przywara <andre.przywara@....com>
Cc:	Will Deacon <will.deacon@....com>,
	Catalin Marinas <catalin.marinas@....com>,
	linux-arch@...r.kernel.org, linux-kernel@...r.kernel.org,
	linux-arm-kernel@...ts.infradead.org
Subject: Re: [PATCH] generic syscalls: wire up preadv2 and pwritev2 syscalls

On Monday 11 April 2016 10:17:46 Andre Przywara wrote:
> These new syscalls are implemented as generic code, so enable them for
> architectures like arm64 which use the generic syscall table.
> 
> Signed-off-by: Andre Przywara <andre.przywara@....com>
> 

I've forwarded it now as a pull request. Generally speaking, I'd much prefer
anyone who adds a syscall to update asm-generic/unistd.h as well
(as documented in Documentation/adding-syscalls.txt), there is no
need for me to put those patches into the asm-generic git tree first.

On a related topic, I've been thinking (for years) about coming up with a
way to have all future syscalls just get added to a single file in the
kernel to have them appended to the tables for all architectures. There
are two basic methods that seem appropriate here for avoiding the split
between unistd.h and syscalls.S:

a) The current asm-generic method of interleaving the __NR_* macro definitions
   and the entry in a .c file array, including the header multiple times
   to get all the tables
b) generating both files from an input like x86 does with
   arch/x86/entry/syscalls/ infrastructure

I think we need something similar to b) but with some extensions to allow
extending the architecture specific tables in a nice way, rather than
having to have one file per architecture.

	Arnd

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ