linux-kernel - [PATCH 0/3] Add restrictions for kexec/kdump jumping between 5-level and 4-level kernel

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-next>] [day] [month] [year] [list]

Date:   Wed, 29 Aug 2018 22:16:21 +0800
From:   Baoquan He <bhe@...hat.com>
To:     tglx@...utronix.de, mingo@...nel.org, hpa@...or.com,
        kirill.shutemov@...ux.intel.com
Cc:     x86@...nel.org, linux-kernel@...r.kernel.org,
        kexec@...ts.infradead.org, Baoquan He <bhe@...hat.com>
Subject: [PATCH 0/3] Add restrictions for kexec/kdump jumping between 5-level and 4-level kernel

This was suggested by Kirill several months ago, I worked out several
patches to fix, then interrupted by other issues. So sort them out
now and post for reviewing.

The current upstream kernel supports 5-level paging mode and supports
dynamically choosing paging mode during bootup according to kernel
image, hardware and kernel parameter setting. This flexibility brings
several issues for kexec/kdump:
1)
Switching between paging modes, requires changes into target kernel.
It means you cannot kexec() 4-level paging kernel from 5-level paging
kernel if 4-level paging kernel doesn't include changes. 

2)
Switching from 5-level paging to 4-level paging kernel would fail, if
kexec() put kernel image above 64TiB of memory.

3)
Kdump jumping has similar issue as 2). This require us to only
reserve crashkernel below 64TB, otherwise jumping from 5-level to
4-level kernel will fail.

4)
The current kexec_load interface will put kernel at the top of system
RAM. This also need be restricted to be under 64TB. However this is not
an issue for kexec_file_load interface since it puts kernel at the top
of lowest 4GB. I ever planned to unify these two's behavior to put
kernel at top of system RAM the reason is we have been using the old
kexec_load, and still more widely than kexec_file_load. Just the change
involves too mamy lines of code change, seems people don't like it. Now
I decide to give up the unifying thing, just leave with it, and add the
restriction for kexec_load in kexec_tools unitilies. The unifying
behaviour patches are:

[PATCH v7 0/4] resource: Use list_head to link sibling resource
http://lkml.kernel.org/r/20180718024944.577-1-bhe@redhat.com

Note:
The issues 1), 2) need be done in kernel for kexec_file_load interface.
Meanwhile, 1), 2), and 4) need be done in user space kexec_tools
utility. I will post patches later for user space fix. Issue 3) can only
be done in kernel.

Baoquan He (3):
  x86/boot: Add bit fields into xloadflags for 5-level kernel checking
  x86/kexec/64: Error out if try to jump to old 4-level kernel from
    5-level kernel
  x86/kdump/64: Change the upper limit of crashkernel reservation

 arch/x86/boot/header.S                | 12 +++++++++++-
 arch/x86/include/uapi/asm/bootparam.h |  2 ++
 arch/x86/kernel/kexec-bzimage64.c     |  5 +++++
 arch/x86/kernel/setup.c               | 18 ++++++++++++++----
 4 files changed, 32 insertions(+), 5 deletions(-)

-- 
2.13.6