From mboxrd@z Thu Jan 1 00:00:00 1970 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 second.openwall.net (second.openwall.net [193.110.157.125]) by smtp.lore.kernel.org (Postfix) with SMTP id BA988C27C76 for ; Wed, 25 Jan 2023 16:41:57 +0000 (UTC) Received: (qmail 28547 invoked by uid 550); 25 Jan 2023 16:41:46 -0000 Mailing-List: contact kernel-hardening-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Received: (qmail 28515 invoked from network); 25 Jan 2023 16:41:45 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mit.edu; s=outgoing; t=1674664852; bh=87ST+3j3ht853XmSEHN0xdLq8YDjUMk/ZvDAixJFyYM=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=ZyOS15yoknFWtHea0S6sBlb9jLH5MZbIghmMMAeYdcsk1vIDYas9OrAdlD2BjcEOc F4YohO7z4oO96Dyh5T2KBvee4slOGj/QZToOkse0CSkdXEnqzBC30hIZB3A4X/9J6S VbP/PnEWEEAWLo9bG+zONBnRln+1DFQ/KW71NpcDI1dEszCxk9WQsxM9LL+mMEbyfs YULe/cw7S42QiPwhbzwgW/u+P7QH4o0rPBizRVjUrma/+ahw9MWZdKyry+jDF7/xc0 N3l7NxzZ1MXrHvL9rKznMJSEHiZg2y44pjmlzahl3odMO8N7evmBTTkAA4TZZ1tafI oLEI5gSH/GuxA== Date: Wed, 25 Jan 2023 11:40:46 -0500 From: "Theodore Ts'o" To: "Reshetova, Elena" Cc: Greg Kroah-Hartman , "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 , Kernel Hardening Subject: Re: Linux guest kernel threat model for Confidential Computing Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: On Wed, Jan 25, 2023 at 03:29:07PM +0000, Reshetova, Elena wrote: > > Again, as our documentation states, when you submit patches based on > > these tools, you HAVE TO document that. Otherwise we think you all are > > crazy and will get your patches rejected. You all know this, why ignore > > it? > > Sorry, I didn’t know that for every bug that is found in linux kernel when > we are submitting a fix that we have to list the way how it has been found. > We will fix this in the future submissions, but some bugs we have are found by > plain code audit, so 'human' is the tool. So the concern is that *you* may think it is a bug, but other people may not agree. Perhaps what is needed is a full description of the goals of Confidential Computing, and what is in scope, and what is deliberately *not* in scope. I predict that when you do this, that people will come out of the wood work and say, no wait, "CoCo ala S/390 means FOO", and "CoCo ala AMD means BAR", and "CoCo ala RISC V means QUUX". Others may end up objecting, "no wait, doing this is going to mean ***insane*** changes to the entire kernel, and this will be a performance / maintenance nightmare and unless you fix your hardware in future chips, we wlil consider this a hardware bug and reject all of your patches". But it's better to figure this out now, then after you get hundreds of patches into the upstream kernel, we discover that this is only 5% of the necessary changes, and then the rest of your patches are rejected, and you have to end up fixing the hardware anyway, with the patches upstreamed so far being wasted effort. :-) If we get consensus on that document, then that can get checked into Documentation, and that can represent general consensus on the problem early on. - Ted