From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by smtp.lore.kernel.org (Postfix) with ESMTP id 77C58C7EE32 for ; Sun, 28 May 2023 07:02:57 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229580AbjE1HCz (ORCPT ); Sun, 28 May 2023 03:02:55 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:56534 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229441AbjE1HCx (ORCPT ); Sun, 28 May 2023 03:02:53 -0400 Received: from mail-yw1-x112d.google.com (mail-yw1-x112d.google.com [IPv6:2607:f8b0:4864:20::112d]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 6576ED9; Sun, 28 May 2023 00:02:52 -0700 (PDT) Received: by mail-yw1-x112d.google.com with SMTP id 00721157ae682-561a41db2c0so32786917b3.3; Sun, 28 May 2023 00:02:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1685257371; x=1687849371; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=TRkqudkgMQ49oMc1gbKQdMb2w50Dkd1fBeJ/gvJ6yX8=; b=qmMTFrt8uoytygO19Oob0VRjf+V9CWhsO4qE9F78KrSta+nabHhX11re+hazJIZlPX TzJeNTBNwbB/qCGJaFc6B34OW2Khw8CWOyne6MGJy7DOi8STTwy4Lyel3LWUwAzb74sG mEwxjcmeyArXXCEa77HqYNLRXy+MU5Amtw8TuAHLJ3I4JXpnqJRFwSYO3T7NhYQZ0N40 9AMiK7zVcPZZt8n1p8u/NL/fk5VKFoGWY/dtTIpExxZD/B6ygrOc2dipwboWZmXU/qmt fmbXQGA0vg8g+l7EDAdUXj4eQYJZn5mY3WS03aAvA2h0h0SqU28km1LxCmAwMTqtuK32 Uglg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1685257371; x=1687849371; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=TRkqudkgMQ49oMc1gbKQdMb2w50Dkd1fBeJ/gvJ6yX8=; b=F+sR9eYAGKkbElXTrjUAswhrV7Omw/SFp0w2gtw7qe5sEUB3lXT5GgrZnfAnpUY24o 78NMWAgFKm1FhE54TDfm9LYYKinLRYFGHtipcy9BoFWxAH0wlWstYBGK61pJ2+ksRXBb q0tfYnqMblU74eZGvv3k/UwmANFTaiHMGjy6zZezFO8RmRRqEkHLcZWcR4JxsT/KvaVf 9plYE10vHN4CIqGvAXM924SS3kFvjYmg3q1n69qDXwCj0DUBn9cZCOLicAX9yisfKUm4 aFV26+gdDXHu03440AH0ANsbQMYrf7j3Gbj0wboZTMgWtykr+6D96Y16RYZvu/Jg3zb5 WkIQ== X-Gm-Message-State: AC+VfDwEEc23F7LjGLzdFxodow1ocwI0ImBLgVogrewceT74vrmzHqQM X1g3eMKk4Fm/RvfT70MDkzHL7JHTAvZgsnTzy2U= X-Google-Smtp-Source: ACHHUZ5QnHgzGna8A0ict5YGfhiUK1/FyXdi06p0MjmNBDyw5tltLHDzYhcCm1SX6aeGhqMyx+OQ3MmemowirLDgF2Y= X-Received: by 2002:a0d:cc0c:0:b0:55a:5870:3d47 with SMTP id o12-20020a0dcc0c000000b0055a58703d47mr7603574ywd.26.1685257371475; Sun, 28 May 2023 00:02:51 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Akihiro Suda Date: Sun, 28 May 2023 16:02:40 +0900 Message-ID: Subject: Re: mix of ACPICA regression and EFISTUB regression (Was: kernel >= v6.2 no longer boots on Apple's Virtualization.framework (x86_64); likely to be related to ACPICA) To: Ard Biesheuvel Cc: Linus Torvalds , Bagas Sanjaya , linux-efi@vger.kernel.org, Linux Kernel Mailing List , Linux Regressions , Linux x86 , Linux ACPI , Linux ACPICA , Linux Stable , "Rafael J. Wysocki" , Jianmin Lv , Huacai Chen , Robert Moore Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org > Fair enough. Or we could try bumping it from v1.1 to v2.0 (or v3.0 if > we make it a bit mask). > > Akihiro, would you mind checking if changing the major/minor to any of > these values results in the same problem? Surprisingly, v2.0 and v3.0 boot, although v1.1, v2.1, v2.2, v3.1, etc. do not boot. Looks like Apple's vmlinuz loader only requires LINUX_EFISTUB_MINOR_VERSION to be 0x0 and does not care about LINUX_EFISTUB_MAJOR_VERSION. 2023=E5=B9=B45=E6=9C=8828=E6=97=A5(=E6=97=A5) 6:48 Ard Biesheuvel : > > On Sat, 27 May 2023 at 21:40, Linus Torvalds > wrote: > > > > On Sat, May 27, 2023 at 11:42=E2=80=AFAM Ard Biesheuvel wrote: > > > > > > Yes, that makes the most sense. If the existing virtual machine BIOS > > > has a hardcoded check that the EFI stub version is 1.0 even if it doe= s > > > not boot via EFI to begin with, I don't see how we can reasonably > > > treat this as a regression that needs fixing on the Linux side. > > > > Well, we consider firmware issues to be the same as any hardware > > issue. If firmware has a bug that requires us to do things certain > > ways, that's really no different from hardware that requires some > > insane init sequence. > > > > So why not just say that LINUX_EFISTUB_MINOR_VERSION should be 0, and > > just add the comment that versioning doesn't work? > > > > Fair enough. Or we could try bumping it from v1.1 to v2.0 (or v3.0 if > we make it a bit mask). > > Akihiro, would you mind checking if changing the major/minor to any of > these values results in the same problem? > > Unfortunately, the only data point we have is that a non-EFI > bootloader (which is unlikely to carry a PE/COFF loader) needs the > byte at that specific offset to be 0x0, and we really have no idea > why, or whether we could hit this in other ways (i.e., by changing the > PE/COFF header to comply with new MS requirements for secure boot, > which is another thing that is in progress) > > > I'm not sure why this was tied into always enabling the initrd command > > line loader. > > > > For x86, it doesn't actually make a difference, but on other > architectures, the command line initrd=3D loader could be disabled, but > that possibility was removed. The idea was that by bumping the version > to v1.1 at the same time, generic EFI loaders would be able to > identify this capability without arch specific conditionals in the > logic. > > Currently, GRUB and systemd-stub check this version field, but only > for v1.0 or higher. Upstream GRUB switched to this generic version of > the EFI loader just this week, but does not actually use initrd=3D at > all for EFI boot (on any architecture). > > > Numbered version checks are a fundamentally broken and stupid concept > > anyway. Don't do them. Just leave it at zero, and maybe some day there > > is a sane model that actually has a bitfield of capabilities and > > requirements. > > > > Yeah, maybe you're right. Currently, only a single feature is tied to > LINUX_EFISTUB_MAJOR_VERSION=3D=3D1 (LoadFile2 support for initrd loading)= , > and this PE/COFF version field has no meaning to UEFI firmware itself, > so we could simply treat these fields as bit masks if we wanted to > (and setting the initrd command line loader bit for x86 would be > redundant anyway) > > But not being able to freely set such a bit because some rarely used > non-EFI BIOS implementation imposes requirements on the contents of > the EFI specific image header is rather disappointing.