[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAGXu5jJ7P95T0ZyAVZagQ0LZhSg28wxkQxR-tRFkhZsHekrN_Q@mail.gmail.com>
Date: Mon, 4 Apr 2016 16:56:58 -0700
From: Kees Cook <keescook@...omium.org>
To: Ralf Baechle <ralf@...ux-mips.org>
Cc: "kernel-hardening@...ts.openwall.com" <kernel-hardening@...ts.openwall.com>,
Linux MIPS Mailing List <linux-mips@...ux-mips.org>, Matt Redfearn <matt.redfearn@...tec.com>,
Aaro Koskinen <aaro.koskinen@...ia.com>, Masahiro Yamada <yamada.masahiro@...ionext.com>,
Alexander Sverdlin <alexander.sverdlin@...il.com>, LKML <linux-kernel@...r.kernel.org>,
Thomas Gleixner <tglx@...utronix.de>, David Daney <ddaney@...iumnetworks.com>,
Jaedon Shin <jaedon.shin@...il.com>, James Hogan <james.hogan@...tec.com>,
Jonas Gorski <jogo@...nwrt.org>, Paul Burton <paul.burton@...tec.com>
Subject: Re: [PATCH v2 00/11] MIPS relocatable kernel & KASLR
On Mon, Apr 4, 2016 at 4:37 PM, Ralf Baechle <ralf@...ux-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
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
