Received-SPF: pass (google.com: domain of linux-kernel+bounces-201153-linux.lists.archive=gmail.com@vger.kernel.org designates 147.75.199.223 as permitted sender) client-ip=147.75.199.223;
Message-ID: <5bffa507-75e8-4cce-ac0c-fe13d6efd3bb@oracle.com>
Date: Tue, 4 Jun 2024 10:24:06 -0700
User-Agent: Mozilla Thunderbird
Subject: Re: [PATCH v9 08/19] x86: Secure Launch kernel early boot stub
To: Ard Biesheuvel <ardb@kernel.org>
Cc: 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-foundation.org,
        dpsmith@apertussolutions.com, tglx@linutronix.de, mingo@redhat.com,
        bp@alien8.de, hpa@zytor.com, dave.hansen@linux.intel.com,
        mjg59@srcf.ucam.org, James.Bottomley@hansenpartnership.com,
        peterhuewe@gmx.de, jarkko@kernel.org, jgg@ziepe.ca,
        luto@amacapital.net, nivedita@alum.mit.edu,
        herbert@gondor.apana.org.au, 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, ross.philipson@oracle.com
References: <20240531010331.134441-1-ross.philipson@oracle.com>
 <20240531010331.134441-9-ross.philipson@oracle.com>
 <CAMj1kXHaH6atsvwr6oVPdZuhR5YEXU33-2kYEn6xb1e=gidOCw@mail.gmail.com>
 <CAMj1kXHcYOPTLTh-hEtfHk+JaORGK+fEatTT+UOqLJww+_cNTg@mail.gmail.com>
