linux-kernel - Re: [PATCH] Handle clock_gettime(CLOCK

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: <CALCETrX2tPRGfyzLgnT_usWGZ-3PA_dzx_i85t7M-0S9cKYZrg@mail.gmail.com>
Date:   Tue, 14 Aug 2018 14:20:45 -0700
From:   Andy Lutomirski <luto@...nel.org>
To:     David Woodhouse <dwmw2@...radead.org>
Cc:     Andy Lutomirski <luto@...nel.org>,
        Matt Rickard <matt@...trans.com.au>,
        LKML <linux-kernel@...r.kernel.org>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        X86 ML <x86@...nel.org>, Kees Cook <keescook@...omium.org>
Subject: Re: [PATCH] Handle clock_gettime(CLOCK_TAI) in VDSO

On Tue, Aug 14, 2018 at 9:30 AM, David Woodhouse <dwmw2@...radead.org> wrote:
> On Tue, 2018-08-14 at 07:20 -0700, Andy Lutomirski wrote:
>> > +       /* Doubled switch statement to work around kernel Makefile error */
>> > +       /* See: https://www.mail-archive.com/gcc-bugs@gcc.gnu.org/msg567499.html */
>>
>> NAK.
>>
>> The issue here (after reading that thread) is that, with our current
>> compile options, gcc generates a jump table once the switch statement
>> hits five entries.  And it uses retpolines for it, and somehow it
>> generates the relocations in such a way that the vDSO build fails.
>> We
>> need to address this so that the vDSO build is reliable, but there's
>> an important question here:
>>
>> Should the vDSO be built with retpolines, or should it be built with
>> indirect branches?  Or should we go out of our way to make sure that
>> the vDSO contains neither retpolines nor indirect branches?
>>
>> We could accomplish the latter (sort of) by manually converting the
>> switch into the appropriate if statements, but that's rather ugly.
>>
>> (Hmm.  We should add exports to directly read each clock source.
>> They'll be noticeably faster, especially when
>> cache-and-predictor-code.)
>
> Surely it's kind of expected that the vDSO can't find an externally
> provided __x86_indirect_thunk_rax symbol, since we only provide one as
> part of the kernel image.
>
> Building the vDSO with -mindirect-branch=thunk(|-inline) should fix
> that, if we want retpolines in the vDSO.

I think that, if we want retpolines in the kernel, we probably want
them in the vDSO as well.  Although there's an argument to be made
that IBPB gives enough protection, at least against most targets.

>
> There's also -fno-jump-tables.

I'll probably do this, conditioned on CONFIG_RETPOLINE.  Or we should
do it kernel-wide.

hjl filed https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86952 based on
my comment in the other bug report.  gcc seems to be generating jump
tables when it shouldn't be doing so.