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]

Message-ID: <20110211204030.GD2010@jolsa.brq.redhat.com>
Date:	Fri, 11 Feb 2011 21:40:30 +0100
From:	Jiri Olsa <jolsa@...hat.com>
To:	Brian Gerst <brgerst@...il.com>
Cc:	x86@...nel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] x86_64: disable identity mappings statically

On Fri, Feb 11, 2011 at 03:19:11PM -0500, Brian Gerst wrote:
> 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.

you're right, when I put it after setting cr3 it crashed
but I still don't understand what instruction took it down..?

thanks,
jirka
--
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/