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 lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id F1517C54E58 for ; Wed, 20 Mar 2024 11:05:07 +0000 (UTC) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rmtkJ-00075c-Ji; Wed, 20 Mar 2024 07:04:35 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rmtkG-00074p-Rz for grub-devel@gnu.org; Wed, 20 Mar 2024 07:04:32 -0400 Received: from mail-qk1-x730.google.com ([2607:f8b0:4864:20::730]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1rmtkE-0004PY-0t for grub-devel@gnu.org; Wed, 20 Mar 2024 07:04:32 -0400 Received: by mail-qk1-x730.google.com with SMTP id af79cd13be357-78a16114b69so74162385a.0 for ; Wed, 20 Mar 2024 04:04:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1710932668; x=1711537468; darn=gnu.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=MfEKnJvmsG0Z5JM4ZXCPg+drObOdX7VSv7S0dQe7cbo=; b=od4jHhV+Ya3zabX9WrjN+/HksvjSqa2jAr/3KqXxAjrDYFeVVxGbq3EBV0R2ZL9sDF 8DEBtlckKvO03wQsDDJomtttpuTFqLuC5RC7fNcaAR/lkZhYIxrgrBNCgQDMj7pi6JMY QteLrzmvQLVWIaycmNPK/NT1XJub/mWuomRnc= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1710932668; x=1711537468; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=MfEKnJvmsG0Z5JM4ZXCPg+drObOdX7VSv7S0dQe7cbo=; b=Id+lnwK2cigyjZdNnbrrNGE003sKb8UnxEj9fL7cYzGiW1LT0mOd8sOLWqki+lEHCZ ThiBVd9EzAvyulRMeme+6u3mhJCrEufSdM+rRt6rfEomNaKw6QUYGVYClRyoTVoppY2D /SDEC8S+33c68YPz8iQfg3JLWfwo5IxXjesT4Ej7QqVfPtDC5ZsR8lPJqFOqXf+bnNSH gl4ub1Ofvu4P2oYEPvSP3/zNbtp21vzGwx6nZ21E7AmnN1DTGVLUBXSAQzekdOhgsL26 PELlqls3jYKEIv8ZTVhnShFusQhbf9J+LruwM7shOPJvUkL5gsy1AQ4zf196Yho3CkJE L5Cw== X-Gm-Message-State: AOJu0YwU+CzEikj6SCKZV4ac7tQiUsVILOiSBnpXzCENvHpYQWADzHfB 5CDBRIMZ58zeEl9TqM76C3gctTRycj2gXH4Jt/E5fyDRvk2pME126yHVWGi9AIT8+WMH4dA5J+u Q X-Google-Smtp-Source: AGHT+IFIlKIN9h7rco0tQXX02EmOOfcUIOmTWuCTm7kt53nSlam7im/4ulWw9UcIPaxQ4HW23RGT4w== X-Received: by 2002:a05:620a:3711:b0:788:3fac:b27a with SMTP id de17-20020a05620a371100b007883facb27amr3663404qkb.39.1710932667958; Wed, 20 Mar 2024 04:04:27 -0700 (PDT) Received: from localhost ([85.31.135.62]) by smtp.gmail.com with ESMTPSA id bl41-20020a05620a1aa900b0078a2832b33esm163914qkb.13.2024.03.20.04.04.27 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 20 Mar 2024 04:04:27 -0700 (PDT) Date: Wed, 20 Mar 2024 12:04:25 +0100 To: Ross Lagerwall Subject: Re: [PATCH 1/7] multiboot2: Add load type header and support for the PE binary type Message-ID: References: <20240313150748.791236-1-ross.lagerwall@citrix.com> <20240313150748.791236-2-ross.lagerwall@citrix.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: Received-SPF: pass client-ip=2607:f8b0:4864:20::730; envelope-from=roger.pau@cloud.com; helo=mail-qk1-x730.google.com X-Spam_score_int: -21 X-Spam_score: -2.2 X-Spam_bar: -- X-Spam_report: (-2.2 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.417, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: =?utf-8?q?Roger_Pau_Monn=C3=A9_via_Grub-devel?= Reply-To: The development of GNU GRUB Cc: Roger Pau =?utf-8?B?TW9ubsOp?= , grub-devel@gnu.org, xen-devel@lists.xenproject.org, Andrew Cooper , Daniel Kiper Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Errors-To: grub-devel-bounces+grub-devel=archiver.kernel.org@gnu.org Sender: grub-devel-bounces+grub-devel=archiver.kernel.org@gnu.org T24gVHVlLCBNYXIgMTksIDIwMjQgYXQgMDI6NDY6NTlQTSArMDAwMCwgUm9zcyBMYWdlcndhbGwg d3JvdGU6Cj4gT24gVHVlLCBNYXIgMTksIDIwMjQgYXQgMToxOOKAr1BNIFJvZ2VyIFBhdSBNb25u w6kgPHJvZ2VyLnBhdUBjaXRyaXguY29tPiB3cm90ZToKPiA+Cj4gPiBPbiBXZWQsIE1hciAxMywg MjAyNCBhdCAwMzowNzo0MlBNICswMDAwLCBSb3NzIExhZ2Vyd2FsbCB3cm90ZToKPiA+ID4gQ3Vy cmVudGx5LCBtdWx0aWJvb3QyLWNvbXBhdGlibGUgYm9vdGxvYWRlcnMgY2FuIGxvYWQgRUxGIGJp bmFyaWVzIGFuZAo+ID4gPiBhLm91dCBiaW5hcmllcy4gVGhlIHByZXNlbmNlIG9mIHRoZSBhZGRy ZXNzIGhlYWRlciB0YWcgZGV0ZXJtaW5lcwo+ID4gPiBob3cgdGhlIGJvb3Rsb2FkZXIgdHJpZXMg dG8gaW50ZXJwcmV0IHRoZSBiaW5hcnkgKGEub3V0IGlmIHRoZSBhZGRyZXNzCj4gPiA+IHRhZyBp cyBwcmVzZW50IGVsc2UgRUxGKS4KPiA+ID4KPiA+ID4gQWRkIGEgbmV3IGxvYWQgdHlwZSBoZWFk ZXIgdGFnIHRoYXQgZXhwbGljaXRseSBzdGF0ZXMgdGhlIHR5cGUgb2YgdGhlCj4gPiA+IGJpbmFy eS4gQm9vdGxvYWRlcnMgc2hvdWxkIHVzZSB0aGUgYmluYXJ5IHR5cGUgc3BlY2lmaWVkIGluIHRo ZSBsb2FkCj4gPiA+IHR5cGUgdGFnLiBJZiB0aGUgbG9hZCB0eXBlIHRhZyBpcyBub3QgcHJlc2Vu dCwgdGhlIGJvb3Rsb2FkZXIgc2hvdWxkCj4gPiA+IGZhbGwgYmFjayB0byB0aGUgcHJldmlvdXMg aGV1cmlzdGljcy4KPiA+ID4KPiA+ID4gSW4gYWRkaXRpb24gdG8gdGhlIGV4aXN0aW5nIGFkZHJl c3MgYW5kIEVMRiBsb2FkIHR5cGVzLCBzcGVjaWZ5IGEgbmV3Cj4gPiA+IG9wdGlvbmFsIFBFIGJp bmFyeSBsb2FkIHR5cGUuIFRoaXMgbmV3IHR5cGUgaXMgYSB1c2VmdWwgYWRkaXRpb24gc2luY2UK PiA+ID4gUEUgYmluYXJpZXMgY2FuIGJlIHNpZ25lZCBhbmQgdmVyaWZpZWQgKGkuZS4gdXNlZCB3 aXRoIFNlY3VyZSBCb290KS4KPiA+ID4KPiA+ID4gU2lnbmVkLW9mZi1ieTogUm9zcyBMYWdlcndh bGwgPHJvc3MubGFnZXJ3YWxsQGNpdHJpeC5jb20+Cj4gPiA+IC0tLQo+ID4gPiAgZG9jL211bHRp Ym9vdC50ZXhpIHwgMzkgKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKysrKy0tLS0tCj4g PiA+ICBkb2MvbXVsdGlib290Mi5oICAgfCAxMyArKysrKysrKysrKysrCj4gPiA+ICAyIGZpbGVz IGNoYW5nZWQsIDQ3IGluc2VydGlvbnMoKyksIDUgZGVsZXRpb25zKC0pCj4gPiA+Cj4gPiA+IGRp ZmYgLS1naXQgYS9kb2MvbXVsdGlib290LnRleGkgYi9kb2MvbXVsdGlib290LnRleGkKPiA+ID4g aW5kZXggZGY4YTBkMDU2ZTc2Li5kMTI3MTljNzQ0ZWIgMTAwNjQ0Cj4gPiA+IC0tLSBhL2RvYy9t dWx0aWJvb3QudGV4aQo+ID4gPiArKysgYi9kb2MvbXVsdGlib290LnRleGkKPiA+ID4gQEAgLTUx MSwxMSArNTExLDEyIEBAIGFzc3VtZXMgdGhhdCBubyBic3Mgc2VnbWVudCBpcyBwcmVzZW50Lgo+ ID4gPgo+ID4gPiAgTm90ZTogVGhpcyBpbmZvcm1hdGlvbiBkb2VzIG5vdCBuZWVkIHRvIGJlIHBy b3ZpZGVkIGlmIHRoZSBrZXJuZWwgaW1hZ2UKPiA+ID4gIGlzIGluIEBzY3tlbGZ9IGZvcm1hdCwg YnV0IGl0IG11c3QgYmUgcHJvdmlkZWQgaWYgdGhlIGltYWdlIGlzIGluIGEub3V0Cj4gPiA+IC1m b3JtYXQgb3IgaW4gc29tZSBvdGhlciBmb3JtYXQuIFdoZW4gdGhlIGFkZHJlc3MgdGFnIGlzIHBy ZXNlbnQgaXQgbXVzdAo+ID4gPiAtYmUgdXNlZCBpbiBvcmRlciB0byBsb2FkIHRoZSBpbWFnZSwg cmVnYXJkbGVzcyBvZiB3aGV0aGVyIGFuIEBzY3tlbGZ9Cj4gPiA+IC1oZWFkZXIgaXMgYWxzbyBw cmVzZW50LiBDb21wbGlhbnQgYm9vdCBsb2FkZXJzIG11c3QgYmUgYWJsZSB0byBsb2FkCj4gPiA+ IC1pbWFnZXMgdGhhdCBhcmUgZWl0aGVyIGluIEBzY3tlbGZ9IGZvcm1hdCBvciBjb250YWluIHRo ZSBhZGRyZXNzIHRhZwo+ID4gPiAtZW1iZWRkZWQgaW4gdGhlIE11bHRpYm9vdDIgaGVhZGVyLgo+ ID4gPiArZm9ybWF0IG9yIGluIHNvbWUgb3RoZXIgZm9ybWF0LiBJZiB0aGUgbG9hZCB0eXBlIHRh ZyBpcyBub3Qgc3BlY2lmaWVkCj4gPiA+ICthbmQgdGhlIGFkZHJlc3MgdGFnIGlzIHByZXNlbnQg aXQgbXVzdCBiZSB1c2VkIGluIG9yZGVyIHRvIGxvYWQgdGhlCj4gPiA+ICtpbWFnZSwgcmVnYXJk bGVzcyBvZiB3aGV0aGVyIGFuIEBzY3tlbGZ9IGhlYWRlciBpcyBhbHNvIHByZXNlbnQuCj4gPiA+ ICtDb21wbGlhbnQgYm9vdCBsb2FkZXJzIG11c3QgYmUgYWJsZSB0byBsb2FkIGltYWdlcyB0aGF0 IGFyZSBlaXRoZXIgaW4KPiA+ID4gK0BzY3tlbGZ9IGZvcm1hdCBvciBjb250YWluIHRoZSBhZGRy ZXNzIHRhZyBlbWJlZGRlZCBpbiB0aGUgTXVsdGlib290Mgo+ID4gPiAraGVhZGVyLgo+ID4gPgo+ ID4gPiAgQHN1YnNlY3Rpb24gVGhlIGVudHJ5IGFkZHJlc3MgdGFnIG9mIE11bHRpYm9vdDIgaGVh ZGVyCj4gPiA+Cj4gPiA+IEBAIC03MzIsNiArNzMzLDM0IEBAIGFuZCBAc2FtcHsyfSBtZWFucyBs b2FkIGltYWdlIGF0IGhpZ2hlc3QgcG9zc2libGUgYWRkcmVzcyBidXQgbm90Cj4gPiA+ICBoaWdo ZXIgdGhhbiBtYXhfYWRkci4KPiA+ID4gIEBlbmQgdGFibGUKPiA+ID4KPiA+ID4gK0Bub2RlIExv YWQgdHlwZSB0YWcKPiA+ID4gK0BzdWJzZWN0aW9uIExvYWQgdHlwZSB0YWcKPiA+ID4gKwo+ID4g PiArQGV4YW1wbGUKPiA+ID4gK0Bncm91cAo+ID4gPiArICAgICAgICArLS0tLS0tLS0tLS0tLS0t LS0tLSsKPiA+ID4gK3UxNiAgICAgfCB0eXBlID0gMTEgICAgICAgICB8Cj4gPiA+ICt1MTYgICAg IHwgZmxhZ3MgICAgICAgICAgICAgfAo+ID4gPiArdTMyICAgICB8IHNpemUgPSAxMiAgICAgICAg IHwKPiA+ID4gK3UzMiAgICAgfCBsb2FkX3R5cGUgICAgICAgICB8Cj4gPiA+ICsgICAgICAgICst LS0tLS0tLS0tLS0tLS0tLS0tKwo+ID4gPiArQGVuZCBncm91cAo+ID4gPiArQGVuZCBleGFtcGxl Cj4gPiA+ICsKPiA+ID4gK1RoaXMgdGFnIGluZGljYXRlcyB0aGUgdHlwZSBvZiB0aGUgcGF5bG9h ZCBhbmQgaG93IHRoZSBib290IGxvYWRlcgo+ID4gPiArc2hvdWxkIGxvYWQgaXQuCj4gPiA+ICsK PiA+ID4gK1RoZSBtZWFuaW5nIG9mIGVhY2ggZmllbGQgaXMgYXMgZm9sbG93czoKPiA+ID4gKwo+ ID4gPiArQHRhYmxlIEBjb2RlCj4gPiA+ICtAaXRlbSBsb2FkX3R5cGUKPiA+ID4gK1JlY29nbml6 ZWQgbG9hZCB0eXBlcyBhcmUgQHNhbXB7MH0gZm9yIGFkZHJlc3MgKGkuZS4gbG9hZCBhLm91dCB1 c2luZwo+ID4gPiArdGhlIGFkZHJlc3MgdGFnKSwgQHNhbXB7MX0gZm9yIEVMRiwgYW5kIEBzYW1w ezJ9IGZvciBQRS4gQ29tcGxpYW50Cj4gPiA+ICtib290bG9hZGVycyBzaG91bGQgaW1wbGVtZW50 IHN1cHBvcnQgZm9yIGEub3V0IGFuZCBFTEYgYXMgYSBtaW5pbXVtLiAgSWYKPiA+ID4gK3RoaXMg dGFnIGlzIG5vdCBzcGVjaWZpZWQsIHRoZSBib290IGxvYWRlciBzaG91bGQgYXR0ZW1wdCB0byBs b2FkIHRoZQo+ID4gPiArcGF5bG9hZCB1c2luZyB0aGUgaW5mb3JtYXRpb24gc3BlY2lmaWVkIGlu IHRoZSBhZGRyZXNzIHRhZyBpZiBwcmVzZW50LAo+ID4gPiArZWxzZSBpdCBzaG91bGQgbG9hZCB0 aGUgcGF5bG9hZCBhcyBhbiBFTEYgYmluYXJ5LiAgQGVuZCB0YWJsZQo+ID4KPiA+IEkgd29uZGVy IGlmIGl0IHdvdWxkIGJlIHNpbXBsZXIgdG8gdXNlIHRoZSBmb2xsb3dpbmcgb3JkZXIgaW5zdGVh ZDoKPiA+Cj4gPiAxLiBBZGRyZXNzIHRhZwo+ID4gMi4gTG9hZCB0eXBlIHRhZwo+ID4gMy4gRUxG IGhlYWRlcgo+ID4KPiA+IEl0J3MgcG9pbnRsZXNzIHRvIGFkZCBhIExvYWRlciB0eXBlIHRhZyB3 aXRoIGxvYWRfdHlwZSA9PSAwLCBhcyB0aGF0J3MKPiA+IGFscmVhZHkgbWFuZGF0ZWQgYnkgdGhl IEFkZHJlc3MgdGFnLiAgSU9XOiBzaWduYWxpbmcgdGhlIHVzZSBvZiB0aGUKPiA+IEFkZHJlc3Mg dGFnIGhlcmUgaXMga2luZCBvZiBwb2ludGxlc3MsIGlmIHRoZSBmaWVsZHMgaW4gdGhlIEFkZHJl c3MKPiA+IHRhZyBhcmUgc2V0LCB0aGF0J3MgdGhlIG9ubHkgc2lnbmFsaW5nIHJlcXVpcmVkIGZv ciB0aGUgZGF0YSBpbiB0aGUKPiA+IEFkZHJlc3MgdGFnIHRvIGJlIHVzZWQuCj4gPgo+ID4gT3Ig YXJlIHdlIGF0dGVtcHRpbmcgdG8gc3VwcG9ydCBpbWFnZXMgdGhhdCBzZXQgQWRkcmVzcyB0YWcg YW5kIExvYWQKPiA+IHR5cGUgdGFnICE9IDAgaW4gb3JkZXIgdG8gdXNlIHRoZSBBZGRyZXNzIHRh ZyB3aGVuIHRoZSBsb2FkZXIgZG9lc24ndAo+ID4gcmVjb2duaXplIHRoZSBMb2FkIHR5cGUgdGFn LCBhbmQgb3RoZXJ3aXNlIHVzZSBhIGRpZmZlcmVudCBmb3JtYXQ/Cj4gCj4gTm8sIHRoYXQgd2Fz bid0IG15IGludGVudGlvbi4gTXkgaW50ZW50aW9uIGZvciB0aGUgbG9hZCB0eXBlIHRhZyB3YXMK PiB0byBoYXZlIG9uZSB0YWcgdGhhdCB1bmFtYmlndW91c2x5IGRlc2NyaWJlcyB0aGUgcGF5bG9h ZCBmb3JtYXQgYW5kIGlmCj4gdGhhdCBpcyBtaXNzaW5nLCBmYWxsIGJhY2sgdG8gdGhlIHByZXZp b3VzIGxvZ2ljIGZvciBjb21wYXRpYmlsaXR5Lgo+IEl0IGF2b2lkcyBtb3JlIGNvbXBsaWNhdGVk IGhldXJpc3RpY3MgaWYgZGlmZmVyZW50IHBheWxvYWQgdHlwZXMgYXJlCj4gYWRkZWQgaW4gdGhl IGZ1dHVyZS4KPiAKPiA+Cj4gPiBXb3VsZCBpdCBiZSBzZW5zaWJsZSBmb3IgbXVsdGlib290MiB0 byB1c2UgUEUgaW4gcHJlZmVyZW5jZSB0byBFTEYgaWYKPiA+IHByZXNlbnQgb24gdGhlIGltYWdl PyAgKHdpdGhvdXQgcmVxdWlyaW5nIGFueSBzaWduYWxpbmcpLiAgSSB3b3VsZAo+ID4gdGhpbmsg dGhpcyBjb3VsZCBiZSB0cm91Ymxlc29tZSBpZiBrZXJuZWxzIGFyZSBzbyBmYXIgZXhwZWN0aW5n IHRoZQo+ID4gRUxGIGhlYWRlciB0byBiZSB1c2VkIHdpdGggbXVsdGlib290MiwgZXZlbiBpZiB0 aGV5IGFsc28gZXhwb3NlIGEgUEUKPiA+IGhlYWRlci4KPiA+Cj4gCj4gQUZBSUsgYW4gRUxGIGlt YWdlIGNhbid0IGFsc28gYmUgYSB2YWxpZCBQRS9DT0ZGIGltYWdlIHNpbmNlIHRoZXkgaGF2ZQo+ IGRpZmZlcmVudCBtYWdpYyBudW1iZXJzIGF0IHRoZSBzdGFydCBvZiB0aGUgaW1hZ2UuIFBlcmhh cHMgaXQgd291bGQKPiBiZSBzaW1wbGVyIHRvIGF2b2lkIGludHJvZHVjaW5nIHRoZSBsb2FkIHR5 cGUgdGFnIGFuZCBqdXN0IGxvYWQgdGhlCj4gcGF5bG9hZCBiYXNlZCBvbiB0aGUgbWFnaWMgbnVt YmVyPwoKSSB3b3VsZCBsaWtlbHkgYmUgZmluZSB3aXRoIGp1c3QgaGFuZGxpbmcgaXQgbGlrZSB3 ZSBoYW5kbGUgRUxGLCBpZiBhClBFIGhlYWRlciBpcyBmb3VuZCB1c2UgaXQuICBBcyBsb25nIGFz IEVMRiBhbmQgUEUgaGVhZGVycyBhcmUgbXV0dWFsbHkKZXhjbHVzaXZlLgoKVGhhbmtzLCBSb2dl ci4KCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fCkdydWIt ZGV2ZWwgbWFpbGluZyBsaXN0CkdydWItZGV2ZWxAZ251Lm9yZwpodHRwczovL2xpc3RzLmdudS5v cmcvbWFpbG1hbi9saXN0aW5mby9ncnViLWRldmVsCg== 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 lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 99096C54E58 for ; Wed, 20 Mar 2024 11:04:43 +0000 (UTC) Received: from list by lists.xenproject.org with outflank-mailman.695866.1086105 (Exim 4.92) (envelope-from ) id 1rmtkF-0001WZ-R2; Wed, 20 Mar 2024 11:04:31 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 695866.1086105; Wed, 20 Mar 2024 11:04:31 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rmtkF-0001WS-Nq; Wed, 20 Mar 2024 11:04:31 +0000 Received: by outflank-mailman (input) for mailman id 695866; Wed, 20 Mar 2024 11:04:30 +0000 Received: from se1-gles-sth1-in.inumbo.com ([159.253.27.254] helo=se1-gles-sth1.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1rmtkE-0001WM-FH for xen-devel@lists.xenproject.org; Wed, 20 Mar 2024 11:04:30 +0000 Received: from mail-qk1-x731.google.com (mail-qk1-x731.google.com [2607:f8b0:4864:20::731]) by se1-gles-sth1.inumbo.com (Halon) with ESMTPS id 9ef061ea-e6a9-11ee-afdd-a90da7624cb6; Wed, 20 Mar 2024 12:04:29 +0100 (CET) Received: by mail-qk1-x731.google.com with SMTP id af79cd13be357-78a13117a3dso62792985a.1 for ; Wed, 20 Mar 2024 04:04:29 -0700 (PDT) Received: from localhost ([85.31.135.62]) by smtp.gmail.com with ESMTPSA id bl41-20020a05620a1aa900b0078a2832b33esm163914qkb.13.2024.03.20.04.04.27 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 20 Mar 2024 04:04:27 -0700 (PDT) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: 9ef061ea-e6a9-11ee-afdd-a90da7624cb6 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=citrix.com; s=google; t=1710932668; x=1711537468; darn=lists.xenproject.org; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:from:to :cc:subject:date:message-id:reply-to; bh=MfEKnJvmsG0Z5JM4ZXCPg+drObOdX7VSv7S0dQe7cbo=; b=HoDgAWrP9X+QnlOCXS+EBHVdDMW2yWV5GexZC2D9DKGsyWAV9wolABVf5APYALQjul CWjim3DAeFkFSeBD4bSATvaBplKS4dINd0/KnfwEzZ26eWfxDCFCbKUuiiBRZQS+XBso tIbheIfjPcvz5EP725v8qY3wXusPLi+cWbgqw= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1710932668; x=1711537468; h=in-reply-to:content-transfer-encoding:content-disposition :mime-version:references:message-id:subject:cc:to:from:date :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=MfEKnJvmsG0Z5JM4ZXCPg+drObOdX7VSv7S0dQe7cbo=; b=C6wiUDxx0JKusuI1DdTiOav09XA/M1BjpCp6pSptfq06bsBNF69a2IaZvK0o9PS6zj GwOPT2qJlNQ4kreOEbvh4Yu51NtkCItwV1YrZDAXRu1ttg4YNAsgrDB1stqUYiShgXS5 0Q0kHVxJ2LtepYdyB607VJVbBHNYDgRB/scLFw5To0W6fZ+XVfOql5uO/HDux36c+gj+ rMLZCYXZQOrMZQssrKU8b3rE5AvfCQ+Zs5MVwrxHF+brdK/BqpRviCxSMB6ZC7UXLvsx hCmTqjAgWrtzBuvbg4FpKKOPTFaNekJ2AYXqcFk2vHFPetaI1qIXpKxTbf/PRAlE0PtW F7CQ== X-Forwarded-Encrypted: i=1; AJvYcCWAmn02PwZ0dy5qfod+O9zFPrReP1l0QmQYH00LZUxFzx980f+sAW5vVPhphT2uwoKUhX28oaajjCVHpCj2tI6VTrvD5991aTxgcYj6uSc= X-Gm-Message-State: AOJu0YwlBTwP7B/dB4zGDe6CtZxlseGuxmEg7J7oirX2zYaJS7thBh/F vAaJaYr2haqaRLH0x0qZ7XKgLsvAHClgtgA4Tsk1bdvWxB89ZxDszVHtPtfAlxY= X-Google-Smtp-Source: AGHT+IFIlKIN9h7rco0tQXX02EmOOfcUIOmTWuCTm7kt53nSlam7im/4ulWw9UcIPaxQ4HW23RGT4w== X-Received: by 2002:a05:620a:3711:b0:788:3fac:b27a with SMTP id de17-20020a05620a371100b007883facb27amr3663404qkb.39.1710932667958; Wed, 20 Mar 2024 04:04:27 -0700 (PDT) Date: Wed, 20 Mar 2024 12:04:25 +0100 From: Roger Pau =?utf-8?B?TW9ubsOp?= To: Ross Lagerwall Cc: grub-devel@gnu.org, xen-devel@lists.xenproject.org, Andrew Cooper , Daniel Kiper Subject: Re: [PATCH 1/7] multiboot2: Add load type header and support for the PE binary type Message-ID: References: <20240313150748.791236-1-ross.lagerwall@citrix.com> <20240313150748.791236-2-ross.lagerwall@citrix.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: On Tue, Mar 19, 2024 at 02:46:59PM +0000, Ross Lagerwall wrote: > On Tue, Mar 19, 2024 at 1:18 PM Roger Pau Monné wrote: > > > > On Wed, Mar 13, 2024 at 03:07:42PM +0000, Ross Lagerwall wrote: > > > Currently, multiboot2-compatible bootloaders can load ELF binaries and > > > a.out binaries. The presence of the address header tag determines > > > how the bootloader tries to interpret the binary (a.out if the address > > > tag is present else ELF). > > > > > > Add a new load type header tag that explicitly states the type of the > > > binary. Bootloaders should use the binary type specified in the load > > > type tag. If the load type tag is not present, the bootloader should > > > fall back to the previous heuristics. > > > > > > In addition to the existing address and ELF load types, specify a new > > > optional PE binary load type. This new type is a useful addition since > > > PE binaries can be signed and verified (i.e. used with Secure Boot). > > > > > > Signed-off-by: Ross Lagerwall > > > --- > > > doc/multiboot.texi | 39 ++++++++++++++++++++++++++++++++++----- > > > doc/multiboot2.h | 13 +++++++++++++ > > > 2 files changed, 47 insertions(+), 5 deletions(-) > > > > > > diff --git a/doc/multiboot.texi b/doc/multiboot.texi > > > index df8a0d056e76..d12719c744eb 100644 > > > --- a/doc/multiboot.texi > > > +++ b/doc/multiboot.texi > > > @@ -511,11 +511,12 @@ assumes that no bss segment is present. > > > > > > Note: This information does not need to be provided if the kernel image > > > is in @sc{elf} format, but it must be provided if the image is in a.out > > > -format or in some other format. When the address tag is present it must > > > -be used in order to load the image, regardless of whether an @sc{elf} > > > -header is also present. Compliant boot loaders must be able to load > > > -images that are either in @sc{elf} format or contain the address tag > > > -embedded in the Multiboot2 header. > > > +format or in some other format. If the load type tag is not specified > > > +and the address tag is present it must be used in order to load the > > > +image, regardless of whether an @sc{elf} header is also present. > > > +Compliant boot loaders must be able to load images that are either in > > > +@sc{elf} format or contain the address tag embedded in the Multiboot2 > > > +header. > > > > > > @subsection The entry address tag of Multiboot2 header > > > > > > @@ -732,6 +733,34 @@ and @samp{2} means load image at highest possible address but not > > > higher than max_addr. > > > @end table > > > > > > +@node Load type tag > > > +@subsection Load type tag > > > + > > > +@example > > > +@group > > > + +-------------------+ > > > +u16 | type = 11 | > > > +u16 | flags | > > > +u32 | size = 12 | > > > +u32 | load_type | > > > + +-------------------+ > > > +@end group > > > +@end example > > > + > > > +This tag indicates the type of the payload and how the boot loader > > > +should load it. > > > + > > > +The meaning of each field is as follows: > > > + > > > +@table @code > > > +@item load_type > > > +Recognized load types are @samp{0} for address (i.e. load a.out using > > > +the address tag), @samp{1} for ELF, and @samp{2} for PE. Compliant > > > +bootloaders should implement support for a.out and ELF as a minimum. If > > > +this tag is not specified, the boot loader should attempt to load the > > > +payload using the information specified in the address tag if present, > > > +else it should load the payload as an ELF binary. @end table > > > > I wonder if it would be simpler to use the following order instead: > > > > 1. Address tag > > 2. Load type tag > > 3. ELF header > > > > It's pointless to add a Loader type tag with load_type == 0, as that's > > already mandated by the Address tag. IOW: signaling the use of the > > Address tag here is kind of pointless, if the fields in the Address > > tag are set, that's the only signaling required for the data in the > > Address tag to be used. > > > > Or are we attempting to support images that set Address tag and Load > > type tag != 0 in order to use the Address tag when the loader doesn't > > recognize the Load type tag, and otherwise use a different format? > > No, that wasn't my intention. My intention for the load type tag was > to have one tag that unambiguously describes the payload format and if > that is missing, fall back to the previous logic for compatibility. > It avoids more complicated heuristics if different payload types are > added in the future. > > > > > Would it be sensible for multiboot2 to use PE in preference to ELF if > > present on the image? (without requiring any signaling). I would > > think this could be troublesome if kernels are so far expecting the > > ELF header to be used with multiboot2, even if they also expose a PE > > header. > > > > AFAIK an ELF image can't also be a valid PE/COFF image since they have > different magic numbers at the start of the image. Perhaps it would > be simpler to avoid introducing the load type tag and just load the > payload based on the magic number? I would likely be fine with just handling it like we handle ELF, if a PE header is found use it. As long as ELF and PE headers are mutually exclusive. Thanks, Roger.