linux.git/arch/x86/kernel/setup_percpu.c, branch v4.13

x86/boot/32: Fix UP boot on Quark and possibly other platforms

2017-05-09T06:14:24+00:00

This partially reverts commit:

  23b2a4ddebdd17f ("x86/boot/32: Defer resyncing initial_page_table until per-cpu is set up")

That commit had one definite bug and one potential bug.  The
definite bug is that setup_per_cpu_areas() uses a differnet generic
implementation on UP kernels, so initial_page_table never got
resynced.  This was fine for access to percpu data (it's in the
identity map on UP), but it breaks other users of
initial_page_table.  The potential bug is that helpers like
efi_init() would be called before the tables were synced.

Avoid both problems by just syncing the page tables in setup_arch()
*and* setup_per_cpu_areas().

Reported-by: Jan Kiszka 
Signed-off-by: Andy Lutomirski 
Cc: Andy Shevchenko 
Cc: Ard Biesheuvel 
Cc: Boris Ostrovsky 
Cc: Borislav Petkov 
Cc: Brian Gerst 
Cc: Denys Vlasenko 
Cc: Josh Poimboeuf 
Cc: Juergen Gross 
Cc: Linus Torvalds 
Cc: Matt Fleming 
Cc: Peter Zijlstra 
Cc: Thomas Garnier 
Cc: Thomas Gleixner 
Cc: linux-efi@vger.kernel.org
Signed-off-by: Ingo Molnar

x86/boot/32: Defer resyncing initial_page_table until per-cpu is set up

2017-03-23T07:25:08+00:00

The x86 smpboot trampoline expects initial_page_table to have the
GDT mapped.  If the GDT ends up in a virtually mapped per-cpu page,
then it won't be in the page tables at all until perc-pu areas are
set up.  The result will be a triple fault the first time that the
CPU attempts to access the GDT after LGDT loads the perc-pu GDT.

This appears to be an old bug, but somehow the GDT fixmap rework
is triggering it.  This seems to have something to do with the
memory layout.

Signed-off-by: Andy Lutomirski 
Cc: Ard Biesheuvel 
Cc: Boris Ostrovsky 
Cc: Borislav Petkov 
Cc: Brian Gerst 
Cc: Denys Vlasenko 
Cc: H. Peter Anvin 
Cc: Josh Poimboeuf 
Cc: Juergen Gross 
Cc: Linus Torvalds 
Cc: Matt Fleming 
Cc: Peter Zijlstra 
Cc: Thomas Garnier 
Cc: Thomas Gleixner 
Cc: linux-efi@vger.kernel.org
Link: http://lkml.kernel.org/r/a553264a5972c6a86f9b5caac237470a0c74a720.1490218061.git.luto@kernel.org
Signed-off-by: Ingo Molnar

x86: Remap GDT tables in the fixmap section

2017-03-16T08:06:35+00:00

Each processor holds a GDT in its per-cpu structure. The sgdt
instruction gives the base address of the current GDT. This address can
be used to bypass KASLR memory randomization. With another bug, an
attacker could target other per-cpu structures or deduce the base of
the main memory section (PAGE_OFFSET).

This patch relocates the GDT table for each processor inside the
fixmap section. The space is reserved based on number of supported
processors.

For consistency, the remapping is done by default on 32 and 64-bit.

Each processor switches to its remapped GDT at the end of
initialization. For hibernation, the main processor returns with the
original GDT and switches back to the remapping at completion.

This patch was tested on both architectures. Hibernation and KVM were
both tested specially for their usage of the GDT.

Thanks to Boris Ostrovsky  for testing and
recommending changes for Xen support.

