linux-kernel - Re: [PATCH] KVM: SEV: Acquire vcpu mutex when updating VMSA

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

Message-ID: <YUEznQvx+bycn9Iq@google.com>
Date:   Tue, 14 Sep 2021 23:43:25 +0000
From:   Sean Christopherson <seanjc@...gle.com>
To:     Peter Gonda <pgonda@...gle.com>
Cc:     kvm list <kvm@...r.kernel.org>, Marc Orr <marcorr@...gle.com>,
        Paolo Bonzini <pbonzini@...hat.com>,
        Brijesh Singh <brijesh.singh@....com>, stable@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] KVM: SEV: Acquire vcpu mutex when updating VMSA

On Tue, Sep 14, 2021, Peter Gonda wrote:
> That looks reasonable to me. I didn't know if changes headed for LTS
> should be smaller so I avoided doing this refactor. From:
> https://www.kernel.org/doc/html/v4.11/process/stable-kernel-rules.html#stable-kernel-rules
> seems to say less than 100 lines is ideal.

Most the rules are more like guidelines ;-)  In seriousness, there's a balance to
be had between minimizing the diff and keeping everything maintainable.  E.g. if
the fix is kept small and then the upstream code is immediately refactored, any
future fixes to the refactored code will be harder to backport.  And the actual
fix would also be poorly tested in upstream since folks would be testing the
refactored version of the code.

> I guess this could also be a "theoretical race condition” anyways so maybe
> not for LTS anyways.

If there's doubt, write a test :-)  The "theoretical race condition" thing is to
discourage people from backporting fixes for ridiculously tiny windows that may
or may not be exploitable.  This is a giant gaping chasm that userspace can drive
a car through, e.g. literally "do KVM_RUN at the same time".