Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Message-ID: <56a125ab-f113-56f7-f8cb-de05127c92b7@redhat.com>
Date:   Thu, 29 Sep 2022 18:47:41 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101
 Thunderbird/102.2.1
Subject: Re: [PATCH] KVM: allow compiling out SMM support
Content-Language: en-US
To:     "Maciej S. Szmigiero" <mail@maciej.szmigiero.name>,
        Sean Christopherson <seanjc@google.com>
Cc:     linux-kernel@vger.kernel.org, kvm@vger.kernel.org
References: <20220927152241.194900-1-pbonzini@redhat.com>
 <bd4d7463-a960-3c49-9c56-a8bd5c1ea7f0@maciej.szmigiero.name>
From:   Paolo Bonzini <pbonzini@redhat.com>
In-Reply-To: <bd4d7463-a960-3c49-9c56-a8bd5c1ea7f0@maciej.szmigiero.name>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Precedence: bulk

On 9/29/22 17:49, Maciej S. Szmigiero wrote:
> On 27.09.2022 17:22, Paolo Bonzini wrote:
>> Some users of KVM implement the UEFI variable store through a 
>> paravirtual device
>> that does not require the "SMM lockbox" component of edk2; allow them to
>> compile out system management mode, which is not a full implementation
>> especially in how it interacts with nested virtualization.
>>
>> Suggested-by: Sean Christopherson <seanjc@google.com>
>> Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
>> ---
>>     The patch isn't pretty.  I could skip all the changes to add WARNs
>>     to called functions, but the point of adding the config symbol is
>>     to make sure that those functions, and all the baggage they bring,
>>     are dead.
> 
> Out of curiosity: why the SMM support is so special that it's worth to
> add a dedicated Kconfig entry for it?

Yeah, that's a good point.  In general the module parameters either:

1) change between two behaviors (e.g. tdp_mmu) or

2) can be toggled at runtime or

3) disable _hardware_ features

The two Kconfig entries for SMM and XEN are more for things that you 
want to remove to reduce attack surface than for testing.

> Looking at the patch it doesn't seem to disable that much of code (like,
> significantly slim down the binary) and where it does disable something
> it mostly relies on compiler dead code removal rather than explicit
> #ifdefs (which would guarantee that the disabled code did not end in
> the binary).

Yeah, v2 will actually remove much more.

Paolo