Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1370841 > unrolled thread

Re: [kernel-hardening] [PATCH v2 00/11] MIPS relocatable kernel & KASLR

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [kernel-hardening] [PATCH v2 00/11] MIPS relocatable kernel & KASLR Kees Cook <keescook@chromium.org> - 2016-04-04 21:50 +0200
    Re: [kernel-hardening] [PATCH v2 00/11] MIPS relocatable kernel &  KASLR Ralf Baechle <ralf@linux-mips.org> - 2016-04-05 01:40 +0200
      Re: [kernel-hardening] [PATCH v2 00/11] MIPS relocatable kernel & KASLR Kees Cook <keescook@chromium.org> - 2016-04-05 02:00 +0200
        Re: [kernel-hardening] [PATCH v2 00/11] MIPS relocatable kernel &  KASLR James Hogan <james.hogan@imgtec.com> - 2016-04-05 11:10 +0200
          Re: [kernel-hardening] [PATCH v2 00/11] MIPS relocatable kernel & KASLR Kees Cook <keescook@chromium.org> - 2016-04-05 20:20 +0200
            Re: [kernel-hardening] [PATCH v2 00/11] MIPS relocatable kernel &  KASLR James Hogan <james.hogan@imgtec.com> - 2016-04-05 23:10 +0200
      Re: [kernel-hardening] [PATCH v2 00/11] MIPS relocatable kernel &  KASLR "Maciej W. Rozycki" <macro@imgtec.com> - 2016-04-05 14:20 +0200

#1370841 — Re: [kernel-hardening] [PATCH v2 00/11] MIPS relocatable kernel & KASLR

On Thu, Mar 31, 2016 at 2:05 AM, Matt Redfearn <matt.redfearn@imgtec.com> wrote:
>
> This series adds the ability for the MIPS kernel to relocate itself at
> runtime, optionally to an address determined at random each boot. This
> series is based on v4.4 and has been tested on the Malta, Boston and
> SEAD3 platforms.
>
> Here is a description of how relocation is achieved:
> * Kernel is compiled & statically linked as normal, with no position
>   independent code. MIPS before R6 only has limited relative jump
>   instructions so the vast majority of jumps are absolute. To compile
>   the kernel position independent would introduce a highly undesireable
>   overhead. Relocating the static binary gives a small startup time
>   penalty but the kernel otherwise perforns normally.
> * The linker flag --emit-relocs is added to the linker command line,
>   causing ld to include relocation sections in the output elf
> * A tool derived from the x86 relocs tool is used to parse the
>   relocation sections and create a binary table of relocations. Each
>   entry in the table is 32bits, comprised of a 24bit offset (in words)
>   from _text and an 8bit relocation type.
> * The table is inserted into the vmlinux elf, into some space reserved
>   for it in the linker script. Inserting the table into vmlinux means
>   all boot targets will automatically include the relocation code and
>   information.
> * At boot, the kernel memcpy()s itself elsewhere in memory, then goes
>   through the table performing each relocation on the new image.
> * If all goes well, control is passed to the entry point of the new
>   kernel.

This is great! Thanks for working on this! :)

Without actually reading the code yet, I wonder if the x86 and MIPS
relocs tool could be merged at all? Sounds like it might be more
difficult though -- the relocation output is different and its storage
location is different...

> Restrictions:
> * The new kernel is not allowed to overlap the old kernel, such that
>   the original kernel can still be booted if relocation fails.

This sounds like physical-only relocation then? Is the virtual offset
randomized as well (like arm64) or just physical (like x86 currently
-- though there is a series to fix this).

> * Relocation is supported only by multiples of 64k bytes. This
>   eliminates the need to handle R_MIPS_LO16 relocations as the bottom
>   16bits will remain the same at the relocated address.

IIUC, that's actually better than x86, which needs to be 2MB aligned.

> * In 64 bit kernels, relocation is supported only within the same 4Gb
>   memory segment as the kernel link address (CONFIG_PHYSICAL_START).
>   This eliminates the need to handle R_MIPS_HIGHEST and R_MIPS_HIGHER
>   relocations as the top 32bits will remain the same at the relocated
>   address.

