<feed xmlns='http://www.w3.org/2005/Atom'>
<title>kernel.git/arch/x86/kernel/head_64.S, branch linux-5.13.y</title>
<subtitle>Hosts the 0x221E linux distro kernel.
</subtitle>
<id>https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-5.13.y</id>
<link rel='self' href='https://git.0xinfinity.dev/distro/kernel.git/atom?h=linux-5.13.y'/>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/'/>
<updated>2020-12-14T21:54:50Z</updated>
<entry>
<title>Merge tag 'x86_build_for_v5.11' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip</title>
<updated>2020-12-14T21:54:50Z</updated>
<author>
<name>Linus Torvalds</name>
</author>
<published>2020-12-14T21:54:50Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=84292fffc2468125632a21c09533a89426ea212e'/>
<id>urn:sha1:84292fffc2468125632a21c09533a89426ea212e</id>
<content type='text'>
Pull x86 build updates from Borislav Petkov:
 "Two x86 build fixes:

   - Fix the vmlinux size check on 64-bit along with adding useful
     clarifications on the topic (Arvind Sankar)

   - Remove -m16 workaround now that the GCC versions that need it are
     unsupported (Nick Desaulniers)"

* tag 'x86_build_for_v5.11' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip:
  x86/build: Remove -m16 workaround for unsupported versions of GCC
  x86/build: Fix vmlinux size check on 64-bit
</content>
</entry>
<entry>
<title>Merge tag 'x86_cleanups_for_v5.11' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip</title>
<updated>2020-12-14T21:45:26Z</updated>
<author>
<name>Linus Torvalds</name>
</author>
<published>2020-12-14T21:45:26Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=405f868f13daf7bae85e6fec143121c27d52cdb4'/>
<id>urn:sha1:405f868f13daf7bae85e6fec143121c27d52cdb4</id>
<content type='text'>
Pull x86 cleanups from Borislav Petkov:
 "Another branch with a nicely negative diffstat, just the way I
  like 'em:

   - Remove all uses of TIF_IA32 and TIF_X32 and reclaim the two bits in
     the end (Gabriel Krisman Bertazi)

   - All kinds of minor cleanups all over the tree"

* tag 'x86_cleanups_for_v5.11' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: (24 commits)
  x86/ia32_signal: Propagate __user annotation properly
  x86/alternative: Update text_poke_bp() kernel-doc comment
  x86/PCI: Make a kernel-doc comment a normal one
  x86/asm: Drop unused RDPID macro
  x86/boot/compressed/64: Use TEST %reg,%reg instead of CMP $0,%reg
  x86/head64: Remove duplicate include
  x86/mm: Declare 'start' variable where it is used
  x86/head/64: Remove unused GET_CR2_INTO() macro
  x86/boot: Remove unused finalize_identity_maps()
  x86/uaccess: Document copy_from_user_nmi()
  x86/dumpstack: Make show_trace_log_lvl() static
  x86/mtrr: Fix a kernel-doc markup
  x86/setup: Remove unused MCA variables
  x86, libnvdimm/test: Remove COPY_MC_TEST
  x86: Reclaim TIF_IA32 and TIF_X32
  x86/mm: Convert mmu context ia32_compat into a proper flags field
  x86/elf: Use e_machine to check for x32/ia32 in setup_additional_pages()
  elf: Expose ELF header on arch_setup_additional_pages()
  x86/elf: Use e_machine to select start_thread for x32
  elf: Expose ELF header in compat_start_thread()
  ...
</content>
</entry>
<entry>
<title>x86/head/64: Remove unused GET_CR2_INTO() macro</title>
<updated>2020-11-18T17:09:38Z</updated>
<author>
<name>Arvind Sankar</name>
</author>
<published>2020-10-05T15:12:08Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=31d8546033053b98de00846ede8088bdbe38651d'/>
<id>urn:sha1:31d8546033053b98de00846ede8088bdbe38651d</id>
<content type='text'>
Commit

  4b47cdbda6f1 ("x86/head/64: Move early exception dispatch to C code")

removed the usage of GET_CR2_INTO().

Drop the definition as well, and related definitions in paravirt.h and
asm-offsets.h