Signed-off-by: Thomas Garnier 
Cc: Alexander Potapenko 
Cc: Andrew Morton 
Cc: Andrey Ryabinin 
Cc: Andy Lutomirski 
Cc: Ard Biesheuvel 
Cc: Boris Ostrovsky 
Cc: Borislav Petkov 
Cc: Chris Wilson 
Cc: Christian Borntraeger 
Cc: Dmitry Vyukov 
Cc: Frederic Weisbecker 
Cc: Jiri Kosina 
Cc: Joerg Roedel 
Cc: Jonathan Corbet 
Cc: Josh Poimboeuf 
Cc: Juergen Gross 
Cc: Kees Cook 
Cc: Len Brown 
Cc: Linus Torvalds 
Cc: Lorenzo Stoakes 
Cc: Luis R . Rodriguez 
Cc: Matt Fleming 
Cc: Michal Hocko 
Cc: Paolo Bonzini 
Cc: Paul Gortmaker 
Cc: Pavel Machek 
Cc: Peter Zijlstra 
Cc: Radim Krčmář 
Cc: Rafael J . Wysocki 
Cc: Rusty Russell 
Cc: Stanislaw Gruszka 
Cc: Thomas Gleixner 
Cc: Tim Chen 
Cc: Vitaly Kuznetsov 
Cc: kasan-dev@googlegroups.com
Cc: kernel-hardening@lists.openwall.com
Cc: kvm@vger.kernel.org
Cc: lguest@lists.ozlabs.org
Cc: linux-doc@vger.kernel.org
Cc: linux-efi@vger.kernel.org
Cc: linux-mm@kvack.org
Cc: linux-pm@vger.kernel.org
Cc: xen-devel@lists.xenproject.org
Cc: zijun_hu 
Link: http://lkml.kernel.org/r/20170314170508.100882-2-thgarnie@google.com
Signed-off-by: Ingo Molnar

x86/percpu: Remove unnecessary include of module.h, add asm/desc.h

2016-11-15T06:26:37+00:00

This was originally a part of commit 186f43608a5c:

    ("x86/kernel: Audit and remove any unnecessary uses of module.h")

...but without the asm/desc.h addition.  As such, Ingo reported a
build failure on i386 allnoconfig with SMP=y during his pre-merge
testing.   For expediency the chunk was just dropped at that time.

The failure was as follows:

  arch/x86/kernel/setup_percpu.c: In function ‘setup_percpu_segment’:
  arch/x86/kernel/setup_percpu.c:159:2: error: implicit declaration of function ‘pack_descriptor’ [-Werror=implicit-function-declaration]
  arch/x86/kernel/setup_percpu.c:162:2: error: implicit declaration of function ‘write_gdt_entry’ [-Werror=implicit-function-declaration]
  arch/x86/kernel/setup_percpu.c:162:18: error: implicit declaration of function ‘get_cpu_gdt_table’ [-Werror=implicit-function-declaration]

As pack_descriptor(), write_gdt_entry() and get_cpu_gdt_table() all
live in the file arch/x86/include/asm/desc.h -- calling that header
out explicitly should fix things.

Reported-by: Ingo Molnar 
Signed-off-by: Paul Gortmaker 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Link: http://lkml.kernel.org/r/20161114190443.10873-1-paul.gortmaker@windriver.com
Signed-off-by: Ingo Molnar

Merge branch 'x86/mm' into x86/asm, to unify the two branches for simplicity

2016-09-08T06:41:52+00:00

Signed-off-by: Ingo Molnar

x86/dumpstack: Remove 64-byte gap at end of irq stack

2016-08-18T16:41:33+00:00

There has been a 64-byte gap at the end of the irq stack for at least 12
years.  It predates git history, and I can't find any good reason for
it.  Remove it.  What's the worst that could happen?

Signed-off-by: Josh Poimboeuf 
Cc: Andy Lutomirski 
Cc: Andy Lutomirski 
Cc: Borislav Petkov 
Cc: Brian Gerst 
Cc: Byungchul Park 
Cc: Denys Vlasenko 
Cc: Frederic Weisbecker 
Cc: H. Peter Anvin 
Cc: Kees Cook 
Cc: Linus Torvalds 
Cc: Nilay Vaish 
Cc: Peter Zijlstra 
Cc: Steven Rostedt 
Cc: Thomas Gleixner 
Link: http://lkml.kernel.org/r/14f9281c5475cc44af95945ea7546bff2e3836db.1471535549.git.jpoimboe@redhat.com
Signed-off-by: Ingo Molnar

