linux-kernel - Re: [RFC PATCH v2] x86/arch_prctl: Add ARCH_SET

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

Message-ID: <5208ad1e-cd9b-d57e-15b0-0ca935fccacd@intel.com>
Date:   Tue, 7 Apr 2020 09:27:31 -0700
From:   Dave Hansen <dave.hansen@...el.com>
To:     Keno Fischer <keno@...iacomputing.com>
Cc:     Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>,
        "maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)" <x86@...nel.org>,
        "H. Peter Anvin" <hpa@...or.com>, Borislav Petkov <bp@...en8.de>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        Andi Kleen <andi@...stfloor.org>,
        Kyle Huey <khuey@...ehuey.com>,
        Robert O'Callahan <robert@...llahan.org>
Subject: Re: [RFC PATCH v2] x86/arch_prctl: Add ARCH_SET_XCR0 to set XCR0
 per-thread

>> How does this work with things like xstateregs_[gs]et() where the format
>> of the kernel buffer and thus the kernel XCR0 is exposed as part of our
>> ABI?  With this patch, wouldn't a debugger app see a state buffer that
>> looks invalid?
> 
> Since those operate on the in-kernel buffer of these, which
> in this patch always uses the unmodified XCR0, ptracers
> should not observe a difference.

Those operate on *BOTH* kernel and userspace buffers.  They copy between
them.  That's kinda the point. :)

But I don't see any modifications to copy_xstate_to_user() or
user_regset_copyout() in your patch.

I suspect the patch thus far is only the tip of the iceberg.  I'd really
suggest doing some more thorough audits of all of the locations in the
kernel that touch the fpu buffer *or* that call XSAVE/XRSTOR.  I'm
pretty sure that audit hasn't been done or the ptrace example would have
been found already.

>> I'm also trying to think of what kinds of things CPU companies add to
>> their architectures that would break this stuff.  I can't recall ever
>> having a discussion with folks at Intel where we're designing a CPU
>> feature and we say, "Can't do that, it would break record/replay".
> 
> Heh, I'm having these discussions for you - ask me which Intel
> microarchitectures have interesting bugs here ;). The fact that rr works,
> is pretty much the only reason we buy Intel hardware these days, so
> there is at least a good reason for Intel folks to care. I think the evil
> plan is to make rr so good that everybody is using it, so you'll
> start having these conversations more :).

Having reverse execution is a laudable goal.  I've been using this:

	https://www.windriver.com/products/simics/

to do kernel (and occasional app) debugging the last few years, and its
reverse execution is invaluable for certain kinds of debugging.  But,
it's also not my daily go-to for debugging.

I'm just far from convinced that we your problem is worth solving,
especially in the place you're proposing to solve it.