Content-Language: en-US
From: ross.philipson@oracle.com
In-Reply-To: <CAMj1kXHcYOPTLTh-hEtfHk+JaORGK+fEatTT+UOqLJww+_cNTg@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Precedence: bulk
MIME-Version: 1.0
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: 
	=?utf-8?B?SS8vNDA0WEc1NnpDbTZjQ1F5QUlWVVJueXpDQWhmd3RheCtGZS9aWUxjWW81?=
 =?utf-8?B?MHo2M0liSGM3bDBFL1l3N3dVdDgxaDlNb21HMkZWdWthT2lQWXVkVkxYaXJh?=
 =?utf-8?B?TFZmTkZrM0dkUVpUYWF6cG9VcnhNNFpGSmhHeStRZm4yRWNJOXRHYzEvL0Nm?=
 =?utf-8?B?dWNBZlpOWEZzWGd4eUhwWEFvWWQ2WUhtTG9iRTV0M0FneXZlbitGdXRaWjM2?=
 =?utf-8?B?eW9LaklBK0drMnY0bDVXemV2dHduZ3lzNFBvck9nQjkwVXlJNjErY3cwUHRL?=
 =?utf-8?B?S3lPL0JRT0Q1UHZscEZqcFFEYnlTeVdzRlVNZTJ0TnRVL3cwNDY4R2NYeUkw?=
 =?utf-8?B?YVU5NUYvdkg3TFdYNTVEL0I5NHlxaXhMUmVoSWNaai9QbDhPbWUvZGgzbzlv?=
 =?utf-8?B?RnYyNE5BNVVzRjdwZ1hZenRydGxoUmMvamJzVWorbURzNXpFU2RVcGwwU1Nv?=
 =?utf-8?B?amxWN3liNGRYM0F2bW5DUU5HYVV6dlNFUTZNU25oRU5pSnNNRXN0RDNZMTZn?=
 =?utf-8?B?TXB2VUN0dmVBTGxIOG12UHlDRkhPSjYzUXdkSDdjZjlnclFxeWtIMFl6QVNx?=
 =?utf-8?B?NVNRMWVnSzdiUDluR2VESXRyWUJOOHNpdFBuSThVTmZCWjlOU2ZPbU1oTlpL?=
 =?utf-8?B?VFRvVjM5dFRyWXIreFRVRHRPQ001citrMlA1ckZYdlVxbnhsZmNwL01weTBE?=
 =?utf-8?B?WEt6WEFQd3VNYVBTaXFzYytsMkxoLzE4dkd1WkdSZDloV3hLMTVuTHk3R2Iw?=
 =?utf-8?B?Z29mVjVZajNnODg1WmtIU3d4anNHOGljbmsyUzJQWW1GRnJWazZ3VnQ3UUNW?=
 =?utf-8?B?dC9sZjVHWk5MRnpVOEVkQ2luTG94SG4yWFY3VXlQNzdhT0JTUmpuNGlKTWpF?=
 =?utf-8?B?RnRsaytMKzQ0TnpRVGFsMllkUnh3eVI3d0NGNUJVMlZ0Q0RkeFJTNVRtK2Fv?=
 =?utf-8?B?ZHh3ZnA5M1BJUFQ4ZmEyQzhjZ3RwNndVV3ZGaDUzdms2VExuYVR2L0Jzd0FY?=
 =?utf-8?B?QVFaOGpsb0FxSFgvZ3BFdS9Yc2V6QmxEeTZhVWdSMjhqd3kzbGdjczRmZFBZ?=
 =?utf-8?B?bmRuVEhxQVRHL3VuKzk0RFhUNHhPZC83TGx1SFdNQ0lYVUI5Rk1Fdk45aS9w?=
 =?utf-8?B?d1Q4WldUckdNVHh2VmhOMmp4RVNSK2FwcExYelpHcFVEV2xPS1VnV2E0MzRr?=
 =?utf-8?B?Zm01amNWelI2WjQxTW9xOXkwSytjYUthNFJBU1FoaThhOTRwUzBpK3E2QVVK?=
 =?utf-8?B?ODhlS0xoOWhFZ3ZZQ0tGV0NVdnVWOS9GbkJralNSYXZhdEpTZ3pIaE9ZekRv?=
 =?utf-8?B?WE1pM2pWUVdLNFVsT1VZNkt4L2pBU1M0S2txWCtZb280cEVWTnFtYjB2d3gv?=
 =?utf-8?B?N2JjY3pHYWdXR0EyWjJSSEgvU1IvRUZ3VkxTanE5QWN2TDNrS25nOUZFU0ky?=
 =?utf-8?B?WmVEd2t6YVpaZzJMVzRTMEN2MW02ZXdMTVVHOGQ0UmdrSEhUcG85T25yd3k5?=
 =?utf-8?B?ZkxQTW44ZFc0aEVnM3Z3YXBXVWw0dytZT1c4bWpWSjVZZm1nTCtXTUVZRjVF?=
 =?utf-8?B?WVl2UlMxeGNiRW5kelBxZFJUNEZjRnFqUmhtQUUxbFV1V0J6aFB6dTNDcW1X?=
 =?utf-8?B?T0tJVTROT2UvdittZEJGV01ycUgyOEY5Z1dDdXJOZUtJeXM0QmZzMDdjSEpu?=
 =?utf-8?B?Y2UxREFXTnVmNUdTN3BIYTFIbC9URDhnbVNkaVBOMTZHR01rejBtZWgydmkr?=
 =?utf-8?B?SndzYW9RL1c5UUpxdmxnd1E4OWk4NEhEZjlWVWVraDc3YW5Zc1hIcG5Qa2NC?=
 =?utf-8?B?eTdnWEdLTVpxOXN4RUxJa3o2ZjBJM3Fla2dFeDl1cmxNR1RlbzRYeER6S2JD?=
 =?utf-8?B?OHFiSXRsZ05qeDFnUUhTK2dnTWhkd2dZaDk2QXJ4VGNXQndmWGh3Mjgwd0NF?=
 =?utf-8?B?ajRJRWJ4V0pFMm41TW5MaEZMaDR0TGM3VUtBOGxlYXdjallhYU1CRFZ3Mk5o?=
 =?utf-8?B?b05iRWEwdGZSYXRERS91Q1pvekFOTEtNQmlkbUhmYzhxYWVyeWVVekl5ZWVF?=
 =?utf-8?B?ZGpDRHRvNEVJdlRMWDBENkpwT1hBdWZqc280dVowY2YzQ2lvblpRdmIybFZ1?=
 =?utf-8?B?QXlyTnluKzdrdnZKaFZuMHIvS25yU0xmTit5NW1CU1ltOXJuSll5RFlFTXF6?=
 =?utf-8?B?d3c9PQ==?=
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-ExternalHop-MessageData-0: 
	XNhF29g3HWsG8wLAZOI2owQ46Y7UdQeq1e2xiHksV+3KcIQV6YFh9bKJpv8e/dbG4qyPXQECiXSlhoGaPCRHpreNuMIJQu2aWrLkkoT0gYRC52KQSuCRo3yl2lxeR1LFHmnuE2xxkjRM1RFOFFZq45C0re458kNg/US0b/T2XA0KJTBWBhZWGvHiWETAjuqxCeCyNyy9L94YIRLAJD6wAMtnJ3hIS8wbWR6M9OwBW/GxzuNeRdkrOy6LMq0fquY7mYQCiuIMXcOQDenozulUG94/V/lZWbTE8MXfRmXIJgNgOedpKNvsq9DXlU9awBj461BNC0UPHl2h31RLdMDtLGF6Ubn9l4z2gl0LLOm18xY3iREiqg4Ruqs57jNRjhnYqnNPXLnUmtLIAToIS1KlKxNIWnHwoZVq3QKIq35Kz0HsdZ607/lzug2m+m1yvF7IavtY+cQ4ydrMDgThgFKC/JkuoUetDazmTtBxxjgDy6a+mi0AGc6iLzPS7QBEN7KLsZP6nO4ZiuvUOYTs+xgNhuIqVo7zdJZcpUuyRUVmanwgo6/BuPwE+hGRUNFCo0/tQBjDcLtzEo/Wc+D1xTcZk5qGUCuYUv3K/Uq0Nqzt5Uc=
