linux-kernel - Re: [GIT] writable

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:	Tue, 10 Aug 2010 20:50:12 +0200
From:	Arnd Bergmann <arnd@...db.de>
To:	Chris Metcalf <cmetcalf@...era.com>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Jiri Slaby <jslaby@...e.cz>,
	LKML <linux-kernel@...r.kernel.org>,
	Oleg Nesterov <oleg@...hat.com>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [GIT] writable_limits for 2.6.36

On Tuesday 10 August 2010, Chris Metcalf wrote:
> In any case, obviously the larger question is how many
> architecture-specific syscalls are appropriate, and where they should be
> located in the syscall number space.  To be clear, the model for new
> generic system calls is that they just continue on after the 16
> architecture-specific ones, and in fact __NR_wait4 is already an example
> of just this -- done that way to avoid making trouble for the "score"
> architecture, since it was deprecated and then later un-deprecated.  So
> new generic syscalls are not a problem.

Right. The writable_rlimits syscall should just go after wait4 at 262.

In retrospect, it would have been nicer to have the architecture specific
syscalls start at zero, but it's too late for that. Since we don't have
an architecture with more than a handful of arch specific calls, I think
16 will get us a very long way, while trying to leave "enough" space
between the generic and the arch specific calls would result either
in wasting space in the table or chosing a too small value.

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