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]

Message-ID: <CAMe9rOoOn2JdsqtRDD_wVQASQoYebMfMhN2NirA2c_r1pao-1w@mail.gmail.com>
Date:   Fri, 16 Jun 2017 09:17:19 -0700
From:   "H.J. Lu" <hjl.tools@...il.com>
To:     Andy Lutomirski <luto@...nel.org>
Cc:     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 Fri, Jun 16, 2017 at 9:01 AM, Andy Lutomirski <luto@...nel.org> wrote:
> 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.

x86-64 was the only target which used FOREIGN_CALL macros
in ld.so,  FOREIGN_CALL macros were the cause of race condition
in ld.so:

https://sourceware.org/bugzilla/show_bug.cgi?id=11214

Not to save and restore the first 8 vector registers means that
FOREIGN_CALL macros have to be used.  We don't want to
do that on x86-64.


-- 
H.J.