linux-stable.git/arch/x86/kernel/setup.c, branch v5.3

Merge branch 'x86-kdump-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip

2019-07-09T18:52:34+00:00

Pull x865 kdump updates from Thomas Gleixner:
 "Yet more kexec/kdump updates:

   - Properly support kexec when AMD's memory encryption (SME) is
     enabled

   - Pass reserved e820 ranges to the kexec kernel so both PCI and SME
     can work"

* 'x86-kdump-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  fs/proc/vmcore: Enable dumping of encrypted memory when SEV was active
  x86/kexec: Set the C-bit in the identity map page table when SEV is active
  x86/kexec: Do not map kexec area as decrypted when SEV is active
  x86/crash: Add e820 reserved ranges to kdump kernel's e820 table
  x86/mm: Rework ioremap resource mapping determination
  x86/e820, ioport: Add a new I/O resource descriptor IORES_DESC_RESERVED
  x86/mm: Create a workarea in the kernel for SME early encryption
  x86/mm: Identify the end of the kernel area to be reserved

x86/kdump/64: Restrict kdump kernel reservation to <64TB

2019-06-28T05:14:59+00:00

Restrict kdump to only reserve crashkernel below 64TB.

The reaons is that the kdump may jump from a 5-level paging mode to a
4-level paging mode kernel. If a 4-level paging mode kdump kernel is put
above 64TB, then the kdump kernel cannot start.

The 1st kernel reserves the kdump kernel region during bootup. At that
point it is not known whether the kdump kernel has 5-level or 4-level
paging support.

To support both restrict the kdump kernel reservation to the lower 64TB
address space to ensure that a 4-level paging mode kdump kernel can be
loaded and successfully started.

[ tglx: Massaged changelog ]

Signed-off-by: Baoquan He 
Signed-off-by: Thomas Gleixner 
Acked-by: Kirill A. Shutemov 
Acked-by: Dave Young 
Cc: bp@alien8.de
Cc: hpa@zytor.com
Link: https://lkml.kernel.org/r/20190524073810.24298-4-bhe@redhat.com

x86/mm: Identify the end of the kernel area to be reserved

2019-06-20T07:22:47+00:00

The memory occupied by the kernel is reserved using memblock_reserve()
in setup_arch(). Currently, the area is from symbols _text to __bss_stop.
Everything after __bss_stop must be specifically reserved otherwise it
is discarded. This is not clearly documented.

Add a new symbol, __end_of_kernel_reserve, that more readily identifies
what is reserved, along with comments that indicate what is reserved,
what is discarded and what needs to be done to prevent a section from
being discarded.

Signed-off-by: Tom Lendacky 
Signed-off-by: Borislav Petkov 
Reviewed-by: Baoquan He 
Reviewed-by: Dave Hansen 
Tested-by: Lianbo Jiang 
Cc: Andy Lutomirski 
Cc: Brijesh Singh 
Cc: Dave Young 
Cc: "H. Peter Anvin" 
Cc: Ingo Molnar 
Cc: Joerg Roedel 
Cc: Juergen Gross 
Cc: Kees Cook 
Cc: Nick Desaulniers 
Cc: Pavel Tatashin 
Cc: Peter Zijlstra 
Cc: Robert Richter 
Cc: Sami Tolvanen 
Cc: Sinan Kaya 
Cc: Thomas Gleixner 
Cc: "x86@kernel.org" 
Link: https://lkml.kernel.org/r/7db7da45b435f8477f25e66f292631ff766a844c.1560969363.git.thomas.lendacky@amd.com

treewide: Add SPDX license identifier for missed files

2019-05-21T08:50:45+00:00

Add SPDX license identifiers to all files which:

 - Have no license information of any form

 - Have EXPORT_.*_SYMBOL_GPL inside which was used in the
   initial scan/conversion to ignore the file

These files fall under the project license, GPL v2 only. The resulting SPDX
license identifier is:

  GPL-2.0-only

