linux-kernel - Re: [PATCH] Syscall arguments are unsigned long (full registers)

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:	Mon, 4 Jul 2016 14:47:10 +0000
From:	"Tautschnig, Michael" <tautschn@...zon.co.uk>
To:	Andi Kleen <ak@...ux.intel.com>
CC:	"x86@...nel.org" <x86@...nel.org>,
	"linux-api@...r.kernel.org" <linux-api@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	"Ingo Molnar" <mingo@...hat.com>, "H. Peter Anvin" <hpa@...or.com>,
	Jaswinder Singh <jaswinder@...radead.org>
Subject: Re: [PATCH] Syscall arguments are unsigned long (full registers)

Thanks a lot for the immediate feedback.

> On 4 Jul 2016, at 16:28, Andi Kleen <ak@...ux.intel.com> wrote:
> 
> On Mon, Jul 04, 2016 at 01:52:58PM +0000, Tautschnig, Michael wrote:
>> All syscall arguments are passed in as types of the same byte size as
>> unsigned long (width of full registers). Using a smaller type without a
>> cast may result in losing bits of information. In all other instances
>> apart from the ones fixed by the patch the code explicitly introduces
>> type casts (using, e.g., SYSCALL_DEFINE1).
>> 
>> While goto-cc reported these problems at build time, it is noteworthy
>> that the calling conventions specified in the System V AMD64 ABI do
>> ensure that parameters 1-6 are passed via registers, thus there is no
>> implied risk of misaligned stack access.
> 
> Does this actually fix anything?
> 

It will ensure the behaviour on 32 and 64-bit systems is consistent, i.e.,
no truncation occurs. This is to ensure that future uses of these syscalls
do not face surprises.

> It seems a big dangerous to me, potentially breaking some existing
> binaries that rely on these arguments being truncated.
> 

Would an analysis of all current call sites be of help? It seems impossible
to tell whether any modules outside the kernel tree using this functionality
rely on the (seemingly broken) behaviour.

Of course I could also provide a patch that introduces explicit type casts
to document the truncation.

Best,
Michael