linux-kernel - Re: [PATCH 03/13] kvm: monolithic: fixup x86-32 build

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]

Date:   Sat, 9 Nov 2019 00:10:03 +0100
From:   Paolo Bonzini <pbonzini@...hat.com>
To:     Andrea Arcangeli <aarcange@...hat.com>
Cc:     Jessica Yu <jeyu@...nel.org>, kvm@...r.kernel.org,
        linux-kernel@...r.kernel.org,
        Vitaly Kuznetsov <vkuznets@...hat.com>,
        Sean Christopherson <sean.j.christopherson@...el.com>,
        Masahiro Yamada <yamada.masahiro@...ionext.com>,
        Matthias Maennich <maennich@...gle.com>
Subject: Re: [PATCH 03/13] kvm: monolithic: fixup x86-32 build

On 08/11/19 22:26, Andrea Arcangeli wrote:
> On Fri, Nov 08, 2019 at 10:02:52PM +0100, Paolo Bonzini wrote:
>> kvm_intel.ko or kvm_amd.ko, I'm not sure why that would be worse for TLB
>> or RAM usage.  The hard part is recording the location of the call sites
> 
> Let's ignore the different code complexity of supporting self
> modifying code: kvm.ko and kvm-*.ko will be located in different
> pages, hence it'll waste 1 iTLB for every vmexit and 2k of RAM in
> average.

This is unlikely to make a difference, since kvm.o and kvm-intel.o are
overall about 700 KiB in size.  You do lose some inlining opportunities
 with LTO, but without LTO the L1 cache benefits are debatable too.  The
real loss is in the complexity, I agree with you about that.

> Now about the code complexity, it is even higher than pvops:
> 
>    KVM				pvops
>    =========                    =============
> 1) Changes daily		Never change
> 
> 2) Patched at runtime		Patched only at boot time early on
>    during module load
>    and multiple times
>    at every load of kvm-*.ko
> 
> 3) The patching points to	All patch destinations are linked into
>    code in kernel modules       the kernel
> 
> Why exactly should we go through such a complication when it runs
> slower in the end and it's much more complex to implement and maintain
> and in fact even more complex than pvops already is?

For completeness, one advantage of patching would be to keep support for
built-in Intel+AMD.  The modpost patch should be pretty small, and since
Jessica seemed quite open to it let's do that.

Thanks,

Paolo

> Furthermore by linking the thing statically we'll also enable LTO and
> other gcc features which would never be possible with those indirect
> calls.
> 
> Thanks,
> Andrea
>