linux-kernel - Re: xgetbv nondeterminism

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]

Date:   Fri, 16 Jun 2017 09:01:57 -0700
From:   Andy Lutomirski <luto@...nel.org>
To:     "H.J. Lu" <hjl.tools@...il.com>
Cc:     Andy Lutomirski <luto@...nel.org>,
        Dave Hansen <dave.hansen@...el.com>,
        "Robert O'Callahan" <robert@...llahan.org>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        X86 ML <x86@...nel.org>
Subject: Re: xgetbv nondeterminism

On Thu, Jun 15, 2017 at 9:34 PM, H.J. Lu <hjl.tools@...il.com> wrote:
> On Thu, Jun 15, 2017 at 8:05 PM, Andy Lutomirski <luto@...nel.org> wrote:
>> On Thu, Jun 15, 2017 at 7:17 PM, H.J. Lu <hjl.tools@...il.com> wrote:
>>> On Thu, Jun 15, 2017 at 4:28 PM, Andy Lutomirski <luto@...nel.org> wrote:
>>>> On Thu, Jun 15, 2017 at 4:11 PM, H.J. Lu <hjl.tools@...il.com> wrote:
>>>>> It is used for lazy binding the first time when an external function is called.
>>>>>
>>>>
>>>> Maybe I'm just being dense, but why?  What does ld.so need to do to
>>>> resolve a symbol and update the GOT that requires using extended
>>>> state?
>>>
>>> Since the first 8 vector registers are used to pass function parameters
>>> and ld.so uses vector registers, _dl_runtime_resolve needs to preserve
>>> the first 8 vector registers when transferring control to ld.so.
>>>
>>
>> Wouldn't it be faster and more future-proof to recompile the relevant
>> parts of ld.so to avoid using extended state?
>>
>
> Are you suggesting not to use vector in ld.so?

Yes, exactly.

>  We used to do that
> several years ago, which leads to some subtle bugs, like
>
> https://sourceware.org/bugzilla/show_bug.cgi?id=15128

I don't think x86_64 has the issue that ARM has there.  The Linux
kernel, for example, has always been compiled to not use vector or
floating point registers on x86 (32 and 64), and it works fine.  Linux
doesn't save extended regs on kernel entry and it doesn't restore them
on exit.

I would suggest that ld.so be compiled without use of vector
registers, that the normal lazy binding path not try to save any extra
regs, and that ifuncs be called through a thunk that saves whatever
registers need saving, possibly just using XSAVEOPT.  After all, ifunc
is used for only a tiny fraction of symbols.