All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jan Beulich <jbeulich@suse.com>
To: Frediano Ziglio <frediano.ziglio@cloud.com>
Cc: "Alejandro Vallejo" <alejandro.vallejo@cloud.com>,
	"Andrew Cooper" <andrew.cooper3@citrix.com>,
	"Roger Pau Monné" <roger.pau@citrix.com>,
	Xen-devel <xen-devel@lists.xenproject.org>
Subject: Re: [PATCH 1/5] x86: Put trampoline in .init.data section
Date: Tue, 27 Aug 2024 17:55:28 +0200	[thread overview]
Message-ID: <773b4710-46c4-4bc3-bf53-623bf666cfe8@suse.com> (raw)
In-Reply-To: <CACHz=ZhuFgTjbGJp-prENbPAM03SoGJ-=+8M1az_TZ3vsG2TEA@mail.gmail.com>

On 27.08.2024 16:56, Frediano Ziglio wrote:
> On Mon, Aug 19, 2024 at 4:50 PM Jan Beulich <jbeulich@suse.com> wrote:
>>
>> On 19.08.2024 17:30, Frediano Ziglio wrote:
>>> On Mon, Aug 19, 2024 at 3:30 PM Jan Beulich <jbeulich@suse.com> wrote:
>>>> On 19.08.2024 16:16, Frediano Ziglio wrote:
>>>>> Could I ouput the trampoline in a code section ("ax" instead of "aw")
>>>>> and then later move it into .init.data section assuring .init.data is
>>>>> writeable but not executable?
>>>>
>>>> Could you go into a little more detail on what you mean here? At the
>>>> first glance my reaction is "yes, sure, why not", but much depends on
>>>> what exactly is meant.
>>>
>>> For instance you could put the trampoline into a
>>>     .section .init.trampoline, "awx", @progbits
>>> section (having the "x" will be disassembled by objdump -d head.o).
>>> Then in xen/arch/x86/xen.lds.S in the .init.data section having something like
>>> ...
>>>   DECL_SECTION(.init.data) {
>>>        *(.init.bss.stack_aligned)
>>>       (.init.trampoline)
>>>    ...
>>> this will put the trampoline in .init.data section of the final
>>> object. At this point the .init.data containing code will have execute
>>> permission that you would have to fix using objcopy command.
>>> The final trampoline will be in a data section not executable so to
>>> use objdump you will need the -D option, but not disassembling head.o.
>>> In theory we could keep the temporary object file before the objcopy
>>> adjustment to avoid the -D but I don't think it would save a lot of
>>> burdain.
>>
>> Part of my "want to be able to disassemble" also applies to the final
>> binaries. Since iirc one can disassemble individual sections, an option
>> may be to have .trampoline be its own section even in the final (PE)
>> binary?
>>
>> In any event, especially as long as there is no really good option, I
>> think I'd like to have input from Andrew and/or Roger as well.
> 
> what about having an extra copy in .init.data. That is, compile the
> trampoline in .init.text having it readable/executable in the final
> PE, at the beginning copying into .init.data and handle the changes
> there then when we can allocate the final memory allocate it and copy
> the temporary writable copy into final lower memory area.

I dislike such duplication, and I'd fear it may cause more confusion
than to actually help. Plus you'd need to sort the symbol name clashes.

> On a related but not too much topic, I noted there's no .init.bss.
> Maybe we could allocate .init.bss (and .init.bss.stack_aligned or
> whatever .init.bss.*) at the end of normal .bss and "cut" it while we
> remove .init.text and .init.data.

How would anything (in C) use .init.bss? __attribute__((section(...)))
doesn't make @nobits sections (last I checked), and .init.bss that's
@progbits is not really different from .init.data.

Jan


  reply	other threads:[~2024-08-27 15:55 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-08-07 13:48 [PATCH 0/5] Improve support for EFI multiboot loading Alejandro Vallejo
2024-08-07 13:48 ` [PATCH 1/5] x86: Put trampoline in .init.data section Alejandro Vallejo
2024-08-08  7:34   ` Jan Beulich
     [not found]     ` <CACHz=Zh7wK58mbB762fnevHEKW9qhp-NRJ6buNe1b-qLxP0qPg@mail.gmail.com>
     [not found]       ` <b9b40658-ff13-4240-98a2-4811411e31b6@suse.com>
2024-08-08 13:05         ` Frediano Ziglio
2024-08-19 14:16         ` Frediano Ziglio
2024-08-19 14:29           ` Jan Beulich
2024-08-19 15:30             ` Frediano Ziglio
2024-08-19 15:50               ` Jan Beulich
2024-08-27 14:56                 ` Frediano Ziglio
2024-08-27 15:55                   ` Jan Beulich [this message]
2024-08-07 13:48 ` [PATCH 2/5] x86: Fix early output messages in case of EFI Alejandro Vallejo
2024-08-08  7:49   ` Jan Beulich
     [not found]     ` <CACHz=ZjYdBcB_S1tpXpuRQDKGAKY=SrgTEy8_0Wyq_q+bOBfHg@mail.gmail.com>
2024-08-08  9:29       ` Jan Beulich
     [not found]         ` <CACHz=ZgRK2DMHmiAVsBo1WJVBxbnTka3-CcpgopKB-6gWs5ZSw@mail.gmail.com>
2024-08-08 12:58           ` Jan Beulich
2024-08-08 13:17             ` Frediano Ziglio
2024-08-08 14:04               ` Jan Beulich
2024-08-07 13:48 ` [PATCH 3/5] x86: Set xen_phys_start and trampoline_xen_phys_start earlier Alejandro Vallejo
2024-08-08  8:25   ` Jan Beulich
2024-08-09 12:48     ` Frediano Ziglio
2024-08-09 12:59       ` Jan Beulich
2024-08-09 13:50         ` Frediano Ziglio
2024-08-09 14:02           ` Jan Beulich
2024-08-09 14:34             ` Frediano Ziglio
2024-08-12  8:41               ` Jan Beulich
2024-08-12 12:42                 ` Frediano Ziglio
2024-08-07 13:48 ` [PATCH 4/5] x86: Force proper gdt_boot_base setting Alejandro Vallejo
2024-08-08  9:58   ` Jan Beulich
2024-08-07 13:48 ` [PATCH 5/5] x86: Rollback relocation in case of EFI multiboot Alejandro Vallejo
2024-08-08 10:36   ` Jan Beulich

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=773b4710-46c4-4bc3-bf53-623bf666cfe8@suse.com \
    --to=jbeulich@suse.com \
    --cc=alejandro.vallejo@cloud.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=frediano.ziglio@cloud.com \
    --cc=roger.pau@citrix.com \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.