Bug 198851 - x86-64 kernel won't boot with 4KB page size
Summary: x86-64 kernel won't boot with 4KB page size
Status: NEW
Alias: None
Product: Other
Classification: Unclassified
Component: Other (show other bugs)
Hardware: x86-64 Linux
: P1 normal
Assignee: other_other
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2018-02-20 19:15 UTC by H.J. Lu
Modified: 2018-02-27 18:28 UTC (History)
1 user (show)

See Also:
Kernel Version: 4.15.3
Subsystem:
Regression: No
Bisected commit-id:


Attachments

Description H.J. Lu 2018-02-20 19:15:57 UTC
After I added

ifdef CONFIG_X86_64
LDFLAGS += $(call ld-option, -z max-page-size=0x1000)
endif

to arch/x86/Makefile, kernel won't boot and machine goes to BIOS
immediately.
Comment 1 H. Peter Anvin 2018-02-20 20:54:42 UTC
I believe this is a bug in our ELF parser that occurs when the output is larger than the input.
Comment 2 H.J. Lu 2018-02-27 18:15:35 UTC
X86 Kconfig has

config RANDOMIZE_BASE
        bool "Randomize the address of the kernel image (KASLR)"
        depends on RELOCATABLE
        default y
        ---help---
          In support of Kernel Address Space Layout Randomization (KASLR),
          this randomizes the physical address at which the kernel image
          is decompressed and the virtual address where the kernel
          image is mapped, as a security feature that deters exploit
          attempts relying on knowledge of the location of kernel
          code internals.

          On 64-bit, the kernel physical and virtual addresses are
          randomized separately. The physical address will be anywhere
          between 16MB and the top of physical memory (up to 64TB). The
          virtual address will be randomized from 16MB up to 1GB (9 bits 
          of entropy). Note that this also reduces the memory space
          available to kernel modules from 1.5GB to 1GB. 

          On 32-bit, the kernel physical and virtual addresses are
          randomized together. They will be randomized from 16MB up to
          512MB (8 bits of entropy).

          Entropy is generated using the RDRAND instruction if it is
          supported. If RDTSC is supported, its value is mixed into 
          the entropy pool as well. If neither RDRAND nor RDTSC are
          supported, then entropy is read from the i8254 timer. The
          usable entropy is limited by the kernel being built using
          2GB addressing, and that PHYSICAL_ALIGN must be at a 
          minimum of 2MB. As a result, only 10 bits of entropy are
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Is this possible for linker to use 4KB page size?

          theoretically possible, but the implementations are further
          limited due to memory layouts.

          If unsure, say Y.
Comment 3 H.J. Lu 2018-02-27 18:28:00 UTC
Also

config PHYSICAL_ALIGN
        hex "Alignment value to which kernel should be aligned"
        default "0x200000"
        range 0x2000 0x1000000 if X86_32
        range 0x200000 0x1000000 if X86_64
        ---help---
          This value puts the alignment restrictions on physical address
          where kernel is loaded and run from. Kernel is compiled for an
          address which meets above alignment restriction.

          If bootloader loads the kernel at a non-aligned address and
          CONFIG_RELOCATABLE is set, kernel will move itself to nearest
          address aligned to above value and run from there.

          If bootloader loads the kernel at a non-aligned address and
          CONFIG_RELOCATABLE is not set, kernel will ignore the run time
          load address and decompress itself to the address it has been
          compiled for and run from there. The address for which kernel is
          compiled already meets above alignment restrictions. Hence the
          end result is that kernel runs from a physical address meeting
          above alignment restrictions.

          On 32-bit this value must be a multiple of 0x2000. On 64-bit
          this value must be a multiple of 0x200000.

          Don't change this unless you know what you are doing.

Note You need to log in before you can comment on or make changes to this bug.