From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S934086AbbEMLQy (ORCPT ); Wed, 13 May 2015 07:16:54 -0400 Received: from mail.skyhub.de ([78.46.96.112]:37571 "EHLO mail.skyhub.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S933753AbbEMLQv (ORCPT ); Wed, 13 May 2015 07:16:51 -0400 Date: Wed, 13 May 2015 13:16:47 +0200 From: Borislav Petkov To: Ingo Molnar Cc: Linus Torvalds , "H. Peter Anvin" , Thomas Gleixner , Andy Lutomirski , Denys Vlasenko , lkml Subject: Re: [RFC PATCH] Drop some asm from copy_user_64.S Message-ID: <20150513111647.GH1517@pd.tnic> References: <20150512205750.GJ3497@pd.tnic> <20150512215320.GK3497@pd.tnic> <20150513095248.GD1517@pd.tnic> <20150513103140.GA5113@gmail.com> <20150513104330.GG1517@pd.tnic> <20150513104630.GA7751@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20150513104630.GA7751@gmail.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, May 13, 2015 at 12:46:30PM +0200, Ingo Molnar wrote: > > * Borislav Petkov wrote: > > > On Wed, May 13, 2015 at 12:31:40PM +0200, Ingo Molnar wrote: > > > So why should an alternatives-CALL, inlined directly into call sites, > > > cost more kernel space? > > > > Not the alternatives CALL alone but inlining _copy_*_user with all > > the preparation glue around it would. Basically what we're doing > > currently. > > So I reacted to this comment of yours: > > > > > The disadvantage is that we have CALL after CALL [...] > > Is the CALL after CALL caused by us calling an alternatives patched > function? If yes then we probably should not do that: alternatives > switching should IMHO happen at the highest possible level. Right, so I was trying to analyze Linus' suggestion to uninline stuff and put it in uaccess_64.c. And that does save us some size and alternatives patch sites but produces the CALL ... CALL thing. So let me show you what we have now: ffffffff8102a774: 0f 1f 40 00 nopl 0x0(%rax) ffffffff8102a778: ba 58 00 00 00 mov $0x58,%edx ffffffff8102a77d: 4c 89 ff mov %r15,%rdi ffffffff8102a780: 49 83 c7 58 add $0x58,%r15 ffffffff8102a784: e8 b7 19 2f 00 callq ffffffff8131c140 <_copy_to_user> ... ffffffff8131c140 <_copy_to_user>: ffffffff8131c140: 65 48 8b 04 25 88 a9 mov %gs:0xa988,%rax ffffffff8131c147: 00 00 ffffffff8131c149: 48 2d 00 40 00 00 sub $0x4000,%rax ffffffff8131c14f: 48 89 f9 mov %rdi,%rcx ffffffff8131c152: 48 01 d1 add %rdx,%rcx ffffffff8131c155: 0f 82 bb c5 57 00 jb ffffffff81898716 ffffffff8131c15b: 48 3b 48 18 cmp 0x18(%rax),%rcx ffffffff8131c15f: 0f 87 b1 c5 57 00 ja ffffffff81898716 ffffffff8131c165: e9 36 00 00 00 jmpq ffffffff8131c1a0 ffffffff8131c16a: 66 0f 1f 44 00 00 nopw 0x0(%rax,%rax,1) so we prep args, call _copy_to_user, do checks and then JMP to the optimal alternative function. What I'd like to do is (hypothetically copy'pasted together): ffffffff8102a778: ba 58 00 00 00 mov $0x58,%edx ffffffff8102a77d: 4c 89 ff mov %r15,%rdi movq -16360(%r14), %rax # _208->addr_limit.seg, tmp347 subq $88, %rax #, D.37904 cmpq %rax, %r15 # D.37904, ubuf ja .L493 #, call copy_user_generic_unrolled # which saves us the first CALL to _copy_to_user and we do the alternatives CALL directly. This would mean that we will have to inline _copy_*_user() and switch it to use copy_user_generic() which already does the proper alternatives. For the price of some minor size increase and more alternatives patch sites. -- Regards/Gruss, Boris. ECO tip #101: Trim your mails when you reply. --