linux-kernel - Re: [PATCH 1/1] x86/split_lock: check split lock feature on initialization

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: <f072e3e0-48b0-346e-b383-3e802069fc3a@kernkonzept.com>
Date:   Mon, 6 Apr 2020 10:23:16 +0200
From:   Benjamin Lamowski <benjamin.lamowski@...nkonzept.com>
To:     Sean Christopherson <sean.j.christopherson@...el.com>
Cc:     xiaoyao.li@...el.com, philipp.eppelt@...nkonzept.com, bp@...en8.de,
        fenghua.yu@...el.com, hpa@...or.com, linux-kernel@...r.kernel.org,
        luto@...nel.org, mingo@...hat.com, nivedita@...m.mit.edu,
        pbonzini@...hat.com, peterz@...radead.org, tglx@...utronix.de,
        tony.luck@...el.com, x86@...nel.org
Subject: Re: [PATCH 1/1] x86/split_lock: check split lock feature on
 initialization

[...]
> Calling split_lock_verify_msr() with X86_FEATURE_SPLIT_LOCK_DETECT=0 is
> intentional, the idea is to ensure SLD is disabled on all CPUs, e.g. in the
> unlikely scenario that BIOS enabled SLD.

I was aware of the intention, but I still don't understand under which
scenario this could be set by the BIOS although the earlier feature
detection has failed, i.e. shouldn't the feature have been detected in
all cases where SLD can actually be disabled? If so, checking for
availability first instead of catching a #GP(0) if it is not implemented
seems to be the cleaner solution.

> The first rdmsrl_safe() should short circuit split_lock_verify_msr() if
> the RDMSR faults, i.e. it might fault, but it shouldn't WARN.  Are you
> seeing issues or was this found via code inspection?

We stumbled across this issue because the x86 version of our VMM is not
yet ready for production and when accessing unimplemented MSRs would
simply return 0 and issue a warning. This is of course a deviation from
rdmsr as defined in the SDM and the pieces are ours to keep, it will be
changed to generate a #GP(0) once the last missing MSRs are emulated
properly.

-- 
Benjamin Lamowski - +49.351.41883235
Operating Systems Engineer - https://www.kernkonzept.com

Kernkonzept GmbH.  Sitz: Dresden.  Amtsgericht Dresden, HRB 31129.
Geschäftsführer: Dr.-Ing. Michael Hohmuth