Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

specifying alignment of loader files

0 views
Skip to first unread message

Mark Johnston

unread,
Jun 12, 2018, 1:08:15 PM6/12/18
to
Hi,

I'm writing some code which processes a file loaded by the loader. I
want the file's contents to be available at a certain alignment in
memory, and as far as I can see, the loader provides no alignment
guarantees today. The access will happen early enough during boot that
making an aligned copy of the data will be awkward, so I'd like the
loader to provide the desired alignment.

I'm considering adding a new "module_align" variable that would specify
the alignment for a given file type, and plumb that through to
command_load(). Does anyone have an alternate suggestion, or an
objection to my proposal?
_______________________________________________
freebsd...@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hacke...@freebsd.org"

Warner Losh

unread,
Jun 12, 2018, 1:14:47 PM6/12/18
to
On Tue, Jun 12, 2018 at 11:04 AM, Mark Johnston <ma...@freebsd.org> wrote:

> Hi,
>
> I'm writing some code which processes a file loaded by the loader. I
> want the file's contents to be available at a certain alignment in
> memory, and as far as I can see, the loader provides no alignment
> guarantees today. The access will happen early enough during boot that
> making an aligned copy of the data will be awkward, so I'd like the
> loader to provide the desired alignment.
>
> I'm considering adding a new "module_align" variable that would specify
> the alignment for a given file type, and plumb that through to
> command_load(). Does anyone have an alternate suggestion, or an
> objection to my proposal?
>

I thought the loader already did that for ELF sections... Why not wrap your
file in such a segment?

Warner

Mark Johnston

unread,
Jun 12, 2018, 1:20:58 PM6/12/18
to
On Tue, Jun 12, 2018 at 11:11:25AM -0600, Warner Losh wrote:
> On Tue, Jun 12, 2018 at 11:04 AM, Mark Johnston <ma...@freebsd.org> wrote:
>
> > Hi,
> >
> > I'm writing some code which processes a file loaded by the loader. I
> > want the file's contents to be available at a certain alignment in
> > memory, and as far as I can see, the loader provides no alignment
> > guarantees today. The access will happen early enough during boot that
> > making an aligned copy of the data will be awkward, so I'd like the
> > loader to provide the desired alignment.
> >
> > I'm considering adding a new "module_align" variable that would specify
> > the alignment for a given file type, and plumb that through to
> > command_load(). Does anyone have an alternate suggestion, or an
> > objection to my proposal?
> >
>
> I thought the loader already did that for ELF sections... Why not wrap your
> file in such a segment?

In this case it's a raw binary file (CPU microcode), and I want to be
able to load it without any modifications or wrappers.

Warner Losh

unread,
Jun 12, 2018, 1:48:38 PM6/12/18
to
On Tue, Jun 12, 2018 at 11:16 AM, Mark Johnston <ma...@freebsd.org> wrote:

> On Tue, Jun 12, 2018 at 11:11:25AM -0600, Warner Losh wrote:
> > On Tue, Jun 12, 2018 at 11:04 AM, Mark Johnston <ma...@freebsd.org>
> wrote:
> >
> > > Hi,
> > >
> > > I'm writing some code which processes a file loaded by the loader. I
> > > want the file's contents to be available at a certain alignment in
> > > memory, and as far as I can see, the loader provides no alignment
> > > guarantees today. The access will happen early enough during boot that
> > > making an aligned copy of the data will be awkward, so I'd like the
> > > loader to provide the desired alignment.
> > >
> > > I'm considering adding a new "module_align" variable that would specify
> > > the alignment for a given file type, and plumb that through to
> > > command_load(). Does anyone have an alternate suggestion, or an
> > > objection to my proposal?
> > >
> >
> > I thought the loader already did that for ELF sections... Why not wrap
> your
> > file in such a segment?
>
> In this case it's a raw binary file (CPU microcode), and I want to be
> able to load it without any modifications or wrappers.
>

How do you identify the type then? I'm ok in theory with this (though a
variable is more flexible than needed), but that's my main concern. What's
the alignment required btw?

Warner

Mark Johnston

unread,
Jun 12, 2018, 1:55:26 PM6/12/18
to
On Tue, Jun 12, 2018 at 11:45:01AM -0600, Warner Losh wrote:
> On Tue, Jun 12, 2018 at 11:16 AM, Mark Johnston <ma...@freebsd.org> wrote:
>
> > On Tue, Jun 12, 2018 at 11:11:25AM -0600, Warner Losh wrote:
> > > On Tue, Jun 12, 2018 at 11:04 AM, Mark Johnston <ma...@freebsd.org>
> > wrote:
> > >
> > > > Hi,
> > > >
> > > > I'm writing some code which processes a file loaded by the loader. I
> > > > want the file's contents to be available at a certain alignment in
> > > > memory, and as far as I can see, the loader provides no alignment
> > > > guarantees today. The access will happen early enough during boot that
> > > > making an aligned copy of the data will be awkward, so I'd like the
> > > > loader to provide the desired alignment.
> > > >
> > > > I'm considering adding a new "module_align" variable that would specify
> > > > the alignment for a given file type, and plumb that through to
> > > > command_load(). Does anyone have an alternate suggestion, or an
> > > > objection to my proposal?
> > > >
> > >
> > > I thought the loader already did that for ELF sections... Why not wrap
> > your
> > > file in such a segment?
> >
> > In this case it's a raw binary file (CPU microcode), and I want to be
> > able to load it without any modifications or wrappers.
> >
>
> How do you identify the type then? I'm ok in theory with this (though a
> variable is more flexible than needed), but that's my main concern. What's
> the alignment required btw?