Interesting. Could the relocation code be updated in the future to
bump the high addresses too?

> Changes in v2:
> - Added support  for MIPSr6
> - Accept the "nokaslr" command line option
> - Add a kernel panic notifier to print the relocation information
> - Accept entropy via the /chosen/kaslr-seed property in device tree
> - Tested on MIPS Malta, Boston and SEAD3 platforms
>
> Matt Redfearn (11):
>   MIPS: tools: Add relocs tool
>   MIPS: tools: Build relocs tool
>   MIPS: Reserve space for relocation table
>   MIPS: Generate relocation table when CONFIG_RELOCATABLE
>   MIPS: Kernel: Add relocate.c
>   MIPS: Call relocate_kernel if CONFIG_RELOCATABLE=y
>   MIPS: bootmem: When relocatable, free memory below kernel
>   MIPS: Add CONFIG_RELOCATABLE Kconfig option
>   MIPS: Introduce plat_get_fdt a platform API to retrieve the FDT
>   MIPS: Kernel: Implement KASLR using CONFIG_RELOCATABLE
>   MIPS: KASLR: Print relocation Information on boot
>
>  arch/mips/Kconfig                  |  64 ++++
>  arch/mips/Makefile                 |  19 ++
>  arch/mips/boot/tools/Makefile      |   8 +
>  arch/mips/boot/tools/relocs.c      | 680 +++++++++++++++++++++++++++++++++++++
>  arch/mips/boot/tools/relocs.h      |  45 +++
>  arch/mips/boot/tools/relocs_32.c   |  17 +
>  arch/mips/boot/tools/relocs_64.c   |  27 ++
>  arch/mips/boot/tools/relocs_main.c |  84 +++++
>  arch/mips/include/asm/bootinfo.h   |  18 +
>  arch/mips/kernel/Makefile          |   2 +
>  arch/mips/kernel/head.S            |  20 ++
>  arch/mips/kernel/relocate.c        | 386 +++++++++++++++++++++
>  arch/mips/kernel/setup.c           |  23 ++
>  arch/mips/kernel/vmlinux.lds.S     |  21 ++
>  arch/mips/mti-malta/malta-setup.c  |   7 +-
>  arch/mips/mti-sead3/sead3-setup.c  |   5 +
>  16 files changed, 1425 insertions(+), 1 deletion(-)
>  create mode 100644 arch/mips/boot/tools/Makefile
>  create mode 100644 arch/mips/boot/tools/relocs.c
>  create mode 100644 arch/mips/boot/tools/relocs.h
>  create mode 100644 arch/mips/boot/tools/relocs_32.c
>  create mode 100644 arch/mips/boot/tools/relocs_64.c
>  create mode 100644 arch/mips/boot/tools/relocs_main.c
>  create mode 100644 arch/mips/kernel/relocate.c
>
> --
> 2.5.0
>

-Kees

-- 
Kees Cook
Chrome OS & Brillo Security

[toc] | [next] | [standalone]

#1370969 — Re: [kernel-hardening] [PATCH v2 00/11] MIPS relocatable kernel & KASLR

On Mon, Apr 04, 2016 at 12:46:29PM -0700, Kees Cook wrote:

> This is great! Thanks for working on this! :)
> 
> Without actually reading the code yet, I wonder if the x86 and MIPS
> relocs tool could be merged at all? Sounds like it might be more
> difficult though -- the relocation output is different and its storage
> location is different...
> 
> > Restrictions:
> > * The new kernel is not allowed to overlap the old kernel, such that
> >   the original kernel can still be booted if relocation fails.
> 
> This sounds like physical-only relocation then? Is the virtual offset
> randomized as well (like arm64) or just physical (like x86 currently
> -- though there is a series to fix this).

On MIPS we normally place the kernel in KSEG0 or XKPHYS which address
segments which are not mapped through the TLB so the difference is
kinda moot.

