Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 4129AC636CC for ; Tue, 7 Feb 2023 06:03:18 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229640AbjBGGDQ (ORCPT ); Tue, 7 Feb 2023 01:03:16 -0500 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:60878 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229535AbjBGGDN (ORCPT ); Tue, 7 Feb 2023 01:03:13 -0500 Received: from sin.source.kernel.org (sin.source.kernel.org [IPv6:2604:1380:40e1:4800::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 5FB07298FB for ; Mon, 6 Feb 2023 22:03:11 -0800 (PST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sin.source.kernel.org (Postfix) with ESMTPS id 835F2CE1C9C for ; Tue, 7 Feb 2023 06:03:09 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 17BA1C433EF; Tue, 7 Feb 2023 06:03:07 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=linuxfoundation.org; s=korg; t=1675749787; bh=n0NSw6MLeyqaJNIB2F0bB4A/V51VTRATE/PybeUZGeI=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=lq+fuoKJWnx5lwARuKY8fU+ugkgKvxmnmh/wFX7tUoTQM1p8cHZYpQzcu6oES9p5j UT4YZIbx9zIBGdQlil9TetkVt3C1vzsVtli86X15g/HRoGuso2qjnCZqbI4Lrq4hfV OAkrv5Bz5aHu3eMR/Ulh4c61HzIVjj/qp7DQmRhg= Date: Tue, 7 Feb 2023 07:03:04 +0100 From: Greg Kroah-Hartman To: Carlos Bilbao Cc: "Reshetova, Elena" , "Shishkin, Alexander" , "Shutemov, Kirill" , "Kuppuswamy, Sathyanarayanan" , "Kleen, Andi" , "Hansen, Dave" , Thomas Gleixner , Peter Zijlstra , "Wunner, Lukas" , Mika Westerberg , "Michael S. Tsirkin" , Jason Wang , "Poimboe, Josh" , "aarcange@redhat.com" , Cfir Cohen , Marc Orr , "jbachmann@google.com" , "pgonda@google.com" , "keescook@chromium.org" , James Morris , Michael Kelley , "Lange, Jon" , "linux-coco@lists.linux.dev" , Linux Kernel Mailing List Subject: Re: Linux guest kernel threat model for Confidential Computing Message-ID: References: <658272b5-9547-a69f-b6c9-a7ff2dd2d468@amd.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <658272b5-9547-a69f-b6c9-a7ff2dd2d468@amd.com> Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Feb 06, 2023 at 06:27:48PM -0600, Carlos Bilbao wrote: > On 1/25/23 6:28 AM, Reshetova, Elena wrote: > > 2) One of the described in the above doc mitigations is "hardening of the enabled > > code". What we mean by this, as well as techniques that are being used are > > described in this document: > https://intel.github.io/ccc-linux-guest-hardening-docs/tdx-guest-hardening.html > > Regarding driver hardening, does anyone have a better filtering idea? > > The current solution assumes the kernel command line is trusted and cannot > avoid the __init() functions that waste memory. That is two different things (command line trust and __init() functions), so I do not understand the relationship at all here. Please explain it better. Also, why would an __init() function waste memory? Memory usage isn't an issue here, right? > I don't know if the > __exit() routines of the filtered devices are called, but it doesn't sound > much better to allocate memory and free it right after. What device has a __exit() function? Drivers have module init/exit functions but they should do nothing but register themselves with the relevant busses and they are only loaded if the device is found in the system. And what exactly is incorrect about allocating memory and then freeing it when not needed? So again, I don't understand the question, sorry. thanks, greg k-h