X-OriginatorOrg: oracle.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 628e4475-78fe-40e0-6fb3-08dc84bb2591
X-MS-Exchange-CrossTenant-AuthSource: DS0PR10MB7224.namprd10.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Jun 2024 17:24:10.5596
 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: frTrel5q8js5WS1qIVR191iUj13haKGvIGM1p50FRK78ytOphOkVektfGItUuKI55Q4j3GJeI1UrzYaNCMCFltQfSMFdKtvyUjmYRSl60sE=
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DS0PR10MB7363
X-Proofpoint-Virus-Version: vendor=baseguard
 engine=ICAP:2.0.293,Aquarius:18.0.1039,Hydra:6.0.680,FMLib:17.12.28.16
 definitions=2024-06-04_09,2024-06-04_01,2024-05-17_01
X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxscore=0 bulkscore=0 spamscore=0
 malwarescore=0 suspectscore=0 phishscore=0 mlxlogscore=999 adultscore=0
 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2405010000
 definitions=main-2406040139
X-Proofpoint-ORIG-GUID: WlogrfIohrhNb_VKaH4qAMvfRJdqTfqe
X-Proofpoint-GUID: WlogrfIohrhNb_VKaH4qAMvfRJdqTfqe

On 5/31/24 6:33 AM, Ard Biesheuvel wrote:
> On Fri, 31 May 2024 at 13:00, Ard Biesheuvel <ardb@kernel.org> wrote:
>>
>> Hello Ross,
>>
>> On Fri, 31 May 2024 at 03:32, Ross Philipson <ross.philipson@oracle.com> wrote:
>>>
>>> The Secure Launch (SL) stub provides the entry point for Intel TXT (and
>>> later AMD SKINIT) to vector to during the late launch. The symbol
>>> sl_stub_entry is that entry point and its offset into the kernel is
>>> conveyed to the launching code using the MLE (Measured Launch
>>> Environment) header in the structure named mle_header. The offset of the
>>> MLE header is set in the kernel_info. The routine sl_stub contains the
>>> very early late launch setup code responsible for setting up the basic
>>> environment to allow the normal kernel startup_32 code to proceed. It is
>>> also responsible for properly waking and handling the APs on Intel
>>> platforms. The routine sl_main which runs after entering 64b mode is
>>> responsible for measuring configuration and module information before
>>> it is used like the boot params, the kernel command line, the TXT heap,
>>> an external initramfs, etc.
>>>
>>> Signed-off-by: Ross Philipson <ross.philipson@oracle.com>
>>> ---
>>>   Documentation/arch/x86/boot.rst        |  21 +
>>>   arch/x86/boot/compressed/Makefile      |   3 +-
>>>   arch/x86/boot/compressed/head_64.S     |  30 +
>>>   arch/x86/boot/compressed/kernel_info.S |  34 ++
>>>   arch/x86/boot/compressed/sl_main.c     | 577 ++++++++++++++++++++
>>>   arch/x86/boot/compressed/sl_stub.S     | 725 +++++++++++++++++++++++++
>>>   arch/x86/include/asm/msr-index.h       |   5 +
>>>   arch/x86/include/uapi/asm/bootparam.h  |   1 +
>>>   arch/x86/kernel/asm-offsets.c          |  20 +
>>>   9 files changed, 1415 insertions(+), 1 deletion(-)
>>>   create mode 100644 arch/x86/boot/compressed/sl_main.c
>>>   create mode 100644 arch/x86/boot/compressed/sl_stub.S
>>>
>>> diff --git a/Documentation/arch/x86/boot.rst b/Documentation/arch/x86/boot.rst
>>> index 4fd492cb4970..295cdf9bcbdb 100644
>>> --- a/Documentation/arch/x86/boot.rst
>>> +++ b/Documentation/arch/x86/boot.rst
>>> @@ -482,6 +482,14 @@ Protocol:  2.00+
>>>              - If 1, KASLR enabled.
>>>              - If 0, KASLR disabled.
>>>
>>> +  Bit 2 (kernel internal): SLAUNCH_FLAG
>>> +
>>> +       - Used internally by the setup kernel to communicate
>>> +         Secure Launch status to kernel proper.
>>> +
>>> +           - If 1, Secure Launch enabled.
>>> +           - If 0, Secure Launch disabled.
>>> +
>>>     Bit 5 (write): QUIET_FLAG
>>>
>>>          - If 0, print early messages.
>>> @@ -1028,6 +1036,19 @@ Offset/size:     0x000c/4
>>>
>>>     This field contains maximal allowed type for setup_data and setup_indirect structs.
>>>
>>> +============   =================
>>> +Field name:    mle_header_offset
>>> +Offset/size:   0x0010/4
>>> +============   =================
>>> +
>>> +  This field contains the offset to the Secure Launch Measured Launch Environment
>>> +  (MLE) header. This offset is used to locate information needed during a secure
>>> +  late launch using Intel TXT. If the offset is zero, the kernel does not have
>>> +  Secure Launch capabilities. The MLE entry point is called from TXT on the BSP
>>> +  following a success measured launch. The specific state of the processors is
>>> +  outlined in the TXT Software Development Guide, the latest can be found here:
>>> +  https://urldefense.com/v3/__https://www.intel.com/content/dam/www/public/us/en/documents/guides/intel-txt-software-development-guide.pdf__;!!ACWV5N9M2RV99hQ!Mng0gnPhOYZ8D02t1rYwQfY6U3uWaypJyd1T2rsWz3QNHr9GhIZ9ANB_-cgPExxX0e0KmCpda-3VX8Fj$
>>> +
>>>
>>
>> Could we just repaint this field as the offset relative to the start
>> of kernel_info rather than relative to the start of the image? That
>> way, there is no need for patch #1, and given that the consumer of
>> this field accesses it via kernel_info, I wouldn't expect any issues
>> in applying this offset to obtain the actual address.
>>
>>
>>>   The Image Checksum
>>>   ==================
>>> diff --git a/arch/x86/boot/compressed/Makefile b/arch/x86/boot/compressed/Makefile
>>> index 9189a0e28686..9076a248d4b4 100644
>>> --- a/arch/x86/boot/compressed/Makefile
>>> +++ b/arch/x86/boot/compressed/Makefile
>>> @@ -118,7 +118,8 @@ vmlinux-objs-$(CONFIG_EFI) += $(obj)/efi.o
>>>   vmlinux-objs-$(CONFIG_EFI_MIXED) += $(obj)/efi_mixed.o
>>>   vmlinux-objs-$(CONFIG_EFI_STUB) += $(objtree)/drivers/firmware/efi/libstub/lib.a
>>>
>>> -vmlinux-objs-$(CONFIG_SECURE_LAUNCH) += $(obj)/early_sha1.o $(obj)/early_sha256.o
>>> +vmlinux-objs-$(CONFIG_SECURE_LAUNCH) += $(obj)/early_sha1.o $(obj)/early_sha256.o \
>>> +       $(obj)/sl_main.o $(obj)/sl_stub.o
>>>
>>>   $(obj)/vmlinux: $(vmlinux-objs-y) FORCE
>>>          $(call if_changed,ld)
>>> diff --git a/arch/x86/boot/compressed/head_64.S b/arch/x86/boot/compressed/head_64.S
>>> index 1dcb794c5479..803c9e2e6d85 100644
>>> --- a/arch/x86/boot/compressed/head_64.S
>>> +++ b/arch/x86/boot/compressed/head_64.S
>>> @@ -420,6 +420,13 @@ SYM_CODE_START(startup_64)
>>>          pushq   $0
>>>          popfq
>>>
>>> +#ifdef CONFIG_SECURE_LAUNCH
>>> +       /* Ensure the relocation region is coverd by a PMR */
>>
>> covered
>>
>>> +       movq    %rbx, %rdi
>>> +       movl    $(_bss - startup_32), %esi
>>> +       callq   sl_check_region
>>> +#endif
>>> +
>>>   /*
>>>    * Copy the compressed kernel to the end of our buffer
>>>    * where decompression in place becomes safe.
>>> @@ -462,6 +469,29 @@ SYM_FUNC_START_LOCAL_NOALIGN(.Lrelocated)
>>>          shrq    $3, %rcx
>>>          rep     stosq
>>>
>>> +#ifdef CONFIG_SECURE_LAUNCH
>>> +       /*
>>> +        * Have to do the final early sl stub work in 64b area.
>>> +        *
>>> +        * *********** NOTE ***********
>>> +        *
>>> +        * Several boot params get used before we get a chance to measure
>>> +        * them in this call. This is a known issue and we currently don't
>>> +        * have a solution. The scratch field doesn't matter. There is no
>>> +        * obvious way to do anything about the use of kernel_alignment or
>>> +        * init_size though these seem low risk with all the PMR and overlap
>>> +        * checks in place.
>>> +        */
>>> +       movq    %r15, %rdi
>>> +       callq   sl_main
>>> +
>>> +       /* Ensure the decompression location is covered by a PMR */
>>> +       movq    %rbp, %rdi
>>> +       movq    output_len(%rip), %rsi
>>> +       callq   sl_check_region
>>> +#endif
>>> +
>>> +       pushq   %rsi
>>
>> This looks like a rebase error.
>>
>>>          call    load_stage2_idt
>>>
>>>          /* Pass boot_params to initialize_identity_maps() */
>>> diff --git a/arch/x86/boot/compressed/kernel_info.S b/arch/x86/boot/compressed/kernel_info.S
>>> index c18f07181dd5..e199b87764e9 100644
>>> --- a/arch/x86/boot/compressed/kernel_info.S
>>> +++ b/arch/x86/boot/compressed/kernel_info.S
>>> @@ -28,6 +28,40 @@ SYM_DATA_START(kernel_info)
>>>          /* Maximal allowed type for setup_data and setup_indirect structs. */
>>>          .long   SETUP_TYPE_MAX
>>>
>>> +       /* Offset to the MLE header structure */
>>> +#if IS_ENABLED(CONFIG_SECURE_LAUNCH)
>>> +       .long   rva(mle_header)
>>
>> ... so this could just be mle_header - kernel_info, and the consumer
>> can do the math instead.
>>
>>> +#else
>>> +       .long   0
>>> +#endif
>>> +
>>>   kernel_info_var_len_data:
>>>          /* Empty for time being... */
>>>   SYM_DATA_END_LABEL(kernel_info, SYM_L_LOCAL, kernel_info_end)
>>> +
>>> +#if IS_ENABLED(CONFIG_SECURE_LAUNCH)
>>> +       /*
>>> +        * The MLE Header per the TXT Specification, section 2.1
>>> +        * MLE capabilities, see table 4. Capabilities set:
>>> +        * bit 0: Support for GETSEC[WAKEUP] for RLP wakeup
>>> +        * bit 1: Support for RLP wakeup using MONITOR address
>>> +        * bit 2: The ECX register will contain the pointer to the MLE page table
>>> +        * bit 5: TPM 1.2 family: Details/authorities PCR usage support
>>> +        * bit 9: Supported format of TPM 2.0 event log - TCG compliant
>>> +        */
>>> +SYM_DATA_START(mle_header)
>>> +       .long   0x9082ac5a  /* UUID0 */
>>> +       .long   0x74a7476f  /* UUID1 */
>>> +       .long   0xa2555c0f  /* UUID2 */
>>> +       .long   0x42b651cb  /* UUID3 */
>>> +       .long   0x00000034  /* MLE header size */
>>> +       .long   0x00020002  /* MLE version 2.2 */
>>> +       .long   rva(sl_stub_entry) /* Linear entry point of MLE (virt. address) */
>>
>> and these should perhaps be relative to mle_header?
>>
>>> +       .long   0x00000000  /* First valid page of MLE */
>>> +       .long   0x00000000  /* Offset within binary of first byte of MLE */
>>> +       .long   rva(_edata) /* Offset within binary of last byte + 1 of MLE */
>>
>> and here
>>
> 
> Ugh never mind - these are specified externally.

Can you clarify your follow on comment here?

Thank you,
Ross