> > * Relocation is supported only by multiples of 64k bytes. This
> >   eliminates the need to handle R_MIPS_LO16 relocations as the bottom
> >   16bits will remain the same at the relocated address.
> 
> IIUC, that's actually better than x86, which needs to be 2MB aligned.

On MIPS a key concern was maintaining a reasonable size for the final
kernel image.  The R_MIPS_LO16 relocatio records make a significant
portion of the relocations in a relocatable .o file, so we wanted to
get rid of them.  This results in a relocation granularity of 64kB.
If we were truely, truely stingy we could come up with a relocation format
to save a few more bits but I doubt that'd make any sense.

> > * In 64 bit kernels, relocation is supported only within the same 4Gb
> >   memory segment as the kernel link address (CONFIG_PHYSICAL_START).
> >   This eliminates the need to handle R_MIPS_HIGHEST and R_MIPS_HIGHER
> >   relocations as the top 32bits will remain the same at the relocated
> >   address.
> 
> Interesting. Could the relocation code be updated in the future to
> bump the high addresses too?

It could but yet again, the idea was to keep the size of the final
generated file under control.  The R_MIPS_HIGHER and R_MIPS_HIGHEST
relocations can be discarded if we constrain the addresses to be in
a single 4GB segment.  Removing this constraint would make a kernel
image much bigger so I suggested to add this restriction at least for
this initial version.

  Ralf

[toc] | [prev] | [next] | [standalone]

#1371057

On Mon, Apr 4, 2016 at 4:37 PM, Ralf Baechle <ralf@linux-mips.org> wrote:
> On Mon, Apr 04, 2016 at 12:46:29PM -0700, Kees Cook wrote:
>
>> This is great! Thanks for working on this! :)
>>
>> Without actually reading the code yet, I wonder if the x86 and MIPS
>> relocs tool could be merged at all? Sounds like it might be more
>> difficult though -- the relocation output is different and its storage
>> location is different...
>>
>> > Restrictions:
>> > * The new kernel is not allowed to overlap the old kernel, such that
>> >   the original kernel can still be booted if relocation fails.
>>
>> This sounds like physical-only relocation then? Is the virtual offset
>> randomized as well (like arm64) or just physical (like x86 currently
>> -- though there is a series to fix this).
>
> On MIPS we normally place the kernel in KSEG0 or XKPHYS which address
> segments which are not mapped through the TLB so the difference is
> kinda moot.

Ah-ha, excellent. Does this mean that MIPS is effectively doing memory
segmentation between userspace and kernel space (or some version of
x86's SMEP/SMAP or ARM's PXN/PAN)? I don't know much about the MIPS
architecture yet.

What do I need to fill in on these tables for MIPS?

http://kernsec.org/wiki/index.php/Exploit_Methods/Userspace_execution
http://kernsec.org/wiki/index.php/Exploit_Methods/Userspace_data_usage

>
>> > * Relocation is supported only by multiples of 64k bytes. This
>> >   eliminates the need to handle R_MIPS_LO16 relocations as the bottom
>> >   16bits will remain the same at the relocated address.
>>
>> IIUC, that's actually better than x86, which needs to be 2MB aligned.
>
> On MIPS a key concern was maintaining a reasonable size for the final
> kernel image.  The R_MIPS_LO16 relocatio records make a significant
> portion of the relocations in a relocatable .o file, so we wanted to
> get rid of them.  This results in a relocation granularity of 64kB.
> If we were truely, truely stingy we could come up with a relocation format
> to save a few more bits but I doubt that'd make any sense.
>
>> > * In 64 bit kernels, relocation is supported only within the same 4Gb
>> >   memory segment as the kernel link address (CONFIG_PHYSICAL_START).
>> >   This eliminates the need to handle R_MIPS_HIGHEST and R_MIPS_HIGHER
>> >   relocations as the top 32bits will remain the same at the relocated
>> >   address.
>>
>> Interesting. Could the relocation code be updated in the future to
>> bump the high addresses too?
>
> It could but yet again, the idea was to keep the size of the final
> generated file under control.  The R_MIPS_HIGHER and R_MIPS_HIGHEST
> relocations can be discarded if we constrain the addresses to be in
> a single 4GB segment.  Removing this constraint would make a kernel
> image much bigger so I suggested to add this restriction at least for
> this initial version.

