linux-kernel - Re: [PATCH v2] x86/cpu: Fix migration safety with X86_BUG_NULL

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: <YW3M40tOILjI3DiD@zn.tnic>
Date:   Mon, 18 Oct 2021 21:37:07 +0200
From:   Borislav Petkov <bp@...en8.de>
To:     Sean Christopherson <seanjc@...gle.com>
Cc:     Jane Malalane <jane.malalane@...rix.com>,
        LKML <linux-kernel@...r.kernel.org>, x86@...nel.org,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>,
        "H. Peter Anvin" <hpa@...or.com>, Pu Wen <puwen@...on.cn>,
        Paolo Bonzini <pbonzini@...hat.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Andrew Cooper <andrew.cooper3@...rix.com>,
        Yazen Ghannam <Yazen.Ghannam@....com>,
        Brijesh Singh <brijesh.singh@....com>,
        Huang Rui <ray.huang@....com>,
        Andy Lutomirski <luto@...nel.org>,
        Kim Phillips <kim.phillips@....com>, stable@...r.kernel.org
Subject: Re: [PATCH v2] x86/cpu: Fix migration safety with X86_BUG_NULL_SEL

On Mon, Oct 18, 2021 at 07:29:41PM +0000, Sean Christopherson wrote:
> This isn't correct.  When running as a guest, the intended behavior is to fully
> trust the CPUID.0x80000021 bit.

Really? Because I'm coming from an SEV-SNP mail thread where we don't
trust the HV at all and we even hand in a CPUID page into the guest...

:-P

> If bit 6 is set, yay, the hypervisor has told the kernel that it
> will only ever run on hardware without the bug. If bit 6 is clear
> and HYPERVISOR is true, then the FMS crud can't be trusted because
> the kernel _may_ run on affected hardware in the future even if the
> current underlying hardware is not affected.

Ok, I see, then the CPUID check needs to go first, makes sense.

> I agree.  If the argument for this patch is that the kernel can be migrated to
> older hardware, then it stands to reason that the kernel could also be migrated
> to a different CPU vendor entirely.  E.g. start on Intel, migrate to Zen1, kaboom.

Migration across vendors? Really, that works?

I'll believe it only when I see it with my own eyes.

:-)

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette