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]
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".

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