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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <1534264248.6862.23.camel@infradead.org>
Date:   Tue, 14 Aug 2018 18:30:48 +0200
From:   David Woodhouse <dwmw2@...radead.org>
To:     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, 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.

There's also -fno-jump-tables.

Download attachment "smime.p7s" of type "application/x-pkcs7-signature" (5213 bytes)