linux-kernel - Re: [RFC PATCH] Drop some asm from copy_user

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]

Message-ID: <20150513103140.GA5113@gmail.com>
Date:	Wed, 13 May 2015 12:31:40 +0200
From:	Ingo Molnar <mingo@...nel.org>
To:	Borislav Petkov <bp@...en8.de>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	"H. Peter Anvin" <hpa@...or.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Andy Lutomirski <luto@...capital.net>,
	Denys Vlasenko <dvlasenk@...hat.com>,
	lkml <linux-kernel@...r.kernel.org>
Subject: Re: [RFC PATCH] Drop some asm from copy_user_64.S


* Borislav Petkov <bp@...en8.de> wrote:

> On Tue, May 12, 2015 at 11:53:20PM +0200, Borislav Petkov wrote:
> > > That said, I think you should uninline those things, and move them
> > > from a header file to a C file (arch/x86/lib/uaccess.c?).
> 
> It is starting to look better wrt size:
> 
> x86_64_defconfig:
> 
> 		   text    data     bss     dec     hex filename
> before: 	12375798        1812800 1085440 15274038         e91036 vmlinux
> after:		12269658        1812800 1085440 15167898         e7719a vmlinux
> 
> Now we CALL _copy_*_user which does CALL the optimal alternative 
> version. Advantage is that we're saving some space and alternatives 
> application for copy_user* is being done in less places, i.e. 
> arch/x86/lib/uaccess_64.c. If I move all copy_user_generic() callers 
> there, it would be the only compilation unit where the alternatives 
> will be done.
> 
> The disadvantage is that we have CALL after CALL and I wanted to 
> have a single CALL directly to the optimal copy_user function. 
> That'll cost us space, though, and more alternatives sites to patch 
> during boot...
> 
> Thoughts?

So why should an alternatives-CALL, inlined directly into call sites, 
cost more kernel space?

It should only be some more metadata, but that's outside any hot path 
and would be freed on init. The actual hot instructions should be 
exactly the same as a regular call, minus the double CALL indirection.

Thanks,

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