linux-kernel - Re: [PATCH] x86_64: disable identity mappings statically

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 11 Feb 2011 15:19:11 -0500
From:	Brian Gerst <brgerst@...il.com>
To:	Jiri Olsa <jolsa@...hat.com>
Cc:	"Eric W. Biederman" <ebiederm@...ssion.com>, tglx@...utronix.de,
	mingo@...hat.com, x86@...nel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] x86_64: disable identity mappings statically

On Fri, Feb 11, 2011 at 2:13 PM, Jiri Olsa <jolsa@...hat.com> wrote:
> On Fri, Feb 11, 2011 at 12:59:47PM -0500, Brian Gerst wrote:
>> On Fri, Feb 11, 2011 at 12:07 PM, Jiri Olsa <jolsa@...hat.com> wrote:
>> > On Fri, Feb 11, 2011 at 08:46:41AM -0800, Eric W. Biederman wrote:
>> >> Jiri Olsa <jolsa@...hat.com> writes:
>> >>
>> >> > hi,
>> >> >
>> >> > while browsing the page table setup code, I noticed the x86_64 head
>> >> > code might not need the identity mappings at all.
>> >> > It seems it's ok to switch it off completely from the begining,
>> >> > unless I'm missing something.
>> >>
>> >> Have you tested it?
>> >
>> > yes, I booted it with no problem
>>
>> The only reason this doesn't crash is because the identity mappings
>> provided by the boot code are marked as global, and therefore might
>> not be flushed by simply loading cr3.  The cpu can evict TLB entries
>> at any time though, so it's a bad idea to run without the identity
>> mappings even for the brief moment before jumping to the virtual
>> address.
>
> I added code for flushing whole TLB (including global pages) and it
> still boots (attached).
>
> I'm sorry if I'm missing something obvious (probably the TLB flushing
> code is wrong), but I'd like to understand this part.
>
> What instruction/action would require the identity mapping,
> after the page table is set?
>
> thanks (and again sry for noise :) )
> jirka
>
>
> ---
> diff --git a/arch/x86/kernel/head_64.S b/arch/x86/kernel/head_64.S
> index c55e6fa..073f489 100644
> --- a/arch/x86/kernel/head_64.S
> +++ b/arch/x86/kernel/head_64.S
> @@ -165,6 +165,13 @@ ENTRY(secondary_startup_64)
>        movl    $(X86_CR4_PAE | X86_CR4_PGE), %eax
>        movq    %rax, %cr4
>
> +       /* invalidate whole TLB */
> +       movq %cr4, %rax
> +       movq %rax, %rdx
> +       andq $~X86_CR4_PGE, %rax
> +       movq %rax, %cr4
> +       movq %rdx, %cr4
> +
>        /* Setup early boot stage 4 level pagetables. */
>        movq    $(init_level4_pgt - __START_KERNEL_map), %rax
>        addq    phys_base(%rip), %rax
>

The way you have it, it will immediately reload the global identity
entry into the TLB when it executes the next instruction, because cr3
is still pointing to the old pagetables.  Disable PGE during or
immediately after the load of cr3 to make sure the global identity
entries are flushed.

--
Brian Gerst
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/