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.129.124]) by mx.groups.io with SMTP id smtpd.web10.15149.1672931569064371160 for ; Thu, 05 Jan 2023 07:12:49 -0800 Authentication-Results: mx.groups.io; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=B+4UW6jI; spf=pass (domain: redhat.com, ip: 170.10.129.124, mailfrom: kraxel@redhat.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1672931568; 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=V4VDA/fY4LfLjosB2K4/iba39cC5e3g4AUpDNpTujww=; b=B+4UW6jIjcwqmS/ZJiPfV9NpbemrOnIJSca5ByCmJiPW29qCOcb+pONNmIV6vpXgDmyMI9 Z7jo19rIdvqX4cw552cv/BK9tY3s50fXJHAsyBlbEVG9hVbp6sLnnYlFbcD+b8NU7zEPp5 ol/haQqQRFPgHNFEijKBeLhqjaQKUuc= Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-1-DdzuZ6m9M4uo_D6iE1p1sg-1; Thu, 05 Jan 2023 10:12:43 -0500 X-MC-Unique: DdzuZ6m9M4uo_D6iE1p1sg-1 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.rdu2.redhat.com [10.11.54.2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id A90E6802C1C; Thu, 5 Jan 2023 15:12:42 +0000 (UTC) Received: from sirius.home.kraxel.org (unknown [10.39.192.238]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 7A4E740C1141; Thu, 5 Jan 2023 15:12:42 +0000 (UTC) Received: by sirius.home.kraxel.org (Postfix, from userid 1000) id 1B11D180062D; Thu, 5 Jan 2023 16:12:41 +0100 (CET) Date: Thu, 5 Jan 2023 16:12:41 +0100 From: "Gerd Hoffmann" To: Ard Biesheuvel Cc: devel@edk2.groups.io, Alexander Graf , dann frazier , Leif Lindholm Subject: Re: [edk2-devel] [PATCH v3 03/16] ArmVirtPkg: make EFI_LOADER_DATA non-executable Message-ID: <20230105151241.ljgxdtm7nqt3zp7q@sirius.home.kraxel.org> References: <20230105081127.muckhpcw6agfkfrs@sirius.home.kraxel.org> <3F97900D-3C85-4E10-BBC2-360CECFD2D39@csgraf.de> <20230105111929.wgjtafvbht5gl2x4@sirius.home.kraxel.org> MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 3.1 on 10.11.54.2 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi, > > That sounds neat, especially as we can print a big'n'fat warning in that > > case, so the problem gets attention without actually breaking users. > > > > That, and a sleep(5) > > > Looking at the efi calls it looks like edk2 doesn't track the owner of > > an allocation (say by image handle), so I suspect it is not possible to > > automatically figure who is to blame? > > > > > Does GRUB generally load/map executable modules at page granularity? > > > > I don't think so, at least the code handles modules not being page > > aligned. But I think it's not grub modules, that fix was actually > > picked up meanwhile. But there are downstream patches for image > > loader code which look suspicious to me ... > > OK, so the GRUB PE/COFF loader strikes again :-( Yep. > Could someone check/confirm whether shim builds need to be take into > account here? Thanks. Tried booting grub.efi directly and via shim.efi, on Fedora 37 GA. In both cases I get a pagefault on linux kernel boot (before any other message is printed), which I guess happens because the loader places the linux kernel efi stub in EfiLoaderData memory. I'd say that confirms grub.efi being buggy. Not sure about shim.efi. It managed to run grub.efi without hitting a fault, which is good. But it also installs efi protocols for the boot loader to call, so it could be involved too. But maybe that happens only in case secure boot is active, which is not supported by ArmVirtPkg. take care, Gerd