linux-kernel - Re: [PATCH 23/27] [AARCH64] delouse input arguments in system functions

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CA+=Sn1=CF8nn59AGbrZAg5fzOM3tk1C_DGLTu4DUcVmYhY46BQ@mail.gmail.com>
Date:	Tue, 21 Jun 2016 09:37:47 -0700
From:	Andrew Pinski <pinskia@...il.com>
To:	Arnd Bergmann <arnd@...db.de>
Cc:	Joseph Myers <joseph@...esourcery.com>,
	Yury Norov <ynorov@...iumnetworks.com>,
	GNU C Library <libc-alpha@...rceware.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Catalin Marinas <catalin.marinas@....com>,
	Marcus Shawcroft <marcus.shawcroft@....com>, philb@....org,
	David Miller <davem@...emloft.net>,
	Szabolcs Nagy <szabolcs.nagy@....com>,
	Maxim Kuvyrkov <maxim.kuvyrkov@...aro.org>
Subject: Re: [PATCH 23/27] [AARCH64] delouse input arguments in system functions

On Tue, Jun 21, 2016 at 8:42 AM, Arnd Bergmann <arnd@...db.de> wrote:
> On Tuesday, June 21, 2016 10:36:53 AM CEST Joseph Myers wrote:
>> On Tue, 21 Jun 2016, Yury Norov wrote:
>>
>> > Signed-off-by: Yury Norov <ynorov@...iumnetworks.com>
>>
>> You're missing a patch description.  What does "delouse" even mean?  What
>> is the ABI peculiarity that means there are ABI-conforming arguments to
>> these functions that need such a manipulation?
>>
>
> This is the term the kernel uses for making sure that no system call
> from user space passes data in the upper bits of the argument registers,
> which could end up being used in an exploit when the calling conventions
> between functions assume that the upper bits contain zeroes.
>
> I don't think there is any point in doing this in glibc though: we
> can safely assume that any application calling into glibc follows
> the documented calling conventions (it would otherwise be a bug),
> but the kernel still has to zero those registers because malicious
> user space code would simply execute the system call instruction
> directly instead of calling into glibc...

The documented abi leaves the top 32bits undefined which is why the
zeroing is needed in these cases. Maybe a different name is needed
here.
It is the same reason why it is needed for vdso assembly code.  If
these functions were written in C, the compiler would be emitting the
zero extend for you.

Thanks,
Andrew




>
>         Arnd