From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 310B234A775 for ; Wed, 18 Feb 2026 21:04:09 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=170.10.133.124 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771448652; cv=none; b=Q8Ils9uB3/thHxdsHJYazDtlKABmUJhAYodp37ZxokD8RrVzSepFtrii5GqTSZRdCu6I/wATUcrR16tF9K+sgec31W9N1zLd9FA/epsVaaP8Ia2O9a6MWjiVvvR/DeLGov/lAaR6pJudao3bpxsWlBEVI+sde+AWtRAuTWSsGb4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1771448652; c=relaxed/simple; bh=qBtd2CO59a+HKvdpME8+RXTr+DLTGtsE5jPI2nVtVKA=; h=Message-ID:Subject:From:To:Cc:Date:In-Reply-To:References: Content-Type:MIME-Version; b=ogDlueRc8UrJsdMn2KFYG8GzPsMJv5r5nCsnRhaqf0GMAlAwweGLqUSd1/qz4IXYS306I8hzJXb8o1nSbLYYBFXSns1H++GYoyDwILtz27HVLsedVjaH0TV7hon+/tlXAGbyKN/tQRZfygrX1b+cw716+077wBeeqzGkEPLyO8c= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com; spf=pass smtp.mailfrom=redhat.com; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b=XUdB4z/2; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b=N5/oQMW7; arc=none smtp.client-ip=170.10.133.124 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=redhat.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (1024-bit key) header.d=redhat.com header.i=@redhat.com header.b="XUdB4z/2"; dkim=pass (2048-bit key) header.d=redhat.com header.i=@redhat.com header.b="N5/oQMW7" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1771448648; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=pPcRNxiA9VF/PkhlksjBanylvA2gRYuNpURfmKx7ewA=; b=XUdB4z/2ooGyyR1GFO/q6nUzsd6shssqEe5S3WTR+HSCOm61Tx+8x+4IZS7rhb5cFDHCcu 2gV8+dDb+NWs11HPktnfXUporxv7KdST3HfRB0YR7aOlMraWCBdDipjxI50Ej0dm+wRC3C 5Mtr0xNThT+0noB6uLqho2E84dOMc6Y= Received: from mail-qk1-f198.google.com (mail-qk1-f198.google.com [209.85.222.198]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-360-oniNuanpNZCCQSRJCj_gHQ-1; Wed, 18 Feb 2026 16:04:06 -0500 X-MC-Unique: oniNuanpNZCCQSRJCj_gHQ-1 X-Mimecast-MFC-AGG-ID: oniNuanpNZCCQSRJCj_gHQ_1771448646 Received: by mail-qk1-f198.google.com with SMTP id af79cd13be357-8c70cff1da5so130230485a.2 for ; Wed, 18 Feb 2026 13:04:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=google; t=1771448646; x=1772053446; darn=vger.kernel.org; h=mime-version:user-agent:content-transfer-encoding:organization :references:in-reply-to:date:cc:to:from:subject:message-id:from:to :cc:subject:date:message-id:reply-to; bh=pPcRNxiA9VF/PkhlksjBanylvA2gRYuNpURfmKx7ewA=; b=N5/oQMW77slCy5JJJssOVI61DoD9V2Vh5jAI0A0dy1ggfKFWmj7c7IzVs3r7hpZfoa TR07yOgyUIaNQAdEiOACUUr8lHyahS46iLIKE4X5/ShcXOa+H1xf5hqpUqE7uECij6Sq G9/Mkc4mtRVVSqPw64TQWf+nOLIWol9QOoxj+FoBVjE0lVP+TllAd+QlhjEuI2s+0Brd TR+yjGXWReX5vcEC60gwpahYdmldMBtgeT6GNlqeoKRgckcIB26ciiVPe3U7pCbKl3tv YDJw8TQ8VyMXtArM/M1Gj0sdeMnt3EkffcnAl6XyEH836KSsdVoFPnQrVHlsRVbwwqKd 0G0A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1771448646; x=1772053446; h=mime-version:user-agent:content-transfer-encoding:organization :references:in-reply-to:date:cc:to:from:subject:message-id:x-gm-gg :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=pPcRNxiA9VF/PkhlksjBanylvA2gRYuNpURfmKx7ewA=; b=OCMug+Izk910Tm0KFZ6doaeuklG4KLBBQvJbhkpJLPVstBRqgw3zMKLL5ZrjV3+iF7 7ezO9l/uJCHfbWvq75aRAF3TSy/ujQYHL1wngo3qys5np6mZI+epCpq5AFognoDw3tSd 7eqyTcTI4+iheRTRfm4kRzKCELd4+Pn6oCJ82e1e6+XjEmno/mUPoowtOjEnChbIw9oZ II6WPC+sqv3SqP+O9H0NtJu6ydZlyhK9jDRJPlWeHWeAzjEH7psGoChBLl0ca5+8cSXB RQPK2mkDHgdHG2QoZoczmotIrFyIQFn1YUsAdcsYyDFPE8nvsleZ5g4Bne9JQLDzOVzv N5aQ== X-Forwarded-Encrypted: i=1; AJvYcCXaORO5uwaa+Vj/O/Hajnz0tmhc2KqjYniJU32FvhR/eZ4I6aa/4TpWZDmaq1VPMVsC1XrdQ7+tanV/dVk=@vger.kernel.org X-Gm-Message-State: AOJu0YyWmEusZEuu4ykfHVILZzKU/l6jOu3qRo22pI9gDuts/jxkfcU2 kZSRkmkzmavpRDfl696ugNRDieNQ1Et//rtM3TbDele1m+Huzoj2O/e07BO1u5pleDJ0bFE1Jm/ icvPcKlPJLPtLwhK5OtuByixdUo9vlA8VYzFepjiuJLz52RodZ+tvoqCMD1p5IIeo6g== X-Gm-Gg: AZuq6aIH+TpRBm+UvhOBpL+LOlMCqTrwGd4n1au7vyfVrx4eFJUMueTBqmjBMqSukpS KeW6VCVNoz0Hx6p1vYs4rlfkibBg4iXRGPi18cUkrhY1p7JG/LRgHB29RJVd/z4PD7gE5nmX0p4 vrhJPU321qqps1Q5JaEHfgDQkuvoPcfOXReR0hSzt7E2+Xn3WOUs9WLNsj/iJzGIQ6FFK4eTnFW UXVgJz+YU2D1z+UsC1Ho83ijOap7xVNJhkd79xSoMb8IQDd8AFMGg0E+zLYQRrkmNyAn0aXvSeL 8fm8wX88+s/SoaziggO+Ck0zzPDkZdvmKupiH+gy/IHViHIYt3Cgjo3zT+Mz5uAsHxdsLxvWq2z b8HFXgHK5IeKB/1Gz X-Received: by 2002:a05:620a:4689:b0:8cb:4dc4:61be with SMTP id af79cd13be357-8cb4dc46babmr1909604185a.49.1771448646114; Wed, 18 Feb 2026 13:04:06 -0800 (PST) X-Received: by 2002:a05:620a:4689:b0:8cb:4dc4:61be with SMTP id af79cd13be357-8cb4dc46babmr1909597185a.49.1771448645565; Wed, 18 Feb 2026 13:04:05 -0800 (PST) Received: from m8.users.ipa.redhat.com ([2603:7000:9400:fe80::7a7]) by smtp.gmail.com with ESMTPSA id af79cd13be357-8cb2b1c7ef7sm2079117785a.28.2026.02.18.13.04.03 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 18 Feb 2026 13:04:04 -0800 (PST) Message-ID: <32e62cef7b89d9691bdd4120388ce752fd041230.camel@redhat.com> Subject: Re: [PATCH v15 00/28] x86: Secure Launch support for Intel TXT From: Simo Sorce To: Andy Lutomirski , "H. Peter Anvin" Cc: Ard Biesheuvel , "Daniel P. Smith" , Ross Philipson , linux-kernel@vger.kernel.org, x86@kernel.org, linux-integrity@vger.kernel.org, linux-doc@vger.kernel.org, linux-crypto@vger.kernel.org, kexec@lists.infradead.org, linux-efi@vger.kernel.org, iommu@lists.linux.dev, dave.hansen@linux.intel.com, Thomas Gleixner , Ingo Molnar , Borislav Petkov , mjg59@srcf.ucam.org, James.Bottomley@hansenpartnership.com, peterhuewe@gmx.de, Jarkko Sakkinen , jgg@ziepe.ca, nivedita@alum.mit.edu, Herbert Xu , davem@davemloft.net, corbet@lwn.net, ebiederm@xmission.com, dwmw2@infradead.org, baolu.lu@linux.intel.com, kanth.ghatraju@oracle.com, andrew.cooper3@citrix.com, trenchboot-devel@googlegroups.com Date: Wed, 18 Feb 2026 16:04:03 -0500 In-Reply-To: References: <20251215233316.1076248-1-ross.philipson@oracle.com> <1ffd3cb5-2c76-4371-a067-3e4849907d80@apertussolutions.com> <49d169bf-0ad2-49be-b7d7-fceb9e7f831a@app.fastmail.com> <1BBD7449-8420-43FD-930B-A4E1BA38FFC6@zytor.com> Organization: Red Hat Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.56.2 (3.56.2-2.fc42) Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 On Wed, 2026-02-18 at 12:34 -0800, Andy Lutomirski wrote: > On Wed, Feb 18, 2026 at 12:29=E2=80=AFPM H. Peter Anvin w= rote: > >=20 > > On February 18, 2026 12:03:27 PM PST, Andy Lutomirski wrote: > > > On Thu, Feb 12, 2026 at 12:40=E2=80=AFPM Ard Biesheuvel wrote: > > > >=20 > > > > On Thu, 12 Feb 2026, at 20:49, Daniel P. Smith wrote: > > > > > On 2/9/26 09:04, Ard Biesheuvel wrote: > > > > ... > > > > > > Surprisingly, even when doing a secure launch, the EFI runtime = services still work happily, which means (AIUI) that code that was excluded= from the D-RTM TCB is still being executed at ring 0? Doesn't this defeat = D-RTM entirely in the case some exploit is hidden in the EFI runtime code? = Should we measure the contents of EfiRuntimeServicesCode regions too? > > > > >=20 > > > > > Yes, in fact in the early days I specifically stated that we shou= ld > > > > > provide for the ability to measure the RS blocks. Particularly if= you > > > > > are not in an environment where you can isolate the calls to RS f= rom the > > > > > TCB. While the RS can pose runtime corruption risks, the larger c= oncern > > > > > is integrating the D-RTM validation of the Intel System Resources > > > > > Defense (ISRD), aka SMI isolation/SMM Supervisor, provided by the= Intel > > > > > System Security Report (ISSR). Within the ISSR is a list of memor= y > > > > > regions which the SMM Policy Shim (SPS) restricts a SMI handler's= access > > > > > when running. This allows a kernel to restrict what access a SMI = handler > > > > > are able to reach, thus allowing them to be removed from the TCB = when > > > > > the appropriate guards are put in place. > > > > >=20 > > > > > If you are interested in understanding these further, Satoshi Tan= da has > > > > > probably the best technical explanation without Intel market spea= k. > > > > >=20 > > > > > ISRD: https://tandasat.github.io/blog/2024/02/29/ISRD.html > > > > > ISSR: https://tandasat.github.io/blog/2024/03/18/ISSR.html > > > > >=20 > > > >=20 > > > > Thanks, I'll take a look at those. > > > >=20 > > > > But would it be better to disable the runtime services by default w= hen doing a secure launch? PREEMPT_RT already does the same. > > >=20 > > > So I have a possible way to disable EFI runtime service without losin= g > > > the ability to write EFI vars. We come up with a simple file format > > > to store deferred EFI var updates and we come up with a place to put > > > it so that we find it early-ish in boot the next time around. (This > > > could be done via integration with systemd-boot or shim some other > > > boot loader or it could actually be part of the kernel.) And then, > > > instead of writing variables directly, we write them to the deferred > > > list and then update them on reboot (before TXT launch, etc). [0] > > > This would be a distincly nontrivial project and would not work for > > > all configurations. > > >=20 > > > As a maybe less painful option, we could disable EFI runtime services > > > but have a root-writable thing in sysfs that (a) turns them back on > > > but (b) first extends a PCR to say that they're turned back on. > > >=20 > > > (Or someone could try running runtime services at CPL3...) > > >=20 > > > [0] I have thought for years that Intel and AMD should do this on > > > their end, too. Keep the sensitive part of SMI flash entirely locked > > > after boot and, instead of using magic SMM stuff to validate that > > > write attempts have the appropriate permissions and signatures, queue > > > them up as deferred upates and validate the signatures on the next > > > boot before locking flash. > > >=20 > >=20 > > *If* a physical EFI partition exists there is a lot to be said for this= approach. > >=20 > > The only issue with this that I can see is for things like network or C= D/DVD booting where there isn't necessarily any EFI boot partition, it migh= t not be writable, or it might not be persistent (e.g. http booting typical= ly uses a ramdisk, like the old Linux initrd.) >=20 > Hmm, I guess my approach is a 100% complete nonstarter for installing > Linux from a CD, and it's really not awesome for installing Linux from > a USB stick. Doing any of this on a removable device feels generally like a trap. You get your USB disk in, try to boot, and it saves vars, but reboot fails for whatever reason, you plug it in another machine ... and it tries to "continue" from there? The amount of validation needed and testing for failure modes across reboots sounds really painful. --=20 Simo Sorce Distinguished Engineer RHEL Crypto Team Red Hat, Inc