Signed-off-by: Thomas Gleixner 
Signed-off-by: Greg Kroah-Hartman

Merge branch 'x86-kdump-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip

2019-05-06T23:11:45+00:00

Pull x86 kdump update from Ingo Molnar:
 "This includes two changes:

   - Raise the crash kernel reservation limit from from ~896MB to ~4GB.

     Only very old (and already known-broken) kexec-tools is supposed to
     be affected by this negatively.

   - Allow higher than 4GB crash kernel allocations when low allocations
     fail"

* 'x86-kdump-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  x86/kdump: Fall back to reserve high crashkernel memory
  x86/kdump: Have crashkernel=X reserve under 4G by default

x86/kdump: Fall back to reserve high crashkernel memory

2019-04-22T08:23:05+00:00

crashkernel=xM tries to reserve memory for the crash kernel under 4G,
which is enough, usually. But this could fail sometimes, for example
when one tries to reserve a big chunk like 2G, for example.

So let the crashkernel=xM just fall back to use high memory in case it
fails to find a suitable low range. Do not set the ,high as default
because it allocates extra low memory for DMA buffers and swiotlb, and
this is not always necessary for all machines.

Typically, crashkernel=128M usually works with low reservation under 4G,
so keep <4G as default.

 [ bp: Massage. ]

Signed-off-by: Dave Young 
Signed-off-by: Borislav Petkov 
Reviewed-by: Ingo Molnar 
Acked-by: Baoquan He 
Cc: Dave Young 
Cc: David Howells 
Cc: Eric Biederman 
Cc: Greg Kroah-Hartman 
Cc: "H. Peter Anvin" 
Cc: Ingo Molnar 
Cc: Jiri Kosina 
Cc: Jonathan Corbet 
Cc: Juergen Gross 
Cc: Kees Cook 
Cc: Konrad Rzeszutek Wilk 
Cc: linux-doc@vger.kernel.org
Cc: "Paul E. McKenney" 
Cc: Petr Tesarik 
Cc: piliu@redhat.com
Cc: Ram Pai 
Cc: Sinan Kaya 
Cc: Thomas Gleixner 
Cc: Thymo van Beers 
Cc: vgoyal@redhat.com
Cc: x86-ml 
Cc: Yinghai Lu 
Cc: Zhimin Gu 
Link: https://lkml.kernel.org/r/20190422031905.GA8387@dhcp-128-65.nay.redhat.com

x86/kdump: Have crashkernel=X reserve under 4G by default

2019-04-22T08:15:16+00:00

The kdump crashkernel low reservation is limited to under 896M even for
X86_64. This obscure and miserable limitation exists for compatibility
with old kexec-tools but the reason is not documented anywhere.

Some more tests/investigations about the background:

a) Previously, old kexec-tools could only load purgatory to memory under
   2G. Eric removed that limitation in 2012 in kexec-tools:

     b4f9f8599679 ("kexec x86_64: Make purgatory relocatable anywhere
		   in the 64bit address space.")

b) Back in 2013 Yinghai removed all the limitations in new kexec-tools,
   bzImage64 can be loaded anywhere:

     82c3dd2280d2 ("kexec, x86_64: Load bzImage64 above 4G")

c) Test results with old kexec-tools with old and latest kernels:

  1. Old kexec-tools can not build with modern toolchain anymore,
     I built it in a RHEL6 vm.

  2. 2.0.0 kexec-tools does not work with the latest kernel even with
     memory under 896M and gives an error:

     "ELF core (kcore) parse failed"

     For that it needs below kexec-tools fix:

       ed15ba1b9977 ("build_mem_phdrs(): check if p_paddr is invalid")

  3. Even with patched kexec-tools which fixes 2),  it still needs some
     other fixes to work correctly for KASLR-enabled kernels.

So the situation is:

* Old kexec-tools is already broken with latest kernels.

* We can not keep these limitations forever just for compatibility with very
  old kexec-tools.

