lkml.org 
[lkml]   [2013]   [Jul]   [16]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [PATCH v5] x86: make sure IDT is page aligned
On 07/16/2013 01:47 PM, Kees Cook wrote:
> On Tue, Jul 16, 2013 at 1:33 PM, Steven Rostedt <rostedt@goodmis.org> wrote:
>> On Tue, 2013-07-16 at 13:28 -0700, Kees Cook wrote:
>>> On Tue, Jul 16, 2013 at 1:21 PM, Yinghai Lu <yinghai@kernel.org> wrote:
>>>> On Tue, Jul 16, 2013 at 11:34 AM, Kees Cook <keescook@chromium.org> wrote:
>>>>> Since the IDT is referenced from a fixmap, make sure it is page aligned.
>>>>> Merge with 32-bit one, since it was already aligned to deal with F00F
>>>>> bug. Since bss is cleared before IDT setup, it can live there. This also
>>>>> moves the other *_idt_table variables into common locations.
>>>>>
>>
>>> It seemed more correct to me to define all the IDTs the same, but
>>> there was no technical reason for that, just one of regularity. I only
>>> care about keeping the real IDT page aligned. :) I'm fine to do
>>> whatever is deemed "correct". :)
>>
>> I'm actually unfamiliar with the F00F bug (heard of it, but have no idea
>> what it is). What happens if the F00F bug exists and we switch to an IDT
>> that's not paged aligned? Is that an issue?
>
> Regardless of F00F, the IDT is now unconditionally being set up in a
> fixmap entry (so that the unprivileged "sidt" instruction won't leak a
> "real" kernel address, and so that this exposed address is read-only).
> If the real IDT is not page aligned, the fixmap IDT will appear offset
> and everything starts calling the wrong handlers.
>
> The other IDTs don't need to be page aligned, but I marked them that
> way in the clean up because it seemed sensible to define these tables
> similarly. I can change the others to be __cacheline_aligned_bss if
> that's desired.
>

I'm fine keeping them as page aligned. They are page-sized on x86-64
anyway (half page on i386).

-hpa




\
 
 \ /
  Last update: 2013-07-17 00:41    [W:0.094 / U:5.456 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site