xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Jan Beulich <jbeulich@suse.com>
To: Bobby Eshleman <bobbyeshleman@gmail.com>
Cc: Daniel Kiper <daniel.kiper@oracle.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>,
	George Dunlap <george.dunlap@citrix.com>,
	Ian Jackson <iwj@xenproject.org>, Julien Grall <julien@xen.org>,
	Stefano Stabellini <sstabellini@kernel.org>, Wei Liu <wl@xen.org>,
	Olivier Lambert <olivier.lambert@vates.fr>,
	Xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [PATCH v3 0/5] Support Secure Boot for multiboot2 Xen
Date: Mon, 25 Jan 2021 09:52:49 +0100	[thread overview]
Message-ID: <5e5e4b26-d956-976d-f076-27eb0f8f479c@suse.com> (raw)
In-Reply-To: <YAtBH/XYrp2Nrfy2@piano>

On 22.01.2021 22:18, Bobby Eshleman wrote:
> On Fri, Jan 22, 2021 at 10:39:28AM +0100, Jan Beulich wrote:
>> On 22.01.2021 01:51, Bobby Eshleman wrote:
>>> I followed with v2 feedback and attempted to convert the PE/COFF header
>>> into C instead of ASM.  Unfortunately, this was only possible for the
>>> first part (Legacy) of the PE/COFF header.  The other parts required
>>> addresses only available at link time (such as __2M_rwdata_end,
>>> __pe_SizeOfImage, efi_mb_start address, etc...), which effectively ruled
>>> out C.
>>
>> I don't follow the conclusion drawn, so would you mind going into
>> further detail?
>>
> 
> No problem at all, bad explanation on my part.  The core issue is
> actually about the legality of casting 64-bit addresses to 32-bit values
> in constant expressions, which then is sometimes complained about by GCC
> in terms of load-time computability...
> 
> Taking __2M_rwdata_end as an example.  Attempting to use it in
> the PE/COFF optional header in C looks something like:
> 
> extern const char __2M_rwdata_end[];
> extern const char efi_pe_head_end[];
> 
> struct optional_header optional_header = {
> ...
>     .code_size = (uint32_t)((unsigned long)&__2M_rwdata_end) -
>                     (uint32_t)((unsigned long)&efi_pe_head_end,
> ...
> }
> 
> GCC throws "error: initializer element is not constant" because casting
> a 64-bit address to a 32-bit value is not a legal constant expression
> for static storage class objects, even though we know that in practice
> the address wouldn't ever be above 4GB.
> 
> efi_pe_head_end could potentially be calculated by header struct sizes,
> but doing that predictably yields the same error.
> 
> If we drop the explicit casting, GCC throws 'error: initializer element
> is not computable at load time'.

Ah yes, I see now, and I'm aware of the compiler shortcoming.
Even with the not really necessary uint32_t casts dropped the
problem would still be there. So for your description this
means it's not "required addresses only available at link time"
but "required differences of addresses not computable or
expressable at compile time".

Jan

> tl;dr:
> 
> I could not find a way to derive code size (data sections and all)
> without using a symbol location, which is an illegal constant expression
> operand for initializing static storage class objects... and I could not
> find a way to define the header in C without using an object of static
> storage class (global variable or static variable).
> 
> -Bob
> 



  reply	other threads:[~2021-01-25  8:53 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-22  0:51 [PATCH v3 0/5] Support Secure Boot for multiboot2 Xen Bobby Eshleman
2021-01-22  0:51 ` [PATCH v3 1/5] xen: add XEN_BUILD_POSIX_TIME Bobby Eshleman
2021-01-22 11:27   ` Jan Beulich
2021-01-22 21:57     ` Bobby Eshleman
2021-01-25  8:58       ` Jan Beulich
2021-01-22  0:51 ` [PATCH v3 2/5] xen/x86: manually build xen.mb.efi binary Bobby Eshleman
2021-03-15 13:36   ` Jan Beulich
2021-05-07 20:26     ` Bob Eshleman
2021-05-17  6:48       ` Jan Beulich
2021-05-17 13:20         ` Daniel Kiper
2021-05-17 13:24           ` Jan Beulich
2021-05-18 17:46             ` Daniel Kiper
2021-05-19  9:29               ` Jan Beulich
2021-05-19 12:48                 ` Daniel Kiper
2021-05-19 14:35                   ` Jan Beulich
2021-06-09 13:18                     ` Daniel Kiper
2021-06-09 13:45                       ` Jan Beulich
2021-01-22  0:51 ` [PATCH v3 3/5] xen/x86: add some addresses to the Multiboot header Bobby Eshleman
2021-03-15 15:05   ` Jan Beulich
2021-01-22  0:51 ` [PATCH v3 4/5] xen/x86: add some addresses to the Multiboot2 header Bobby Eshleman
2021-02-23  9:04   ` Roger Pau Monné
2021-02-23 18:07     ` Bob Eshleman
2021-01-22  0:51 ` [PATCH v3 5/5] xen/x86/efi: Verify dom0 kernel with SHIM_LOCK protocol in efi_multiboot2() Bobby Eshleman
2021-03-16 15:08   ` Jan Beulich
2021-01-22  9:39 ` [PATCH v3 0/5] Support Secure Boot for multiboot2 Xen Jan Beulich
2021-01-22 21:18   ` Bobby Eshleman
2021-01-25  8:52     ` Jan Beulich [this message]
2021-02-22 18:04 ` Bobby Eshleman
2021-02-23  7:16   ` Jan Beulich
2021-02-23 18:00     ` Bob Eshleman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5e5e4b26-d956-976d-f076-27eb0f8f479c@suse.com \
    --to=jbeulich@suse.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=bobbyeshleman@gmail.com \
    --cc=daniel.kiper@oracle.com \
    --cc=george.dunlap@citrix.com \
    --cc=iwj@xenproject.org \
    --cc=julien@xen.org \
    --cc=olivier.lambert@vates.fr \
    --cc=sstabellini@kernel.org \
    --cc=wl@xen.org \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).