Awesome, thanks for the details.

-Kees

-- 
Kees Cook
Chrome OS & Brillo Security

[toc] | [prev] | [next] | [standalone]

#1371337 — Re: [kernel-hardening] [PATCH v2 00/11] MIPS relocatable kernel & KASLR

[Multipart message — attachments visible in raw view] — view raw

On Mon, Apr 04, 2016 at 04:56:58PM -0700, Kees Cook wrote:
> On Mon, Apr 4, 2016 at 4:37 PM, Ralf Baechle <ralf@linux-mips.org> wrote:
> > On Mon, Apr 04, 2016 at 12:46:29PM -0700, Kees Cook wrote:
> >
> >> This is great! Thanks for working on this! :)
> >>
> >> Without actually reading the code yet, I wonder if the x86 and MIPS
> >> relocs tool could be merged at all? Sounds like it might be more
> >> difficult though -- the relocation output is different and its storage
> >> location is different...
> >>
> >> > Restrictions:
> >> > * The new kernel is not allowed to overlap the old kernel, such that
> >> >   the original kernel can still be booted if relocation fails.
> >>
> >> This sounds like physical-only relocation then? Is the virtual offset
> >> randomized as well (like arm64) or just physical (like x86 currently
> >> -- though there is a series to fix this).
> >
> > On MIPS we normally place the kernel in KSEG0 or XKPHYS which address
> > segments which are not mapped through the TLB so the difference is
> > kinda moot.
> 
> Ah-ha, excellent. Does this mean that MIPS is effectively doing memory
> segmentation between userspace and kernel space (or some version of
> x86's SMEP/SMAP or ARM's PXN/PAN)? I don't know much about the MIPS
> architecture yet.

User and kernel virtual address spaces don't traditionally overlap, so
you don't get that sort of protection at the moment.

MIPS TLBs do have ASIDs though, and kernel mappings are marked global,
so it could easily reserve an ASID with no mappings, and switch to that
while in kernel mode. It'd have to keep switching between them when
reading/writing userland though, as you can't directly access another
ASID, and I don't think thats a particularly cheap operation, especially
on cores with hardware page table walkers.

EVA (enhanced virtual addressing) is a feature present on recent MIPS
32-bit i-class and p-class cores (and p6600 too which is 64-bit),
intended to make better use of 32-bit virtual address space. It can
actually overlap kernel and virtual address space, requiring special
instructions for accessing userland mappings, however each segment can't
have distinct TLB mappings for kernel and user mode (if kernel and user
view of segment differs, kernel would need to see it unmapped, i.e. a
window into physical memory). As such its generally better to keep the
lowest segment visible to both kernel and user, so that kernel NULL
dereferences can still be caught, which would negate the point of using
it for security. It is possible to make it work with watchpoints to
catch NULL dereferences in lowest 4KB, so kernel can't access any user
address space directly, but thats a bit of a hack really. Also since EVA
is aimed at making better use of 32-bit address space, it doesn't
address 64-bit.

> 
> What do I need to fill in on these tables for MIPS?
> 
> http://kernsec.org/wiki/index.php/Exploit_Methods/Userspace_execution
> http://kernsec.org/wiki/index.php/Exploit_Methods/Userspace_data_usage

Both are best addressed using ASID switching in my opinion at the
moment.

Cheers
James

