linux-kernel - Re: [PATCH] KVM: allow compiling out SMM support

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]

Message-ID: <56a125ab-f113-56f7-f8cb-de05127c92b7@redhat.com>
Date:   Thu, 29 Sep 2022 18:47:41 +0200
From:   Paolo Bonzini <pbonzini@...hat.com>
To:     "Maciej S. Szmigiero" <mail@...iej.szmigiero.name>,
        Sean Christopherson <seanjc@...gle.com>
Cc:     linux-kernel@...r.kernel.org, kvm@...r.kernel.org
Subject: Re: [PATCH] KVM: allow compiling out SMM support

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@...gle.com>
>> Signed-off-by: Paolo Bonzini <pbonzini@...hat.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