x86: Apply more __ro_after_init and const

2016-08-10T12:55:05+00:00

Guided by grsecurity's analogous __read_only markings in arch/x86,
this applies several uses of __ro_after_init to structures that are
only updated during __init, and const for some structures that are
never updated.  Additionally extends __init markings to some functions
that are only used during __init, and cleans up some missing C99 style
static initializers.

Signed-off-by: Kees Cook 
Cc: Andy Lutomirski 
Cc: Andy Lutomirski 
Cc: Arnd Bergmann 
Cc: Borislav Petkov 
Cc: Brad Spengler 
Cc: Brian Gerst 
Cc: David Brown 
Cc: Denys Vlasenko 
Cc: Emese Revfy 
Cc: H. Peter Anvin 
Cc: Josh Poimboeuf 
Cc: Linus Torvalds 
Cc: Mathias Krause 
Cc: Michael Ellerman 
Cc: PaX Team 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: kernel-hardening@lists.openwall.com
Link: http://lkml.kernel.org/r/20160808232906.GA29731@www.outflux.net
Signed-off-by: Ingo Molnar

x86/acpi: store ACPI ids from MADT for future usage

2016-07-25T12:30:53+00:00

Currently we don't save ACPI ids (unlike LAPIC ids which go to
x86_cpu_to_apicid) from MADT and we may need this information later.
Particularly, ACPI ids is the only existent way for a PVHVM Xen guest
to figure out Xen's idea of its vCPUs ids before these CPUs boot and
in some cases these ids diverge from Linux's cpu ids.

Signed-off-by: Vitaly Kuznetsov 
Signed-off-by: David Vrabel

x86: Convert a few more per-CPU items to read-mostly ones

2014-11-04T19:13:28+00:00

Both this_cpu_off and cpu_info aren't getting modified post boot, yet
are being accessed on enough code paths that grouping them with other
frequently read items seems desirable. For cpu_info this at the same
time implies removing the cache line alignment (which afaict became
pointless when it got converted to per-CPU data years ago).

Signed-off-by: Jan Beulich 
Link: http://lkml.kernel.org/r/54589BD20200007800044A84@mail.emea.novell.com
Signed-off-by: Thomas Gleixner

x86: Add read_mostly declaration/definition to variables from smp.h

2012-06-14T10:42:11+00:00

Add "read-mostly" qualifier to the following variables in
smp.h:

 - cpu_sibling_map
 - cpu_core_map
 - cpu_llc_shared_map
 - cpu_llc_id
 - cpu_number
 - x86_cpu_to_apicid
 - x86_bios_cpu_apicid
 - x86_cpu_to_logical_apicid

As long as all the variables above are only written during the
initialization, this change is meant to prevent the false
sharing. More specifically, on vSMP Foundation platform
x86_cpu_to_apicid shared the same internode_cache_line with
frequently written lapic_events.

From the analysis of the first 33 per_cpu variables out of 219
(memories they describe, to be more specific) the 8 have read_mostly
nature (tlb_vector_offset, cpu_loops_per_jiffy, xen_debug_irq, etc.)
and 25 are frequently written (irq_stack_union, gdt_page,
exception_stacks, idt_desc, etc.).

Assuming that the spread of the rest of the per_cpu variables is
similar, identifying the read mostly memories will make more sense
in terms of long-term code maintenance comparing to identifying
frequently written memories.

Signed-off-by: Vlad Zolotarov 
Acked-by: Shai Fultheim 
Cc: Shai Fultheim (Shai@ScaleMP.com) 
Cc: ido@wizery.com
Cc: Linus Torvalds 
Cc: Andrew Morton 
Cc: Peter Zijlstra 
Link: http://lkml.kernel.org/r/1719258.EYKzE4Zbq5@vlad
Signed-off-by: Ingo Molnar