* If one must use old tools then he/she can choose crashkernel=X@Y.

* People have reported bugs where crashkernel=384M failed because KASLR
  makes the 0-896M space sparse.

* Crashkernel can reserve in low or high area, it is natural to understand
  low as memory under 4G.

Hence drop the 896M limitation and change crashkernel low reservation to
reserve under 4G by default.

Signed-off-by: Dave Young 
Signed-off-by: Borislav Petkov 
Reviewed-by: Ingo Molnar 
Acked-by: Baoquan He 
Cc: Dave Hansen 
Cc: David Howells 
Cc: Eric Biederman 
Cc: "H. Peter Anvin" 
Cc: Ingo Molnar 
Cc: Juergen Gross 
Cc: Petr Tesarik 
Cc: piliu@redhat.com
Cc: Ram Pai 
Cc: Sinan Kaya 
Cc: Thomas Gleixner 
Cc: vgoyal@redhat.com
Cc: x86-ml 
Cc: Yinghai Lu 
Cc: Zhimin Gu 
Link: https://lkml.kernel.org/r/20190421035058.943630505@redhat.com

efi: Unify DMI setup code over the arm/arm64, ia64 and x86 architectures

2019-03-29T06:35:00+00:00

All architectures (arm/arm64, ia64 and x86) do the same here, so unify
the code.

Note: We do not need to call dump_stack_set_arch_desc() in case of
!dmi_available. Both strings, dmi_ids_string and dump_stack_arch_
desc_str are initialized zero and thus nothing would change.

Signed-off-by: Robert Richter 
Signed-off-by: Ard Biesheuvel 
Reviewed-by: Jean Delvare 
Cc: Linus Torvalds 
Cc: Matt Fleming 
Cc: Peter Zijlstra 
Cc: Thomas Gleixner 
Cc: linux-efi@vger.kernel.org
Link: http://lkml.kernel.org/r/20190328193429.21373-5-ard.biesheuvel@linaro.org
Signed-off-by: Ingo Molnar

Merge branch 'mount.part1' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs

2019-01-05T21:25:58+00:00

Pull vfs mount API prep from Al Viro:
 "Mount API prereqs.

  Mostly that's LSM mount options cleanups. There are several minor
  fixes in there, but nothing earth-shattering (leaks on failure exits,
  mostly)"

* 'mount.part1' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs: (27 commits)
  mount_fs: suppress MAC on MS_SUBMOUNT as well as MS_KERNMOUNT
  smack: rewrite smack_sb_eat_lsm_opts()
  smack: get rid of match_token()
  smack: take the guts of smack_parse_opts_str() into a new helper
  LSM: new method: ->sb_add_mnt_opt()
  selinux: rewrite selinux_sb_eat_lsm_opts()
  selinux: regularize Opt_... names a bit
  selinux: switch away from match_token()
  selinux: new helper - selinux_add_opt()
  LSM: bury struct security_mnt_opts
  smack: switch to private smack_mnt_opts
  selinux: switch to private struct selinux_mnt_opts
  LSM: hide struct security_mnt_opts from any generic code
  selinux: kill selinux_sb_get_mnt_opts()
  LSM: turn sb_eat_lsm_opts() into a method
  nfs_remount(): don't leak, don't ignore LSM options quietly
  btrfs: sanitize security_mnt_opts use
  selinux; don't open-code a loop in sb_finish_set_opts()
  LSM: split ->sb_set_mnt_opts() out of ->sb_kern_mount()
  new helper: security_sb_eat_lsm_opts()
  ...

vfs: Suppress MS_* flag defs within the kernel unless explicitly enabled

2018-12-20T16:32:56+00:00

Only the mount namespace code that implements mount(2) should be using the
MS_* flags.  Suppress them inside the kernel unless uapi/linux/mount.h is
included.

Signed-off-by: David Howells 
Signed-off-by: Al Viro 
Reviewed-by: David Howells