It'd be a property of the type, e.g.,

cpu_ucode_name=/boot/firmware/...
cpu_ucode_align=16

I do feel like having a separate variable is overkill, but I can't see
a less invasive solution that isn't hacky.

The required alignment for Intel is 16 bytes; I'm not yet sure whether
AMD has a required alignment.

Warner Losh

unread,
Jun 12, 2018, 1:59:24 PM6/12/18
to
OK. That seems sane. I was thinking it was more general than this, but I'm
cool with what you've outlined.

OTOH, wouldn't just loading all files on page boundaries suffice?

Warner

Kyle Evans

unread,
Jun 12, 2018, 2:04:14 PM6/12/18
to
If the answer to the above isn't "yes," can we consider making this a
flag to `load` parsed in command_load instead of its own
${module}_align variable? e.g.

cpu_ucode_name=/boot/firmware/...
cpu_ucode_flags="-a 16"

The initial recommendation isn't a bad idea,
but adding a new ${module}_flags requires changes in both interpreters
that I'm not sure are strictly necessary when this will be relatively
rarely used.

Thanks,

Kyle Evans

Kyle Evans

unread,
Jun 12, 2018, 2:05:04 PM6/12/18
to
Sorry, that ${module}_flags should read ${module}_align.

Mark Johnston

unread,
Jun 12, 2018, 2:09:20 PM6/12/18
to
It would (and that's actually what I did in my test branch). We
already have to do this for ELF, and the only other frequently loaded
file I can think of is /boot/entropy. Can you think of any scenarios
where forcing page alignment for all files would waste a substantial
amount of memory? If not, I might just go ahead with that approach for
now and wait for a good reason before introducing customizable
alignments.

Mark Johnston

unread,
Jun 12, 2018, 2:13:40 PM6/12/18
to
Oh, I didn't realize those flags get passed straight to command_load().
I think that's a better idea than what I suggested. I started this
thread when I realized that I would need to write some Forth code to
implement my idea. :)

Brooks Davis

unread,
Jun 12, 2018, 2:13:46 PM6/12/18
to
Page boundaries might be too much on very small systems, but there's
a principled argument for 8-bytes just based on the aligment of
primative types so 16 (or even 64) isn't much of a stretch. 16-bytes
would future-proof for the CHERI variants that are likely to make
it to silicon.

-- Brooks
signature.asc

Ben Widawsky

unread,
Jun 12, 2018, 2:17:54 PM6/12/18
to
I think native cacheline size is a pretty safe yet more conservative than page
size bet ie. me too for 64.

Ian Lepore

unread,
Jun 13, 2018, 12:30:02 PM6/13/18
to
On Tue, 2018-06-12 at 14:05 -0400, Mark Johnston wrote:
> On Tue, Jun 12, 2018 at 11:55:27AM -0600, Warner Losh wrote:
> >
> > On Tue, Jun 12, 2018 at 11:51 AM, Mark Johnston <ma...@freebsd.org>
> > wrote:
> >
> > >
> > > On Tue, Jun 12, 2018 at 11:45:01AM -0600, Warner Losh wrote:
> > > >
> > > > On Tue, Jun 12, 2018 at 11:16 AM, Mark Johnston <markj@freebsd.
> > > > org>
> > > wrote:
> > > >
> > > >
> > > > >
> > > > > On Tue, Jun 12, 2018 at 11:11:25AM -0600, Warner Losh wrote:
> > > > > >
> > > > > > On Tue, Jun 12, 2018 at 11:04 AM, Mark Johnston <markj@free
There is already an arch_loadaddr() method in the archsw which is used
to align every loaded module/file/whatever. I think not all arches
implement it, but they probably should, and each arch should probably
use the biggest possible cacheline size for that arch as the minimum
alignment. For some arches, page boundaries might make sense.  A nice
example is the beri implementation which does this:

  /* Align ELF objects at page boundaries; others at cache lines. */
  align = (type == LOAD_ELF) ? PAGE_SIZE : CACHE_LINE_SIZE;
  return (roundup2(addr, align));

For a nice description of how the function is intended to work, see the
comment block above uboot_loadaddr() in stand/uboot/lib/copy.c.

-- Ian
0 new messages