From: Ralf Baechle <ralf@linux-mips.org>
To: Kees Cook <keescook@chromium.org>
Cc: "kernel-hardening@lists.openwall.com"
<kernel-hardening@lists.openwall.com>,
Linux MIPS Mailing List <linux-mips@linux-mips.org>,
Matt Redfearn <matt.redfearn@imgtec.com>,
Aaro Koskinen <aaro.koskinen@nokia.com>,
Masahiro Yamada <yamada.masahiro@socionext.com>,
Alexander Sverdlin <alexander.sverdlin@gmail.com>,
LKML <linux-kernel@vger.kernel.org>,
Thomas Gleixner <tglx@linutronix.de>,
David Daney <ddaney@caviumnetworks.com>,
Jaedon Shin <jaedon.shin@gmail.com>,
James Hogan <james.hogan@imgtec.com>,
Jonas Gorski <jogo@openwrt.org>,
Paul Burton <paul.burton@imgtec.com>
Subject: Re: [kernel-hardening] [PATCH v2 00/11] MIPS relocatable kernel & KASLR
Date: Tue, 5 Apr 2016 01:37:21 +0200 [thread overview]
Message-ID: <20160404233721.GB26295@linux-mips.org> (raw)
In-Reply-To: <CAGXu5jKMLcRmMkowF=fUEQdtccTJLR9FEWT4g_zeyZMW4BWQOg@mail.gmail.com>
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
next prev parent reply other threads:[~2016-04-04 23:37 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-03-31 9:05 [PATCH v2 00/11] MIPS relocatable kernel & KASLR Matt Redfearn
2016-03-31 9:05 ` [PATCH v2 01/11] MIPS: tools: Add relocs tool Matt Redfearn
2016-03-31 9:05 ` [PATCH v2 02/11] MIPS: tools: Build " Matt Redfearn
2016-03-31 9:05 ` [PATCH v2 03/11] MIPS: Reserve space for relocation table Matt Redfearn
2016-03-31 9:05 ` [PATCH v2 04/11] MIPS: Generate relocation table when CONFIG_RELOCATABLE Matt Redfearn
2016-03-31 9:05 ` [PATCH v2 05/11] MIPS: Kernel: Add relocate.c Matt Redfearn
2016-03-31 9:05 ` [PATCH v2 06/11] MIPS: Call relocate_kernel if CONFIG_RELOCATABLE=y Matt Redfearn
2016-03-31 9:05 ` [PATCH v2 07/11] MIPS: bootmem: When relocatable, free memory below kernel Matt Redfearn
2016-03-31 9:05 ` [PATCH v2 08/11] MIPS: Add CONFIG_RELOCATABLE Kconfig option Matt Redfearn
2016-03-31 9:05 ` [PATCH v2 09/11] MIPS: Introduce plat_get_fdt a platform API to retrieve the FDT Matt Redfearn
2016-03-31 9:05 ` [PATCH v2 10/11] MIPS: Kernel: Implement KASLR using CONFIG_RELOCATABLE Matt Redfearn
2016-03-31 9:05 ` [PATCH v2 11/11] MIPS: KASLR: Print relocation Information on boot Matt Redfearn
2016-03-31 12:38 ` Sergei Shtylyov
2016-04-01 8:44 ` Ralf Baechle
2016-04-01 9:07 ` Matt Redfearn
2016-04-04 19:46 ` [kernel-hardening] [PATCH v2 00/11] MIPS relocatable kernel & KASLR Kees Cook
2016-04-04 23:37 ` Ralf Baechle [this message]
2016-04-04 23:56 ` Kees Cook
2016-04-05 9:09 ` James Hogan
2016-04-05 18:10 ` Kees Cook
2016-04-05 21:00 ` James Hogan
2016-04-05 12:14 ` Maciej W. Rozycki
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=20160404233721.GB26295@linux-mips.org \
--to=ralf@linux-mips.org \
--cc=aaro.koskinen@nokia.com \
--cc=alexander.sverdlin@gmail.com \
--cc=ddaney@caviumnetworks.com \
--cc=jaedon.shin@gmail.com \
--cc=james.hogan@imgtec.com \
--cc=jogo@openwrt.org \
--cc=keescook@chromium.org \
--cc=kernel-hardening@lists.openwall.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mips@linux-mips.org \
--cc=matt.redfearn@imgtec.com \
--cc=paul.burton@imgtec.com \
--cc=tglx@linutronix.de \
--cc=yamada.masahiro@socionext.com \
/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