> 
> >
> >> > * Relocation is supported only by multiples of 64k bytes. This
> >> >   eliminates the need to handle R_MIPS_LO16 relocations as the bottom
> >> >   16bits will remain the same at the relocated address.
> >>
> >> IIUC, that's actually better than x86, which needs to be 2MB aligned.
> >
> > On MIPS a key concern was maintaining a reasonable size for the final
> > kernel image.  The R_MIPS_LO16 relocatio records make a significant
> > portion of the relocations in a relocatable .o file, so we wanted to
> > get rid of them.  This results in a relocation granularity of 64kB.
> > If we were truely, truely stingy we could come up with a relocation format
> > to save a few more bits but I doubt that'd make any sense.
> >
> >> > * In 64 bit kernels, relocation is supported only within the same 4Gb
> >> >   memory segment as the kernel link address (CONFIG_PHYSICAL_START).
> >> >   This eliminates the need to handle R_MIPS_HIGHEST and R_MIPS_HIGHER
> >> >   relocations as the top 32bits will remain the same at the relocated
> >> >   address.
> >>
> >> Interesting. Could the relocation code be updated in the future to
> >> bump the high addresses too?
> >
> > It could but yet again, the idea was to keep the size of the final
> > generated file under control.  The R_MIPS_HIGHER and R_MIPS_HIGHEST
> > relocations can be discarded if we constrain the addresses to be in
> > a single 4GB segment.  Removing this constraint would make a kernel
> > image much bigger so I suggested to add this restriction at least for
> > this initial version.
> 
> Awesome, thanks for the details.
> 
> -Kees
> 
> -- 
> Kees Cook
> Chrome OS & Brillo Security

[toc] | [prev] | [next] | [standalone]

#1371859

On Tue, Apr 5, 2016 at 2:09 AM, James Hogan <james.hogan@imgtec.com> wrote:
> On Mon, Apr 04, 2016 at 04:56:58PM -0700, Kees Cook wrote:
>> On Mon, Apr 4, 2016 at 4:37 PM, Ralf Baechle <ralf@linux-mips.org> wrote:
>> > On Mon, Apr 04, 2016 at 12:46:29PM -0700, Kees Cook wrote:
>> >
>> >> This is great! Thanks for working on this! :)
>> >>
>> >> Without actually reading the code yet, I wonder if the x86 and MIPS
>> >> relocs tool could be merged at all? Sounds like it might be more
>> >> difficult though -- the relocation output is different and its storage
>> >> location is different...
>> >>
>> >> > Restrictions:
>> >> > * The new kernel is not allowed to overlap the old kernel, such that
>> >> >   the original kernel can still be booted if relocation fails.
>> >>
>> >> This sounds like physical-only relocation then? Is the virtual offset
>> >> randomized as well (like arm64) or just physical (like x86 currently
>> >> -- though there is a series to fix this).
>> >
>> > On MIPS we normally place the kernel in KSEG0 or XKPHYS which address
>> > segments which are not mapped through the TLB so the difference is
>> > kinda moot.
>>
>> Ah-ha, excellent. Does this mean that MIPS is effectively doing memory
>> segmentation between userspace and kernel space (or some version of
>> x86's SMEP/SMAP or ARM's PXN/PAN)? I don't know much about the MIPS
>> architecture yet.
>
> User and kernel virtual address spaces don't traditionally overlap, so
> you don't get that sort of protection at the moment.
>
> MIPS TLBs do have ASIDs though, and kernel mappings are marked global,
> so it could easily reserve an ASID with no mappings, and switch to that
> while in kernel mode. It'd have to keep switching between them when
> reading/writing userland though, as you can't directly access another
> ASID, and I don't think thats a particularly cheap operation, especially
> on cores with hardware page table walkers.

Yeah, it seems that x86 SMAP has some performance problems too. I'd be
curious to see how much of a hit it would be to use ASID switching on
MIPS.

