linux-kernel - Re: Remove __end_entry_SYSENTER

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] [day] [month] [year] [list]

Message-ID: <20170712092514.GA24119@nazgul.tnic>
Date:   Wed, 12 Jul 2017 11:25:14 +0200
From:   Borislav Petkov <bp@...en8.de>
To:     Ingo Molnar <mingo@...nel.org>
Cc:     Andy Lutomirski <luto@...capital.net>, x86-ml <x86@...nel.org>,
        lkml <linux-kernel@...r.kernel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        "H. Peter Anvin" <hpa@...or.com>
Subject: Re: Remove __end_entry_SYSENTER_compat?

On Wed, Jul 12, 2017 at 10:48:03AM +0200, Ingo Molnar wrote:
> Hm, I'd argue that the old code is much clearer: we need both the start and the 
> end of a function and have the properly named symbols for that.
> 
> That entry_SYSCALL_compat() happens to start just where 
> __end_entry_SYSENTER_compat is an accident of placement.

Yeah, probably not worth the effort of actually making it less reliable
this way...

> Is it even true - doesn't ENTRY() imply an .align, in which case it might be that 
> __end_entry_SYSENTER_compat != entry_SYSCALL_compat?

Yes, ENTRY does .p2align:

.globl __end_entry_SYSENTER_compat; __end_entry_SYSENTER_compat:
.type entry_SYSENTER_compat, @function ; .size entry_SYSENTER_compat, .-entry_SYSENTER_compat
# 184 "arch/x86/entry/entry_64_compat.S"
.globl entry_SYSCALL_compat ; .p2align 4, 0x90 ; entry_SYSCALL_compat:
				^^^^^^
Pads to an alignment of 4 with NOPs.

> In fact that appears to be the case for my defconfig:
> 
>   ffffffff81942f90 T entry_SYSENTER_compat
>   ffffffff81942feb T __end_entry_SYSENTER_compat
>   ffffffff81942ff0 T entry_SYSCALL_compat
> 
> So unless there's some disadvantage beyond having one more symbol, I'd favor the 
> old approach.

Yeah, my only concern was getting rid of the global symbol but it
doesn't work in this case.

Thanks.

-- 
Regards/Gruss,
    Boris.

ECO tip #101: Trim your mails when you reply.
--