Signed-off-by: Arvind Sankar &lt;nivedita@alum.mit.edu&gt;
Signed-off-by: Borislav Petkov &lt;bp@suse.de&gt;
Link: https://lkml.kernel.org/r/20201005151208.2212886-3-nivedita@alum.mit.edu
</content>
</entry>
<entry>
<title>x86/build: Fix vmlinux size check on 64-bit</title>
<updated>2020-10-29T20:54:35Z</updated>
<author>
<name>Arvind Sankar</name>
</author>
<published>2020-10-29T16:19:03Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=ea3186b9572a1b0299448697cfc44920061872cf'/>
<id>urn:sha1:ea3186b9572a1b0299448697cfc44920061872cf</id>
<content type='text'>
Commit

  b4e0409a36f4 ("x86: check vmlinux limits, 64-bit")

added a check that the size of the 64-bit kernel is less than
KERNEL_IMAGE_SIZE.

The check uses (_end - _text), but this is not enough. The initial
PMD used in startup_64() (level2_kernel_pgt) can only map upto
KERNEL_IMAGE_SIZE from __START_KERNEL_map, not from _text, and the
modules area (MODULES_VADDR) starts at KERNEL_IMAGE_SIZE.

The correct check is what is currently done for 32-bit, since
LOAD_OFFSET is defined appropriately for the two architectures. Just
check (_end - LOAD_OFFSET) against KERNEL_IMAGE_SIZE unconditionally.

Note that on 32-bit, the limit is not strict: KERNEL_IMAGE_SIZE is not
really used by the main kernel. The higher the kernel is located, the
less the space available for the vmalloc area. However, it is used by
KASLR in the compressed stub to limit the maximum address of the kernel
to a safe value.

Clean up various comments to clarify that despite the name,
KERNEL_IMAGE_SIZE is not a limit on the size of the kernel image, but a
limit on the maximum virtual address that the image can occupy.

Signed-off-by: Arvind Sankar &lt;nivedita@alum.mit.edu&gt;
Signed-off-by: Borislav Petkov &lt;bp@suse.de&gt;
Link: https://lkml.kernel.org/r/20201029161903.2553528-1-nivedita@alum.mit.edu
</content>
</entry>
<entry>
<title>x86/head/64: Check SEV encryption before switching to kernel page-table</title>
<updated>2020-10-29T17:09:59Z</updated>
<author>
<name>Joerg Roedel</name>
</author>
<published>2020-10-28T16:46:58Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=c9f09539e16e281f92a27760fdfae71e8af036f6'/>
<id>urn:sha1:c9f09539e16e281f92a27760fdfae71e8af036f6</id>
<content type='text'>
When SEV is enabled, the kernel requests the C-bit position again from
the hypervisor to build its own page-table. Since the hypervisor is an
untrusted source, the C-bit position needs to be verified before the
kernel page-table is used.

Call sev_verify_cbit() before writing the CR3.

 [ bp: Massage. ]

Signed-off-by: Joerg Roedel &lt;jroedel@suse.de&gt;
Signed-off-by: Borislav Petkov &lt;bp@suse.de&gt;
Reviewed-by: Tom Lendacky &lt;thomas.lendacky@amd.com&gt;
Link: https://lkml.kernel.org/r/20201028164659.27002-5-joro@8bytes.org
</content>
</entry>
<entry>
<title>x86/head/64: Don't call verify_cpu() on starting APs</title>
<updated>2020-09-09T09:33:20Z</updated>
<author>
<name>Joerg Roedel</name>
</author>
<published>2020-09-07T13:16:09Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=3ecacdbd23956a549d93023f86adc87b4a9d6520'/>
<id>urn:sha1:3ecacdbd23956a549d93023f86adc87b4a9d6520</id>
<content type='text'>
The APs are not ready to handle exceptions when verify_cpu() is called
in secondary_startup_64().

Signed-off-by: Joerg Roedel &lt;jroedel@suse.de&gt;
Signed-off-by: Borislav Petkov &lt;bp@suse.de&gt;
Reviewed-by: Kees Cook &lt;keescook@chromium.org&gt;
Link: https://lkml.kernel.org/r/20200907131613.12703-69-joro@8bytes.org
</content>
</entry>
<entry>
<title>x86/sev-es: Setup GHCB-based boot #VC handler</title>
<updated>2020-09-09T09:32:27Z</updated>
<author>
<name>Joerg Roedel</name>
</author>
<published>2020-09-08T12:38:16Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=1aa9aa8ee517e0443b06e816a4fd2d15f2113615'/>
<id>urn:sha1:1aa9aa8ee517e0443b06e816a4fd2d15f2113615</id>
<content type='text'>
Add the infrastructure to handle #VC exceptions when the kernel runs on
virtual addresses and has mapped a GHCB. This handler will be used until
the runtime #VC handler takes over.

