linux-kernel - Re: [PATCH 01/17] x86: spec_ctrl: fix SPEC

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]

Date:   Mon, 23 Sep 2019 15:27:34 -0700
From:   Sean Christopherson <sean.j.christopherson@...el.com>
To:     Andrea Arcangeli <aarcange@...hat.com>
Cc:     Paolo Bonzini <pbonzini@...hat.com>,
        Vitaly Kuznetsov <vkuznets@...hat.com>,
        "Dr. David Alan Gilbert" <dgilbert@...hat.com>,
        Marcelo Tosatti <mtosatti@...hat.com>,
        Peter Xu <peterx@...hat.com>, kvm@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH 01/17] x86: spec_ctrl: fix SPEC_CTRL initialization after
 kexec

On Mon, Sep 23, 2019 at 01:34:21PM -0400, Andrea Arcangeli wrote:
> Per subject of the patch, 14 is also an optimization that while not a
> strict requirement, is somewhat related to the monolithic conversion
> because in fact it may naturally disappear if I rename the vmx/svm
> functions directly.
> 
> 15 16 17 don't have the monolithic tag in the subject of the patch and
> they're obviously unrelated to the monolithic conversion, but when I
> did the first research on this idea of dropping kvm.ko a couple of
> months ago, things didn't really work well until I got rid of those
> few last retpolines too. If felt as if the large retpoline regression
> wasn't linear with the number of retpolines executed for each vmexit,
> and that it was more linear with the percentage of vmexits that hit on
> any number of retpolines. So while they're not part of the monolithic
> conversion I assumed they're required to run any meaningful benchmark.
> 
> I can drop 15 16 17 from further submits of course, after clarifying
> benchmark should be only run on the v1 full set I posted earlier, or
> they wouldn't be meaningful.

I like the patches, I'd just prefer that they be sent in a separate
series so they can churn independently.