linux-kernel - Re: [PATCHv2 1/1] Documentation: describe how to add a system call

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, 30 Jul 2015 11:22:05 -0700
From:	Josh Triplett <josh@...htriplett.org>
To:	Ingo Molnar <mingo@...nel.org>
Cc:	David Drysdale <drysdale@...gle.com>, linux-api@...r.kernel.org,
	Michael Kerrisk <mtk.manpages@...il.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Arnd Bergmann <arnd@...db.de>,
	Shuah Khan <shuahkh@....samsung.com>,
	Jonathan Corbet <corbet@....net>,
	Eric B Munson <emunson@...mai.com>,
	Randy Dunlap <rdunlap@...radead.org>,
	Andrea Arcangeli <aarcange@...hat.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ingo Molnar <mingo@...hat.com>,
	"H. Peter Anvin" <hpa@...or.com>, Oleg Nesterov <oleg@...hat.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Andy Lutomirski <luto@...capital.net>,
	Al Viro <viro@...iv.linux.org.uk>,
	Rusty Russell <rusty@...tcorp.com.au>,
	Peter Zijlstra <peterz@...radead.org>,
	Vivek Goyal <vgoyal@...hat.com>,
	Alexei Starovoitov <ast@...mgrid.com>,
	David Herrmann <dh.herrmann@...il.com>,
	Theodore Ts'o <tytso@....edu>,
	Kees Cook <keescook@...omium.org>,
	Miklos Szeredi <mszeredi@...e.cz>,
	Milosz Tanski <milosz@...in.com>, Fam Zheng <famz@...hat.com>,
	Mathieu Desnoyers <mathieu.desnoyers@...icios.com>,
	linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>
Subject: Re: [PATCHv2 1/1] Documentation: describe how to add a system call

On Thu, Jul 30, 2015 at 10:38:31AM +0200, Ingo Molnar wrote:
> When the system call is extended in the future on the kernel side, with 'u64 
> param_4', then the structure expands from an old size of 24 to a new size of 32 
> bytes. The following scenarios might occur:
> 
>  - the common case: new user-space calls the new kernel code, ->size is 32 on both 
>    sides.
> 
>  - old binaries might call the kernel with params->size == 24, in which case the 
>    kernel sets the new fields to 0. The new feature should be written
>    accordingly, so that a value of 0 means the old behavior.
> 
>  - new binaries might run on old kernels, with params->size == 32. In this case 
>    the old kernel will check that all the new fields it does not know about are 
>    set to 0 - if they are nonzero (if the new feature is used) it returns with 
>    -ENOSYS or -EINVAL.

Nit: it seems easier, rather than having the kernel check this, to have
userspace only use the minimum version of the structure that contains
the features they use, and then have older kernels reject sizes bigger
than they understand.  If you don't need param_4, don't use the version
of the structure that has param_4.  That also means the kernel doesn't
need to copy and read those values.  Either approach works, though.

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