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 for Android: free password hash cracker in your pocket
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YgFoNeASrXizWMIa@zn.tnic>
Date:   Mon, 7 Feb 2022 19:43:01 +0100
From:   Borislav Petkov <bp@...en8.de>
To:     Michael Roth <michael.roth@....com>
Cc:     x86@...nel.org, linux-kernel@...r.kernel.org, kvm@...r.kernel.org,
        linux-efi@...r.kernel.org, platform-driver-x86@...r.kernel.org,
        linux-coco@...ts.linux.dev, linux-mm@...ck.org,
        Thomas Gleixner <tglx@...utronix.de>,
        Ingo Molnar <mingo@...hat.com>, Joerg Roedel <jroedel@...e.de>,
        Tom Lendacky <thomas.lendacky@....com>,
        "H. Peter Anvin" <hpa@...or.com>, Ard Biesheuvel <ardb@...nel.org>,
        Paolo Bonzini <pbonzini@...hat.com>,
        Sean Christopherson <seanjc@...gle.com>,
        Vitaly Kuznetsov <vkuznets@...hat.com>,
        Jim Mattson <jmattson@...gle.com>,
        Andy Lutomirski <luto@...nel.org>,
        Dave Hansen <dave.hansen@...ux.intel.com>,
        Sergio Lopez <slp@...hat.com>, Peter Gonda <pgonda@...gle.com>,
        Peter Zijlstra <peterz@...radead.org>,
        Srinivas Pandruvada <srinivas.pandruvada@...ux.intel.com>,
        David Rientjes <rientjes@...gle.com>,
        Dov Murik <dovmurik@...ux.ibm.com>,
        Tobin Feldman-Fitzthum <tobin@....com>, brijesh.singh@....com,
        Vlastimil Babka <vbabka@...e.cz>,
        "Kirill A . Shutemov" <kirill@...temov.name>,
        Andi Kleen <ak@...ux.intel.com>,
        "Dr . David Alan Gilbert" <dgilbert@...hat.com>,
        brijesh.ksingh@...il.com, tony.luck@...el.com, marcorr@...gle.com,
        sathyanarayanan.kuppuswamy@...ux.intel.com
Subject: Re: [PATCH v9 38/43] x86/sev: Use firmware-validated CPUID for
 SEV-SNP guests

On Mon, Feb 07, 2022 at 11:00:18AM -0600, Michael Roth wrote:
> this is more a statement that an out-of-spec hypervisor should not
> expect that their guests will continue working in future firmware
> versions, and what's being determined here is whether to break
> those out-of-spec hypervisor now, or later when/if we actually
> make use of the fields in the guest code,

I think you're missing a very important aspect here called reality.

Let's say that HV is a huge cloud vendor who means a lot of $ and a
huge use case for SEV tech. And let's say that same HV is doing those
incompatible things.

Now imagine you break it with the spec change. But they already have
a gazillion of deployments on real hw which they can't simply update
just like that. Hell, cloud vendors are even trying to dictate how CPU
vendors should do microcode updates on a live system, without rebooting,
and we're talking about some wimpy fields in some table.

Now imagine your business unit calls your engineering and says, you need
to fix this because a very persuasive chunk of money.

What you most likely will end up with is an ugly ugly workaround after a
lot of managers screaming at each other and you won't even think about
breaking that HV.

Now imagine you've designed it the right and unambiguous way from the
getgo. You wake up and realize, it was all just a bad dream...

> Ok, I'll follow up with the firmware team on this. But just to be clear,
> what they're suggesting is that the firmware could enforce the MBZ checks
> on the CPUID page, so out-of-spec hypervisors will fail immediately,
> rather than in some future version of the spec/cpuid page, and guests
> can continue ignoring them in the meantime.

Yes, exactly. Fail immediately.

Thx.

-- 
Regards/Gruss,
    Boris.

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

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