Received: by 2002:a05:6a10:1a4d:0:0:0:0 with SMTP id nk13csp2387475pxb; Thu, 3 Feb 2022 05:40:52 -0800 (PST) X-Google-Smtp-Source: ABdhPJxeEZKchkSR2cIG8OfOdWNyHUzd+NUix9Lb2lO0C8xsnmMVd0YAcs4IJRxyxutBUJKLYeSV X-Received: by 2002:a17:906:9491:: with SMTP id t17mr28916490ejx.339.1643895652651; Thu, 03 Feb 2022 05:40:52 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1643895652; cv=none; d=google.com; s=arc-20160816; b=0A2/5CiF4u2ro8Wgg01bCjp2JXi+5uBqlISxbWl+J81MKD1atVtHO+V5PL4ZZx06Uy mvM3l631KXV9FK7sXCDHfL6kSJgbBQUG0M4uYP0gcodVKpZXFJejdG6kIHH00YoYgSWH yOvceQlhZp54oq0HCWoohVg/RMWcOltqDMGcID4I3TQRWgi+JzBXB61Qm9paTQpmXgqL 9ZMVANtLVetwcMfwSk1X6gAqlQ70OELeDfwLSRT/ZjXLx2ts6LdKd6z327My666JaiOb 8V0G7BHy8mUmie+a6J8upg1MBfOD55PUPCt5td6nVFUs5EeSNcmx/w2dl/vDL3Mkybtw Jtlg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :references:cc:to:content-language:subject:user-agent:mime-version :date:message-id:dkim-signature; bh=BbPHxKoric5q4pnCkk+2NcaC2f0C46PrlPGRhayIQPg=; b=tFtrgUks4t+dRi6v31HTiup76t9KKKGwNQS0qIHY3fxq2PHrPGiWiP2w9oLRl8X3XT g4LGWE9XqFF3Lg9R/06RPvSaoRYOTyA3DJAzgSHKtd6j8KsQgco7qttVz03SyWwa5qGh 6lARDSZ8bX7+CXOEvZL4IJ55D8/wx+M0Sv2oAgYLjtYZCyWSzjy5sgv2fAPJaayyVbR5 zYjdGDxzZO7g26lhfaIPqX2mErdaw4VIGanqqxRRgFNJ9F9izpZg2T/Hl3j//BhXsyF8 Tevfhq2yKY9lHGVOpkmUBNyze7fpfhXNy01hIUR2pXRlePCswp1EZFRAN5gfyMpnZP/G vKDQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@ibm.com header.s=pp1 header.b=KoDbaFth; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=ibm.com Return-Path: Received: from out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id hr1si13602965ejc.269.2022.02.03.05.40.24; Thu, 03 Feb 2022 05:40:52 -0800 (PST) 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; Authentication-Results: mx.google.com; dkim=pass header.i=@ibm.com header.s=pp1 header.b=KoDbaFth; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=ibm.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1349867AbiBCLEo (ORCPT + 99 others); Thu, 3 Feb 2022 06:04:44 -0500 Received: from mx0a-001b2d01.pphosted.com ([148.163.156.1]:3328 "EHLO mx0a-001b2d01.pphosted.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S236576AbiBCLEn (ORCPT ); Thu, 3 Feb 2022 06:04:43 -0500 Received: from pps.filterd (m0098410.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.1.2/8.16.1.2) with SMTP id 213AiCOh013287; Thu, 3 Feb 2022 11:04:14 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ibm.com; h=message-id : date : mime-version : subject : to : cc : references : from : in-reply-to : content-type : content-transfer-encoding; s=pp1; bh=BbPHxKoric5q4pnCkk+2NcaC2f0C46PrlPGRhayIQPg=; b=KoDbaFth/X6OZ5d1Od2Sn02UXI2/UzesyMFpSqv9p0lpmV+zpWmJgkgTeNhAlCkoG1fC 4w513HClOPgv8JWawuq0Lo9LcS2eNaJ6B0KRII/o4zhMIG0jvV34w/q1u1o89HwtkCfY e4bSE1VIE7Asa+mD/82+1Gu13GtC/3J3nf8z+PVtGiwH1/Q61jH4QGwjTxGxlrHGVZvQ jB3VWBFGhoQBKUVcgMKkCAbAOYijN3W3LmO2+7H9l3ER9PuqHACy8PyU/KRJOrrmSkxs gw5qJ947D4SWl4sF80qhu8hD4ck8AT5zHPoFc1ZEMq8mg2khPSDSdftInS2uxI3w4yVC sg== Received: from pps.reinject (localhost [127.0.0.1]) by mx0a-001b2d01.pphosted.com with ESMTP id 3dyvexmuvw-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 03 Feb 2022 11:04:13 +0000 Received: from m0098410.ppops.net (m0098410.ppops.net [127.0.0.1]) by pps.reinject (8.16.0.43/8.16.0.43) with SMTP id 2139qoGJ032495; Thu, 3 Feb 2022 11:04:13 GMT Received: from ppma02dal.us.ibm.com (a.bd.3ea9.ip4.static.sl-reverse.com [169.62.189.10]) by mx0a-001b2d01.pphosted.com with ESMTP id 3dyvexmuvf-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 03 Feb 2022 11:04:13 +0000 Received: from pps.filterd (ppma02dal.us.ibm.com [127.0.0.1]) by ppma02dal.us.ibm.com (8.16.1.2/8.16.1.2) with SMTP id 213B2i0L000440; Thu, 3 Feb 2022 11:04:12 GMT Received: from b01cxnp22035.gho.pok.ibm.com (b01cxnp22035.gho.pok.ibm.com [9.57.198.25]) by ppma02dal.us.ibm.com with ESMTP id 3dvw7c7nfx-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 03 Feb 2022 11:04:12 +0000 Received: from b01ledav001.gho.pok.ibm.com (b01ledav001.gho.pok.ibm.com [9.57.199.106]) by b01cxnp22035.gho.pok.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id 213B456W32965110 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 3 Feb 2022 11:04:05 GMT Received: from b01ledav001.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 371EF28064; Thu, 3 Feb 2022 11:04:05 +0000 (GMT) Received: from b01ledav001.gho.pok.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 05AB928060; Thu, 3 Feb 2022 11:03:59 +0000 (GMT) Received: from [9.65.240.79] (unknown [9.65.240.79]) by b01ledav001.gho.pok.ibm.com (Postfix) with ESMTP; Thu, 3 Feb 2022 11:03:59 +0000 (GMT) Message-ID: <815ba487-a6c1-0daa-aead-a7f3a52df2a1@linux.ibm.com> Date: Thu, 3 Feb 2022 13:03:58 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.5.1 Subject: Re: [PATCH v7 4/5] efi: Load efi_secret module if EFI secret area is populated Content-Language: en-US To: Gerd Hoffmann Cc: linux-efi@vger.kernel.org, Borislav Petkov , Ashish Kalra , Brijesh Singh , Tom Lendacky , Ard Biesheuvel , James Morris , "Serge E. Hallyn" , Andi Kleen , Greg KH , Andrew Scull , Dave Hansen , "Dr. David Alan Gilbert" , Lenny Szubowicz , Peter Gonda , James Bottomley , Tobin Feldman-Fitzthum , Jim Cadden , Daniele Buono , linux-coco@lists.linux.dev, linux-security-module@vger.kernel.org, linux-kernel@vger.kernel.org, Dov Murik References: <20220201124413.1093099-1-dovmurik@linux.ibm.com> <20220201124413.1093099-5-dovmurik@linux.ibm.com> <20220202084723.ushasiekb3cxami4@sirius.home.kraxel.org> <20220202143128.jgadmr7tzetlobt7@sirius.home.kraxel.org> <20220203061615.wwembqmmpmg77iyj@sirius.home.kraxel.org> From: Dov Murik In-Reply-To: <20220203061615.wwembqmmpmg77iyj@sirius.home.kraxel.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-TM-AS-GCONF: 00 X-Proofpoint-ORIG-GUID: trqepfqvgRVlBjWR4INAX6e7ekuRrq62 X-Proofpoint-GUID: 4inEO94yDJbCDJmeSB782KtEUjr6ZfJ4 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.205,Aquarius:18.0.816,Hydra:6.0.425,FMLib:17.11.62.513 definitions=2022-02-03_03,2022-02-03_01,2021-12-02_01 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 lowpriorityscore=0 clxscore=1015 impostorscore=0 phishscore=0 suspectscore=0 spamscore=0 mlxlogscore=999 malwarescore=0 bulkscore=0 priorityscore=1501 mlxscore=0 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2201110000 definitions=main-2202030070 Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 03/02/2022 8:16, Gerd Hoffmann wrote: > Hi, > >>> I think the module should fail noisily. See above for autoload. In >>> case the module is loaded (either manually by the admin, or because >>> efi.coco_secret != EFI_INVALID_TABLE_ADDR) and it can't actually load >>> the secrets we want know why ... >> >> Note that the AmdSev build of OVMF always publishes >> LINUX_EFI_COCO_SECRET_TABLE_GUID in the EFI table. Even when >> LAUNCH_SECRET was not executed. In such cases the secret area will be >> empty. > > Hmm, ok. Why? I assume the secret area is filled by the host and ovmf > doesn't even look at it? > Exactly. OVMF just reserves this area, and puts its address+size in the EFI config table. It doesn't care about its format and usage. There are currently two "users" for the actual data in this memory area: 1. grub's efisecret module (which reads the disk passphrase from an entry in the secret area) 2. linux's efi_secret module (which we're discussing here) >> If we keep only the 'efi.coco_secret != EFI_INVALID_TABLE_ADDR' check, >> we'll get errors from efi_secret for every VM launch that doesn't >> undergo LAUNCH_SECRET. I don't think that's good. > > Well, if that is a common case the module could either print nothing or > log KERN_INFO level instead of KERN_ERROR. > What if the user doesn't inject a secret and doesn't include the efi_secret module at all in the initrd? request_module("efi_secret") will fail. I can ignore the error code of request_module("efi_secret") but that feels bad. >> If we *do* want to check that the area starts with >> EFI_SECRET_TABLE_HEADER_GUID (like I think we should), we need all the >> checks before that, like checking that the area is big enough, and that >> all the memremap()s succeed -- before actually comparing the >> header_guid. The checks are basically prerequisites for calling >> efi_guidcmp() safely. > > It is still not fully clear to me why you want do that check twice. > I want to load the module only if secrets were injected by the Guest Owner. Again, I'm open to ideas on how to de-duplicate these early checks, if that's important. -Dov