x86/asm: Provide new infrastructure for GDT descriptors
authorVegard Nossum <vegard.nossum@oracle.com>
Tue, 19 Dec 2023 15:11:56 +0000 (16:11 +0100)
committerIngo Molnar <mingo@kernel.org>
Wed, 20 Dec 2023 09:56:04 +0000 (10:56 +0100)
commit016919c1f2e5b7ea3436abe6db0b73dbabd36682
tree969845a165a4f984d478e6944fd80aacbe8a131b
parentceb6a6f023fd3e8b07761ed900352ef574010bcb
x86/asm: Provide new infrastructure for GDT descriptors

Linus suggested replacing the magic numbers in the GDT descriptors
using preprocessor macros. Designing the interface properly is actually
pretty hard -- there are several constraints:

- you want the final expressions to be readable at a glance; something
  like GDT_ENTRY_FLAGS(5, 1, 0, 1, 0, 1, 1, 0) isn't because you need
  to visit the definition to understand what each parameter represents
  and then match up parameters in the user and the definition (which is
  hard when there are so many of them)

- you want the final expressions to be fairly short/information-dense;
  something like GDT_ENTRY_PRESENT | GDT_ENTRY_DATA_WRITABLE |
  GDT_ENTRY_SYSTEM | GDT_ENTRY_DB | GDT_ENTRY_GRANULARITY_4K is a bit
  too verbose to write out every time and is actually hard to read as
  well because of all the repetition

- you may want to assume defaults for some things (e.g. entries are
  DPL-0 a.k.a. kernel segments by default) and allow the user to
  override the default -- but this works best if you can OR in the
  override; if you want DPL-3 by default and override with DPL-0 you
  would need to start masking off bits instead of OR-ing them in and
  that just becomes harder to read

- you may want to parameterize some things (e.g. CODE vs. DATA or
  KERNEL vs. USER) since both values are used and you don't really
  want prefer either one by default -- or DPL, which is always some
  value that is always specified

This patch tries to balance these requirements and has two layers of
definitions -- low-level and high-level:

- the low-level defines are the mapping between human-readable names
  and the actual bit numbers

- the high-level defines are the mapping from high-level intent to
  combinations of low-level flags, representing roughly a tuple
  (data/code/tss, 64/32/16-bits) plus an override for DPL-3 (= USER),
  since that's relatively rare but still very important to mark
  properly for those segments.

- we have *_BIOS variants for 32-bit code and data segments that don't
  have the G flag set and give the limit in terms of bytes instead of
  pages

[ mingo: Improved readability bit more. ]

Signed-off-by: Vegard Nossum <vegard.nossum@oracle.com>
Signed-off-by: Ingo Molnar <mingo@kernel.org>
Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
Link: https://lore.kernel.org/r/20231219151200.2878271-2-vegard.nossum@oracle.com
arch/x86/include/asm/desc_defs.h