Since the handler runs very early, disable instrumentation for sev-es.c.

 [ bp: Make vc_ghcb_invalidate() __always_inline so that it can be
   inlined in noinstr functions like __sev_es_nmi_complete(). ]

Signed-off-by: Joerg Roedel &lt;jroedel@suse.de&gt;
Signed-off-by: Borislav Petkov &lt;bp@suse.de&gt;
Link: https://lkml.kernel.org/r/20200908123816.GB3764@8bytes.org
</content>
</entry>
<entry>
<title>x86/sev-es: Setup an early #VC handler</title>
<updated>2020-09-09T08:45:24Z</updated>
<author>
<name>Joerg Roedel</name>
</author>
<published>2020-09-08T12:35:17Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=74d8d9d531b4cc945a9f75aa2fc21d99ca5a9fe3'/>
<id>urn:sha1:74d8d9d531b4cc945a9f75aa2fc21d99ca5a9fe3</id>
<content type='text'>
Setup an early handler for #VC exceptions. There is no GHCB mapped
yet, so just re-use the vc_no_ghcb_handler(). It can only handle
CPUID exit-codes, but that should be enough to get the kernel through
verify_cpu() and __startup_64() until it runs on virtual addresses.

Signed-off-by: Joerg Roedel &lt;jroedel@suse.de&gt;
Signed-off-by: Borislav Petkov &lt;bp@suse.de&gt;
[ boot failure Error: kernel_ident_mapping_init() failed. ]
Reported-by: kernel test robot &lt;lkp@intel.com&gt;
Link: https://lkml.kernel.org/r/20200908123517.GA3764@8bytes.org
</content>
</entry>
<entry>
<title>x86/head/64: Move early exception dispatch to C code</title>
<updated>2020-09-07T20:49:18Z</updated>
<author>
<name>Joerg Roedel</name>
</author>
<published>2020-09-07T13:15:36Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=4b47cdbda6f1ad73b08dc7d497bac12b8f26ae0d'/>
<id>urn:sha1:4b47cdbda6f1ad73b08dc7d497bac12b8f26ae0d</id>
<content type='text'>
Move the assembly coded dispatch between page-faults and all other
exceptions to C code to make it easier to maintain and extend.

Also change the return-type of early_make_pgtable() to bool and make it
static.

Signed-off-by: Joerg Roedel &lt;jroedel@suse.de&gt;
Signed-off-by: Borislav Petkov &lt;bp@suse.de&gt;
Link: https://lkml.kernel.org/r/20200907131613.12703-36-joro@8bytes.org
</content>
</entry>
<entry>
<title>x86/head/64: Install a CPU bringup IDT</title>
<updated>2020-09-07T20:18:38Z</updated>
<author>
<name>Joerg Roedel</name>
</author>
<published>2020-09-07T13:15:34Z</published>
<link rel='alternate' type='text/html' href='https://git.0xinfinity.dev/distro/kernel.git/commit/?id=f5963ba7a45fc6ff298a34976064354be437e1d8'/>
<id>urn:sha1:f5963ba7a45fc6ff298a34976064354be437e1d8</id>
<content type='text'>
Add a separate bringup IDT for the CPU bringup code that will be used
until the kernel switches to the idt_table. There are two reasons for a
separate IDT:

	1) When the idt_table is set up and the secondary CPUs are
	   booted, it contains entries (e.g. IST entries) which
	   require certain CPU state to be set up. This includes a
	   working TSS (for IST), MSR_GS_BASE (for stack protector) or
	   CR4.FSGSBASE (for paranoid_entry) path. By using a
	   dedicated IDT for early boot this state need not to be set
	   up early.

	2) The idt_table is static to idt.c, so any function
	   using/modifying must be in idt.c too. That means that all
	   compiler driven instrumentation like tracing or KASAN is
	   also active in this code. But during early CPU bringup the
	   environment is not set up for this instrumentation to work
	   correctly.

To avoid all of these hassles and make early exception handling robust,
use a dedicated bringup IDT.

The IDT is loaded two times, first on the boot CPU while the kernel is
still running on direct mapped addresses, and again later after the
switch to kernel addresses has happened. The second IDT load happens on
the boot and secondary CPUs.

Signed-off-by: Joerg Roedel &lt;jroedel@suse.de&gt;
Signed-off-by: Borislav Petkov &lt;bp@suse.de&gt;
Link: https://lkml.kernel.org/r/20200907131613.12703-34-joro@8bytes.org
</content>
</entry>
</feed>
