linux-kernel - Re: [PATCH v9 00/17] Enable FSGSBASE instructions

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] [thread-next>] [day] [month] [year] [list]

Message-Id: <BB51CFEA-A635-4664-821C-B57094AE95F0@amacapital.net>
Date:   Tue, 21 Apr 2020 09:49:11 -0700
From:   Andy Lutomirski <luto@...capital.net>
To:     Sasha Levin <sashal@...nel.org>
Cc:     Thomas Gleixner <tglx@...utronix.de>,
        Andi Kleen <ak@...ux.intel.com>,
        Andy Lutomirski <luto@...nel.org>,
        "Bae, Chang Seok" <chang.seok.bae@...el.com>,
        "Metzger, Markus T" <markus.t.metzger@...el.com>,
        "hpa@...or.com" <hpa@...or.com>, "bp@...en8.de" <bp@...en8.de>,
        "Hansen, Dave" <dave.hansen@...el.com>,
        "Luck, Tony" <tony.luck@...el.com>,
        Pedro Alves <palves@...hat.com>,
        Simon Marchi <simark@...ark.ca>,
        "Shankar, Ravi V" <ravi.v.shankar@...el.com>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v9 00/17] Enable FSGSBASE instructions



> On Apr 21, 2020, at 9:06 AM, Sasha Levin <sashal@...nel.org> wrote:
> 
> On Mon, Apr 20, 2020 at 07:14:46PM +0200, Thomas Gleixner wrote:
>> Andi Kleen <ak@...ux.intel.com> writes:
>>>> the *gdb developers* don't care.  But gdb isn't exactly a good example
>>>> of a piece of software that tries to work correctly when dealing with
>>>> unusual software.  Maybe other things like rr will care more.  It
>>> 
>>> rr is used to replay modern software, and modern software
>>> doesn't care about selectors, thus rr doesn't care either.
>>> 
>>> Please stop the FUD.
>> 
>> There is absolutely no FUD. Being careful about not breaking existing
>> user space is a legitimate request.
>> 
>> It's up to those who change the ABI to prove that it does not matter and
>> not up to the maintainers to figure it out.
> 
> I think that this is a difficult ask; "prove that god doesn't exist".
> 
> Andi's point is that there is no known user it breaks, and the Intel
> folks did some digging into potential users who might be affected by
> this, including 'rr' brought up by Andy, and concluded that there won't
> be breakage as a result of this patchset:
> 
>    https://mail.mozilla.org/pipermail/rr-dev/2018-March/000616.html
> 
> Sure, if you poke at it you could see a behavior change, but is there
> an actual user that will be affected by it? I suspect not.
> 
>> This sits in limbo for months now just because Intel doesn't get it's
>> homework done.
>> 
>> Stop making false accusations and provide factual information instead.
> 
> If there's no known user that will be broken here, can we consider
> merging this to be disabled by default and let distros try it out? This
> will let us find these users while providing an easy way to work around
> the problem.

No.  Once it’s merged, people will write user code using the ABI, and that means we need to get the ABI right.

The very early versions had severely problematic ABIs. The new ones are probably okay except for, maybe, ptrace.  If we had merged the old ones, then we might have gotten stuck with the old, problematic ABI.

> 
> -- 
> Thanks,
> Sasha