> EVA (enhanced virtual addressing) is a feature present on recent MIPS
> 32-bit i-class and p-class cores (and p6600 too which is 64-bit),
> intended to make better use of 32-bit virtual address space. It can
> actually overlap kernel and virtual address space, requiring special
> instructions for accessing userland mappings, however each segment can't
> have distinct TLB mappings for kernel and user mode (if kernel and user
> view of segment differs, kernel would need to see it unmapped, i.e. a
> window into physical memory). As such its generally better to keep the
> lowest segment visible to both kernel and user, so that kernel NULL
> dereferences can still be caught, which would negate the point of using
> it for security. It is possible to make it work with watchpoints to
> catch NULL dereferences in lowest 4KB, so kernel can't access any user
> address space directly, but thats a bit of a hack really. Also since EVA
> is aimed at making better use of 32-bit address space, it doesn't
> address 64-bit.

Ah, so it couldn't cover a 64-bit userspace range? It seems like it
might work for 32-bit if mmap_min_addr sysctl was used to choose the
size of the low-address shared mapping.

>> What do I need to fill in on these tables for MIPS?
>>
>> http://kernsec.org/wiki/index.php/Exploit_Methods/Userspace_execution
>> http://kernsec.org/wiki/index.php/Exploit_Methods/Userspace_data_usage
>
> Both are best addressed using ASID switching in my opinion at the
> moment.

Okay, thanks, I'll make a note.

-Kees

>
> Cheers
> James
>
>>
>> >
>> >> > * Relocation is supported only by multiples of 64k bytes. This
>> >> >   eliminates the need to handle R_MIPS_LO16 relocations as the bottom
>> >> >   16bits will remain the same at the relocated address.
>> >>
>> >> IIUC, that's actually better than x86, which needs to be 2MB aligned.
>> >
>> > On MIPS a key concern was maintaining a reasonable size for the final
>> > kernel image.  The R_MIPS_LO16 relocatio records make a significant
>> > portion of the relocations in a relocatable .o file, so we wanted to
>> > get rid of them.  This results in a relocation granularity of 64kB.
>> > If we were truely, truely stingy we could come up with a relocation format
>> > to save a few more bits but I doubt that'd make any sense.
>> >
>> >> > * In 64 bit kernels, relocation is supported only within the same 4Gb
>> >> >   memory segment as the kernel link address (CONFIG_PHYSICAL_START).
>> >> >   This eliminates the need to handle R_MIPS_HIGHEST and R_MIPS_HIGHER
>> >> >   relocations as the top 32bits will remain the same at the relocated
>> >> >   address.
>> >>
>> >> Interesting. Could the relocation code be updated in the future to
>> >> bump the high addresses too?
>> >
>> > It could but yet again, the idea was to keep the size of the final
>> > generated file under control.  The R_MIPS_HIGHER and R_MIPS_HIGHEST
>> > relocations can be discarded if we constrain the addresses to be in
>> > a single 4GB segment.  Removing this constraint would make a kernel
>> > image much bigger so I suggested to add this restriction at least for
>> > this initial version.
>>
>> Awesome, thanks for the details.
>>
>> -Kees
>>
>> --
>> Kees Cook
>> Chrome OS & Brillo Security



-- 
Kees Cook
Chrome OS & Brillo Security

[toc] | [prev] | [next] | [standalone]

#1371943 — Re: [kernel-hardening] [PATCH v2 00/11] MIPS relocatable kernel & KASLR

[Multipart message — attachments visible in raw view] — view raw

On Tue, Apr 05, 2016 at 11:10:40AM -0700, Kees Cook wrote:
> On Tue, Apr 5, 2016 at 2:09 AM, James Hogan <james.hogan@imgtec.com> wrote:
> > EVA (enhanced virtual addressing) is a feature present on recent MIPS
> > 32-bit i-class and p-class cores (and p6600 too which is 64-bit),
> > intended to make better use of 32-bit virtual address space. It can
> > actually overlap kernel and virtual address space, requiring special
> > instructions for accessing userland mappings, however each segment can't
> > have distinct TLB mappings for kernel and user mode (if kernel and user
> > view of segment differs, kernel would need to see it unmapped, i.e. a
> > window into physical memory). As such its generally better to keep the
> > lowest segment visible to both kernel and user, so that kernel NULL
> > dereferences can still be caught, which would negate the point of using
> > it for security. It is possible to make it work with watchpoints to
> > catch NULL dereferences in lowest 4KB, so kernel can't access any user
> > address space directly, but thats a bit of a hack really. Also since EVA
> > is aimed at making better use of 32-bit address space, it doesn't
> > address 64-bit.
> 
> Ah, so it couldn't cover a 64-bit userspace range?

