Received: by 2002:a25:6193:0:0:0:0:0 with SMTP id v141csp359236ybb; Wed, 8 Apr 2020 00:58:36 -0700 (PDT) X-Google-Smtp-Source: APiQypL1QvWM3UOlJyOZJMEtZIdYIQLtss+Nfxy1c4q9z3kAlPviyYpaDqxEUqNb+8dlgQqB2YiY X-Received: by 2002:aca:dbd6:: with SMTP id s205mr1427847oig.109.1586332715976; Wed, 08 Apr 2020 00:58:35 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1586332715; cv=none; d=google.com; s=arc-20160816; b=WjxfA0W9Mff4SEs7oa7zgNZr/wOEjGzXsElR96Cjd1ZNc7eAVdRRpV5ydT+UX8Z5Ck ASnP0pivrjgZ4UsAAtZatp1ANKOFD1iPAboimpV/O8GqM9+fBwZbg5H8lb/xOSUMsRY9 tncRVfW3kYSh0/9Vtn/Uwh1x4z6dZwQabwy6MkSl9NGKYPBpAGJJiJobk7l8RflvLzBv HDGz3m/arKnOVAt2QptB68WQO1hTRMKV2I01169uxYEn9GE5th3rFGh7qRbVw3rnIPwa ubcRwnTLYoJQumi47pBpfmcXGAIycQzpemiltdNxKzpHmIISd0C3J/t7A9FW3j1PHsBc JaGQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=1NHXbJ1ggTEz9znHCJ6y1LtMhBGcqQmUtkFDzA2MquM=; b=oyjwYlqMBPYtYImk0xuNrPzTEFKun4BMvIDZUoeu4p0N0WV804fqwHb3uVQ7gs7LiP eqq54kJJjqXa50sZvZgwko+TK2I9HxB4g0HQarSPO5QVqv9ucEk/R0hpW+12dFp1Ioi8 Nve/7kMh0zTBQtMSYEqEuKe17zxeuQvvj4urRPU7eaOmbT3d57Khxj1001BQlWwAPtC7 8VDclCqqa/oCdZM9L1b5Bao1REzCobfc/tX7baRwJnLbHZF19MaJubWQkF9R9JB8gf76 idyl8fFnhSji3Gghx0QVOwX0BPelC6U2AYXpcnKwPjQC087zxhrxf5dcmsp307yiJQPv GT0w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=M4A3XfdL; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id j65si384554oib.191.2020.04.08.00.58.22; Wed, 08 Apr 2020 00:58:35 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=default header.b=M4A3XfdL; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726846AbgDHHt2 (ORCPT + 99 others); Wed, 8 Apr 2020 03:49:28 -0400 Received: from mail.kernel.org ([198.145.29.99]:55722 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726366AbgDHHt1 (ORCPT ); Wed, 8 Apr 2020 03:49:27 -0400 Received: from mail-io1-f54.google.com (mail-io1-f54.google.com [209.85.166.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id 300B720857; Wed, 8 Apr 2020 07:49:27 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=default; t=1586332167; bh=LFSPRKgmR8auwK03bWcZlzXa6g+J6cxGqFZeIyDLWBs=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=M4A3XfdLzGoCqjFphZs46oHKHPvNRNyaxBpA9xZOfsoCACHV49gh3cMPEQj0HjuuH K5KQp0P7ZX1Za5RsThorpN36rb8kGaUgiaq32dYWGNm/PIEGD7Xe4ymWpTMGYbdsuu gSRBrZ2r52eMPpBPRm9gCBQCDV5PL1qvhKb/3sxc= Received: by mail-io1-f54.google.com with SMTP id b12so6153064ion.8; Wed, 08 Apr 2020 00:49:27 -0700 (PDT) X-Gm-Message-State: AGi0PuZtXrHE6BJHRoT5TAyDCbab9LHXjcCi6fR3Oyja3IP1Pcug2yr4 jZpkLKZnZ/b6PHrWjviDRaWZR8QSdflqXaKQBb4= X-Received: by 2002:a6b:f413:: with SMTP id i19mr5867611iog.203.1586332166519; Wed, 08 Apr 2020 00:49:26 -0700 (PDT) MIME-Version: 1.0 References: <20200406180614.429454-1-nivedita@alum.mit.edu> <20200408074334.GA21886@dhcp-128-65.nay.redhat.com> In-Reply-To: <20200408074334.GA21886@dhcp-128-65.nay.redhat.com> From: Ard Biesheuvel Date: Wed, 8 Apr 2020 09:49:15 +0200 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH 1/2] efi/x86: Move efi stub globals from .bss to .data To: Dave Young , pjones@redhat.com, daniel.kiper@oracle.com, Leif Lindholm Cc: Arvind Sankar , Borislav Petkov , Sergey Shatunov , hpa@zytor.com, Linux Kernel Mailing List , mingo@redhat.com, Thomas Gleixner , x86@kernel.org, linux-efi , initramfs@vger.kernel.org, Donovan Tremura , Harald Hoyer Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org (add Peter, Leif and Daniel) On Wed, 8 Apr 2020 at 09:43, Dave Young wrote: > > On 04/06/20 at 02:06pm, Arvind Sankar wrote: > > Commit > > > > 3ee372ccce4d ("x86/boot/compressed/64: Remove .bss/.pgtable from > > bzImage") > > > > removed the .bss section from the bzImage. > > > > However, while a PE loader is required to zero-initialize the .bss > > section before calling the PE entry point, the EFI handover protocol > > does not currently document any requirement that .bss be initialized by > > the bootloader prior to calling the handover entry. > > > > When systemd-boot is used to boot a unified kernel image [1], the image > > is constructed by embedding the bzImage as a .linux section in a PE > > executable that contains a small stub loader from systemd together with > > additional sections and potentially an initrd. As the .bss section > > within the bzImage is no longer explicitly present as part of the file, > > it is not initialized before calling the EFI handover entry. > > Furthermore, as the size of the embedded .linux section is only the size > > of the bzImage file itself, the .bss section's memory may not even have > > been allocated. > > I did not follow up the old report, maybe I missed something. But not > sure why only systemd-boot is mentioned here. I also have similar issue > with early efi failure. With these two patches applied, it works well > then. > > BTW, I use Fedora 31 + Grub2 > OK, so I take it this means that GRUB's PE/COFF loader does not zero-initialize BSS either? Does it honor the image size in memory if it exceeds the file size?