linux-kernel - Re: [PATCH 14/15] x86/fsgsbase/64: Support legacy behavior when FS/GS updated by ptracer

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:   Thu, 22 Mar 2018 01:39:58 +0000
From:   Andy Lutomirski <luto@...nel.org>
To:     "Metzger, Markus T" <markus.t.metzger@...el.com>
Cc:     Andy Lutomirski <luto@...nel.org>,
        "Bae, Chang Seok" <chang.seok.bae@...el.com>,
        X86 ML <x86@...nel.org>, Andi Kleen <ak@...ux.intel.com>,
        "H. Peter Anvin" <hpa@...or.com>,
        "Luck, Tony" <tony.luck@...el.com>,
        "Shankar, Ravi V" <ravi.v.shankar@...el.com>,
        LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 14/15] x86/fsgsbase/64: Support legacy behavior when FS/GS
 updated by ptracer

On Wed, Mar 21, 2018 at 7:01 AM, Metzger, Markus T
<markus.t.metzger@...el.com> wrote:
>> -----Original Message-----
>> From: Andy Lutomirski [mailto:luto@...nel.org]
>> Sent: 21 March 2018 01:47
>
> Hello Andy,
>
>> I retract this particular comment.  But I still think that all this complexity needs to
>> be more clearly justified.  My objection to the old approach wasn't that I thought
>> it was obviously wrong -- I thought that someone needed to survey existing
>> ptrace() users and see if anyone needed the fancier code that you're adding.  Did
>> you find something that needs this fancy code?
>
> There are 3 cases:
> - only FS changed, e.g. "p $fs = ..."

If a person literally types that, I have no problem if they get
different behavior on different systems.  If it's some existing
program that needs to keep working, then we may be out of luck, since
gdb seems to use SETREGS.

> - only FS_BASE changed, e.g. "p $fs_base = ..."

That's fine no matter what, I think.

> - both change, e.g. "p foo()" when restoring the original register state on return
>   from the inferior call

This is the interesting case.  If everything that matters uses
SETREGS, then I think we're in good shape, and we should probably just
make writing to FS using ptrace on FSGSBASE systems *not* change
FSBASE, since that way is much simpler.