2

The documentation of the Linux kernel describes the virtual memory map.

It says:

fffffe0000000000 - fffffe7fffffffff (=39 bits) cpu_entry_area mapping

What is this "cpu entry area"? Is it accessible in some way to code running in ring 3 (i.e. CPL3)?

I ask because I am experimenting with QEMU, and it seems that some CPL3 code that runs on the QEMU guest (Ubuntu server 18.04) attempts (I don't know whether it succeeds) to access memory in cpu_entry_area.
At first, I thought I did something wrong, as I thought that all addresses higher than 0x00007fffffffffff aren't accessible to CPL3, but then I found out about vsyscall (see here).

I tried to access vsyscall memory (specifically *(int *)0xffffffffff600000) from CPL3 code in the QEMU guest, and succeeded, but I got a segfault when I tried to access the cpu_entry_area (specifically *(int *)0xfffffe0000000ee0).

Improve this question

1 Answer 1

Reset to default
4

cpu_entry_area contains all the data and code needed to allow the CPU to hand control over to the kernel. When KPTI is enabled, only that part of the kernel is mapped when user-space is running. You can see its definition in arch/x86/include/asm/cpu_entry_area.h: it contains

  • the GDT;
  • the entry stack;
  • the TSS;
  • a set of trampolines;
  • the exception stacks;
  • debug stores and buffers.

The trampolines contain the entry points for syscalls; see for example arch/x86/entry/entry_64.S which defines the entry point for 64-bit calls.

None of this is accessible directly from ring 3, but ring 3 code can jump into it using CPU-mediated mechanisms which allow changing privilege levels (e.g. the SYSCALL CPU instruction).

The kernel documentation on Page Table Isolation provides more context.

Improve this answer
4
  • That's very helpful, especially Documentation/x86/pti.txt. But why doesn't cpu_entry_area appear when I do cat /proc/<pid>/maps, while vsyscall does appear? Commented Oct 20, 2018 at 19:50
  • 1
    /proc/<pid>/maps only shows mappings of areas which are accessible from user-space; vsyscall is, but the rest of the kernel mappings aren’t. (User-space can jump into cpu_entry_area, but that’s mediated by CPU-provided mechanisms for changing privilege levels; cpu_entry_area isn’t directly accessible.) Commented Oct 20, 2018 at 19:57
  • Cool :) Any guess for the cause of the trace I got from QEMU? Is there any reason for CPL3 code to try to access cpu_entry_area? (Of course, it could be that some bug in my patch of QEMU makes it only seem that way, but I couldn't find such bug..) Commented Oct 20, 2018 at 20:26
  • I imagine that a SYSCALL could look like a CPL3 access to cpu_entry_area, depending on how you’re tracing; likewise an INT 0x80... But that’s just guessing ;-). Commented Oct 20, 2018 at 20:36

You must log in to answer this question.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.