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

Date:   Tue, 7 Apr 2020 14:30:13 -0400
From:   Keno Fischer <keno@...iacomputing.com>
To:     Andy Lutomirski <luto@...capital.net>
Cc:     Dave Hansen <dave.hansen@...el.com>,
        Peter Zijlstra <peterz@...radead.org>,
        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

> TSX!

Yes, it's problematic, but luckily turns out to
be ok in practice if masked off in cpuid.

> I think rr should give the raw KVM API at least a try.  It should be possible to fire up a vCPU in CPL3 in the correct state.  No guest kernel required.  I don’t know if there will be issues with the perf API, though.

Yes, I've looked into it, but stopped short of doing a
complete implementation. Using KVM to solve it
for replay would probably be feasible with a moderate
amount of engineering work, since rr does very few
syscalls during replay. I'm a bit afraid of the
performance implications, but I don't have numbers on this.

Record and diversions are a lot harder though, because
in this mode the tracee is a live process and able to do
syscalls (and needs to receive signals and all that good
stuff associated with being a real process). For diversions,
performance isn't super important, so we could probably
emulate this, but for record, performance is quite critical.
I assume it would be possible to add a feature to KVM
where it forwards syscalls made in guest CPL3 to the real
kernel without round-trip through userspace, but I'm just
seeing myself back here asking
for a weird KVM feature that nobody but me wants ;)
(well almost nobody, as I mentioned, there's an
academic project that tried this with a custom kernel
plugin - http://dune.scs.stanford.edu/).

Admittedly, the use case for this feature during record is
less pressing, since in our (operational) case
the replay machines tend to be much newer than
the record machines, but I wouldn't be surprised if I got
bit by this as soon as the next user xstate component gets
added and users start sending me those kinds of traces,
even if we mask off the feature in CPUID (which rr already
supports for record for similar reasons).