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 03810235058 for ; Fri, 20 Jun 2025 08:19:54 +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=1750407596; cv=none; b=QZHh4WPCNput5dGetQ5JNxMC9U/N42Py2BKXzy+b9oLVFdA2l7uLhsjoTVxQj4G4R8lR2RviCotSkFt2WifYDi9RCEV6ccqKGgtnAxAywe0OTwDZKcwo7VnS0p0c2V6zP9nB0QHj7M808dEDhFu2FXuG9lvVFsCqttpfHwq1MAQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1750407596; c=relaxed/simple; bh=EZJgeG7o7S5LSoNijejXr1VzyhgQ9cnzYr7vFQVsCQM=; h=From:To:Cc:Subject:In-Reply-To:References:Date:Message-ID: MIME-Version:Content-Type; b=INTMErb5mYt8LI+0ryPaYCEplAtAIZeIB/oYZOnwM0QIFB0VC9H4nXNzbdv6/mASIsg7W5eZC60Meo9U3aecLiuZ5/l+cu40B1LqfvLQ158wCmfdYH4AfCN1BG81QjhF0IkqkxRXJ1eFR4fKaGqT3M95KrGcfrqI7M+FyPimFl8= 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=T8GyoOUe; 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="T8GyoOUe" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1750407593; 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: in-reply-to:in-reply-to:references:references; bh=I42ahxY637ah5hv17ijVkw5D/XryJ8P8/wdbbtL7i+U=; b=T8GyoOUeGnLBSycwz2L6W5+X4FSNks2h/BG1zdgZHEjB6iRbY8w2Qv9EN/tIwGQ3Y0ReG+ OvRxZ59SFYd/iVmGu+PtXP0MuurM60N3airuuhGbpR8sCTJDbEs3yimVdF99Zps25JcCw/ YfXXOMiqFvCDYCLaeBuX7OwtnKZIkDo= Received: from mail-wr1-f69.google.com (mail-wr1-f69.google.com [209.85.221.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-528-egN-QUIOOrSp75InDRMCMA-1; Fri, 20 Jun 2025 04:19:52 -0400 X-MC-Unique: egN-QUIOOrSp75InDRMCMA-1 X-Mimecast-MFC-AGG-ID: egN-QUIOOrSp75InDRMCMA_1750407591 Received: by mail-wr1-f69.google.com with SMTP id ffacd0b85a97d-3a4f3796779so788093f8f.1 for ; Fri, 20 Jun 2025 01:19:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1750407591; x=1751012391; h=mime-version:message-id:date:references:in-reply-to:subject:cc:to :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=I42ahxY637ah5hv17ijVkw5D/XryJ8P8/wdbbtL7i+U=; b=UC5g0oKBfpyl9jPO0r4IbkepK+KFek2ocaLn05RuThou8y7bi55GCz05kA79TrOK7Y UUcaYkBMK68zq3XNM0A7v9I804fYP823vvByc/TQX3riOExkVyvfdwCTKn9Abk+v0NVQ vAsDTkSkh/z0CSokeJv/bkiQSJJ05EIEwYQyKDeGinVrmb3P2Jh0xdGsXCi5R4xDiGoh VvL+Ai4Y7iiK7sQRAZVfuJoeEJCNoNtqY/u4VgGeEtMrgZkgCYsiQ+OqusIzUzr25oRx cd/BFLWhIKcZE5rXOaAvRwpJ8Dl6xa6FEMCoMh8U2J9ykv/wxlLZsG5kTZDYdJGmTKDr OwEQ== X-Gm-Message-State: AOJu0YzTuDxx5fEdMMihmYRepvl+jE+awfqd03ckJRcDQ40y7t9xU1J/ 2RxUrHqNvCIWwjVGyeNiFWg5MbzSYoL0fUAMplZCcijaFgLGENWjOUDJm44esLJZGPcd3NZeo4D YbtdEKZq9AjgBywgSHjH8pNWqsPpc58KkR+oyZl4r6tCUc2ioaKyZbuCsclr1ng== X-Gm-Gg: ASbGnctjyVwwJyAPhwTo+47/HEIBMmK77+SNYKjqL6uVpC7HNLTnAl8CqXKWMBI1wxH h7nqa0s6zNHrApPus/EQhP1n9j+wpKRI2vo5Te30+wi6VkARb9LPSs1W4dynH/vNoqJqnaKyL37 kboZBPYtwO9OA4POsVi5tobWPf2sWTfghjvxQQq7hLHhDn7TKzC//Yr/G4qjGYiLTiTqDZstw7H EZJmhOgWwTS84fmViWPeV5qrmnHkWtGkG8A2yEU5z2eeEKwB6ugOVv7Z5+SO6dpmTLr9wPMO42S 0eLaCO4o+1teiFlitPE= X-Received: by 2002:a05:6000:4284:b0:3a5:783f:5289 with SMTP id ffacd0b85a97d-3a6d1310426mr1399039f8f.49.1750407591008; Fri, 20 Jun 2025 01:19:51 -0700 (PDT) X-Google-Smtp-Source: AGHT+IHjbyKfwYax+z1je2KpEdB0he3Tm2a0YUIzDj7QxBg0hghd6uGZaDXXPhvxDh2eI7i4eZRSMA== X-Received: by 2002:a05:6000:4284:b0:3a5:783f:5289 with SMTP id ffacd0b85a97d-3a6d1310426mr1399019f8f.49.1750407590629; Fri, 20 Jun 2025 01:19:50 -0700 (PDT) Received: from fedora ([2a00:11b1:10e1:28a7:c525:9906:d20b:f587]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-3a6d117c663sm1408561f8f.64.2025.06.20.01.19.49 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 20 Jun 2025 01:19:50 -0700 (PDT) From: Vitaly Kuznetsov To: Ard Biesheuvel Cc: linux-efi@vger.kernel.org, Peter Jones , Gerd Hoffmann , Heinrich Schuchardt Subject: Re: [PATCH] efi: Fix .data section size calculations when .sbat is present In-Reply-To: References: <20250618122008.264294-1-vkuznets@redhat.com> Date: Fri, 20 Jun 2025 10:19:48 +0200 Message-ID: <874iwaq0yj.fsf@redhat.com> Precedence: bulk X-Mailing-List: linux-efi@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: text/plain Ard Biesheuvel writes: > On Thu, 19 Jun 2025 at 17:29, Ard Biesheuvel wrote: >> >> On Wed, 18 Jun 2025 at 14:20, Vitaly Kuznetsov wrote: >> > >> > Commit 0f9a1739dd0e ("efi: zboot specific mechanism for embedding SBAT >> > section") neglected to adjust the sizes of the .data section when >> > CONFIG_EFI_SBAT_FILE is set. As the result, the produced PE binary is >> > incorrect and some tools complain about it. E.g. 'sbsign' reports: >> > >> > # sbsign --key my.key --cert my.crt arch/arm64/boot/vmlinuz.efi >> > warning: file-aligned section .data extends beyond end of file >> > warning: checksum areas are greater than image size. Invalid section table? >> > >> > Note, '__data_size' was also used in the PE optional header. The field is >> > supposed to reflect "The size of the initialized data section, or the sum >> > of all such sections if there are multiple data sections.". While OVMF >> > based firmware doesn't seem to care much about what's there, it sounds like >> > including .sbat in the calculation is more correct. >> > >> > Fixes: 0f9a1739dd0e ("efi: zboot specific mechanism for embedding SBAT section") >> > Reported-by: Heinrich Schuchardt >> > Signed-off-by: Vitaly Kuznetsov >> > --- >> > drivers/firmware/efi/libstub/zboot-header.S | 2 +- >> > drivers/firmware/efi/libstub/zboot.lds | 6 ++++-- >> > 2 files changed, 5 insertions(+), 3 deletions(-) >> > >> >> Thanks for the fix. >> >> > diff --git a/drivers/firmware/efi/libstub/zboot-header.S b/drivers/firmware/efi/libstub/zboot-header.S >> > index b6431edd0fc9..65df5f52e138 100644 >> > --- a/drivers/firmware/efi/libstub/zboot-header.S >> > +++ b/drivers/firmware/efi/libstub/zboot-header.S >> > @@ -41,7 +41,7 @@ __efistub_efi_zboot_header: >> > .short .Lpe_opt_magic >> > .byte 0, 0 >> > .long _etext - .Lefi_header_end >> > - .long __data_size >> > + .long __all_data_size >> >> Frankly, I'm not sure if this is even worth the hassle. >> >> There is also a 'size of uninitialized data' field, but given that the >> .data section has both initialized data and uninitialized data, and >> the fact that no loaders appear to care about these fields, let's just >> not bother. >> > > ... or add .sbat to SizeOfCode instead. (the preceding field) > I was wondering how to make it consistent with yet-unmerged x86 patch. In v3: https://lore.kernel.org/linux-efi/20250603091951.57775-1-vkuznets@redhat.com/ .sbat was accounted as SizeOfCode but the section is "IMAGE_SCN_CNT_INITIALIZED_DATA", not "IMAGE_SCN_CNT_CODE" so I sent v4 yesterday: https://lore.kernel.org/linux-efi/20250619151759.355893-1-vkuznets@redhat.com/ which made .sbat accounted in SizeOfInitializedData. -- Vitaly