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: <CALCETrXFh76p1BZzTMCefaRrL+61wzFgmz+1fz7s72E4H=i7Hg@mail.gmail.com>
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.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