Correct.

<long version>
OTOH the segments that can be configured by EVA on MIPS64 (specifically
P6600 core) are:

0xffffffffe0000000..0xffffffffffffffff 512MB (normally kernel mapped)
0xffffffffc0000000..0xffffffffdfffffff 512MB (normally kernel mapped)
0xffffffffa0000000..0xffffffffbfffffff 512MB (normally kernel uncached)
0xffffffff80000000..0xffffffff9fffffff 512MB (normally kernel)
...
0x8000000000000000..0xbfffffffffffffff 8 64-bit unmapped segments (kern)
... <- MIPS64 extends user address space here
0x0000000040000000..0x000000007fffffff 1GB (normally user)
0x0000000000000000..0x000000003fffffff 1GB (normally user)

In the middle there, MIPS64 extends userspace from 0x0000000080000000
towards 0x4000000000000000 (depending on number of virtual address bits
implemented), over which there is no segmentation control.
</long version>

Cheers
James

[toc] | [prev] | [next] | [standalone]

#1371497 — Re: [kernel-hardening] [PATCH v2 00/11] MIPS relocatable kernel & KASLR

On Tue, 5 Apr 2016, Ralf Baechle wrote:

> > > * Relocation is supported only by multiples of 64k bytes. This
> > >   eliminates the need to handle R_MIPS_LO16 relocations as the bottom
> > >   16bits will remain the same at the relocated address.
> > 
> > IIUC, that's actually better than x86, which needs to be 2MB aligned.
> 
> On MIPS a key concern was maintaining a reasonable size for the final
> kernel image.  The R_MIPS_LO16 relocatio records make a significant
> portion of the relocations in a relocatable .o file, so we wanted to
> get rid of them.  This results in a relocation granularity of 64kB.
> If we were truely, truely stingy we could come up with a relocation format
> to save a few more bits but I doubt that'd make any sense.

 Additionally, for historical reasons, with 32-bit (o32) ELF images the 
REL relocation format is used making borrow propagation from R_MIPS_LO16 
to its corresponding R_MIPS_HI16 relocation a pain to handle.  It is 
solvable as the static linker does handle it, in particular doing the 
reasonable thing for orphan relocations, but I think it's a complication 
worth avoiding if the cost is so little.

> > > * In 64 bit kernels, relocation is supported only within the same 4Gb
> > >   memory segment as the kernel link address (CONFIG_PHYSICAL_START).
> > >   This eliminates the need to handle R_MIPS_HIGHEST and R_MIPS_HIGHER
> > >   relocations as the top 32bits will remain the same at the relocated
> > >   address.
> > 
> > Interesting. Could the relocation code be updated in the future to
> > bump the high addresses too?
> 
> It could but yet again, the idea was to keep the size of the final
> generated file under control.  The R_MIPS_HIGHER and R_MIPS_HIGHEST
> relocations can be discarded if we constrain the addresses to be in
> a single 4GB segment.  Removing this constraint would make a kernel
> image much bigger so I suggested to add this restriction at least for
> this initial version.

 For the record, with 64-bit ELF images the RELA relocation format is 
used, so there's no such concern about borrows as with 32-bit ones, 
because the whole addend is always readily available and does not have to 
be calculated from parts coming from different relocations.  Consequently 
the handling of R_MIPS_HIGHER and R_MIPS_HIGHEST (and also R_MIPS_HI16 and 
R_MIPS_LO16) relocations in 64-bit ELF images is straightforward if we 
decided to include them.

 I suspect extending the handling to R_MIPS_HIGHER only will suffice all 
use cases for the foreseeable future as I don't expect MIPS systems with 
more than 256TiB of RAM to appear anytime soon.

 FWIW,

  Maciej

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web