Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1371057
| From | Kees Cook <keescook@chromium.org> |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [kernel-hardening] [PATCH v2 00/11] MIPS relocatable kernel & KASLR |
| Date | 2016-04-05 02:00 +0200 |
| Message-ID | <rkmzx-2ph-37@gated-at.bofh.it> (permalink) |
| References | <riGVH-2I1-3@gated-at.bofh.it> <rkiFB-89A-15@gated-at.bofh.it> <rkmga-2hL-3@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
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
Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
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
csiph-web