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 vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id C617BEB64DA for ; Mon, 19 Jun 2023 15:05:11 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230046AbjFSPFK (ORCPT ); Mon, 19 Jun 2023 11:05:10 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50662 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231667AbjFSPEm (ORCPT ); Mon, 19 Jun 2023 11:04:42 -0400 Received: from mail-lf1-x12c.google.com (mail-lf1-x12c.google.com [IPv6:2a00:1450:4864:20::12c]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 59184E64 for ; Mon, 19 Jun 2023 08:03:41 -0700 (PDT) Received: by mail-lf1-x12c.google.com with SMTP id 2adb3069b0e04-4f870247d6aso1638385e87.0 for ; Mon, 19 Jun 2023 08:03:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=semihalf.com; s=google; t=1687187019; x=1689779019; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=49YbCrrQnu++46aqDxt53mcv8RYAaq7cMrbIqaaKKyY=; b=nF2ZfiGhvW695ksU2fZGH8TntTiJZDsIYNJXmRhfJhE8hrLMgVujyNeOlovtQ8zmBs YJBdLOvNi4ffSAs3QIuT44dZxkwfw1Jsk59cfo0o2+aVJrRGBC4zF1SrVJOc0tuMrch3 WCgBsh9iZWz+AhHRspSUz3dLixDXzXEXyZCArBISpBJgjvKafrnV6WiLg/VRywdKbMHH wDXJUa/K5OD2WXMFtiDt+tecmRmZWvJBjtAz0aSIDS8iVdZreDp5aMwSEz7SO3uIWmjl IYoekmh7VOrc8ZdwyGktpGMDlyoOiji0hCps/UObbPmONQO2PjwIIf+Qc64ZsGOb8nlg kBEw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1687187019; x=1689779019; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=49YbCrrQnu++46aqDxt53mcv8RYAaq7cMrbIqaaKKyY=; b=DLanMwFSy2lOgw1fmIdpwZ+8YI1jev3/GaCWAQWNCMCUZz0dTSx2KMPCpu2nOYHeT6 JmQ9W9ipbDheNrFxS7yegMgVaxRjaBm3PhE6oUF61sWdBjBGbrjq+SazXbPljrp2QvIm Wf1JTa5nsCHUYp2/gcxaLou0NwZ2+/AfbPfD8D2Jv3eAuPFgc/orWKUrNaP1DT2NFGP1 MiuWl5lWSzanAz+hCqZTM0cwjqfbHnUcwc9nMiD8ZzLsI6jMqjzhgWqyJai7mFMy1dT6 qRoy2BZ6k778XQ8cA6D5+hC7PIA5r/i5P6A98c2Sex3O0qffsUpP5lJzxnukhc1IGeme uOug== X-Gm-Message-State: AC+VfDzYYLztN3+ZR/6KLZNq5HPRs+cqf0Nd2Auaq6t8xQMUcZKSEioi kCeahiNznbb5q/ghKGewAAW5Lw== X-Google-Smtp-Source: ACHHUZ7FJRf9OVIP5GW2qC+5pDf0N+cIYCphYRWLPLD/TYzVC+I3/y+Zs8rDeqQ1h+4S2vb97c/VQw== X-Received: by 2002:a19:e30e:0:b0:4f4:b138:e998 with SMTP id a14-20020a19e30e000000b004f4b138e998mr5132982lfh.68.1687187018602; Mon, 19 Jun 2023 08:03:38 -0700 (PDT) Received: from [10.43.1.253] ([83.142.187.84]) by smtp.gmail.com with ESMTPSA id m29-20020a056512015d00b004f6366cbe72sm4295872lfo.228.2023.06.19.08.03.36 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 19 Jun 2023 08:03:38 -0700 (PDT) Message-ID: Date: Mon, 19 Jun 2023 17:03:35 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.11.0 Subject: Re: [PATCH v2] docs: security: Confidential computing intro and threat model for x86 virtualization To: "Reshetova, Elena" , "Christopherson,, Sean" Cc: Carlos Bilbao , "Chen, Jason CJ" , "corbet@lwn.net" , "linux-doc@vger.kernel.org" , "linux-kernel@vger.kernel.org" , "ardb@kernel.org" , "kraxel@redhat.com" , "dovmurik@linux.ibm.com" , "dave.hansen@linux.intel.com" , "Dhaval.Giani@amd.com" , "michael.day@amd.com" , "pavankumar.paluri@amd.com" , "David.Kaplan@amd.com" , "Reshma.Lal@amd.com" , "Jeremy.Powell@amd.com" , "sathyanarayanan.kuppuswamy@linux.intel.com" , "alexander.shishkin@linux.intel.com" , "thomas.lendacky@amd.com" , "tglx@linutronix.de" , "dgilbert@redhat.com" , "gregkh@linuxfoundation.org" , "dinechin@redhat.com" , "linux-coco@lists.linux.dev" , "berrange@redhat.com" , "mst@redhat.com" , "tytso@mit.edu" , "jikos@kernel.org" , "joro@8bytes.org" , "leon@kernel.org" , "richard.weinberger@gmail.com" , "lukas@wunner.de" , "jejb@linux.ibm.com" , "cdupontd@redhat.com" , "jasowang@redhat.com" , "sameo@rivosinc.com" , "bp@alien8.de" , "security@kernel.org" , Larry Dewey , "android-kvm@google.com" , Dmitry Torokhov , Allen Webb , Tomasz Nowicki , Grzegorz Jaszczyk , Patryk Duda References: <20230612164727.3935657-1-carlos.bilbao@amd.com> <001aa2ed-2f78-4361-451d-e31a4d4abaa0@semihalf.com> <22438996-cea6-fcdc-530b-bf3f2477a81c@semihalf.com> <10b6045e-e5e4-e1f6-f93a-34f1ad61fdfe@semihalf.com> Content-Language: en-US From: Dmytro Maluka In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 6/19/23 13:23, Reshetova, Elena wrote: >> And BTW, doesn't it mean that interrupts also need to be hardened in the >> guest (if we don't want the complexity of interrupt controllers in the >> trusted hypervisor)? At least sensitive ones like IPIs, but I guess we >> should also consider interrupt-based timings attacks, which could use >> any type of interrupt. (I have no idea how to harden either of the two >> cases, but I'm no expert.) > > We have been thinking about it a bit at least when it comes to our > TDX case. Two main issues were identified: interrupts contributing > to the state of Linux PRNG [1] and potential implications of missing > interrupts for reliable panic and other kernel use cases [2]. > > [1] https://intel.github.io/ccc-linux-guest-hardening-docs/security-spec.html#randomness-inside-tdx-guest > [2] https://intel.github.io/ccc-linux-guest-hardening-docs/security-spec.html#reliable-panic > > For the first one, in addition to simply enforce usage of RDSEED > for TDX guests, we still want to do a proper evaluation of security > of Linux PRNG under our threat model. The second one is > harder to reliably asses imo, but so far we were not able to find any > concrete attack vectors. But it would be good if people who > have expertise in this, could take a look on the assessment we did. > The logic was to go over all kernel core callers of various > smp_call_function*, on_each_cpu* and check the implications > if such an IPI is never delivered. Thanks. I also had in mind for example [1]. [1] https://people.cs.kuleuven.be/~jo.vanbulck/ccs18.pdf