amd64/vmparam: Fix KASAN shadow map size in comment

[zishun.yi.dev_gmail.com]

Summary

The address range 0xfffff78000000000 - 0xfffff7bfffffffff spans exactly 256GB
(0x4000000000 bytes), not 512GB.

For a 2TB kernel map, based on the KASAN 1:8 shadow map ratio, the required
shadow map size is indeed 256GB. The current comment incorrectly states 512GB,
which can be misleading and cause confusion.

[markj]

Thanks

[markj]

Sigh. I realized just after pushing this that the address range is wrong, not the comment:

(kgdb) p/x kva_layout
$1 = {kva_min = 0xffff800000000000, kva_max = 0xfffffffffffff000, dmap_low = 0xfffff80000000000, dmap_high = 0xfffffc0000000000, 
  lm_low = 0xffff808000000000, lm_high = 0xfffff78000000000, km_low = 0xfffffe0000000000, km_high = 0xfffffffffffff000, rec_pt = 0xffff800000000000, 
  kasan_shadow_low = 0xfffff78000000000, kasan_shadow_high = 0xfffff80000000000, kmsan_shadow_low = 0xfffffc0000000000, 
  kmsan_shadow_high = 0xfffffe0000000000, kmsan_origin_low = 0xfffff60000000000, kmsan_origin_high = 0xfffff80000000000}

512GB makes sense, as that's one PML4 entry.

[markj]

In D57129#1309086, @markj wrote:

Sigh. I realized just after pushing this that the address range is wrong, not the comment:

(kgdb) p/x kva_layout
$1 = {kva_min = 0xffff800000000000, kva_max = 0xfffffffffffff000, dmap_low = 0xfffff80000000000, dmap_high = 0xfffffc0000000000, 
  lm_low = 0xffff808000000000, lm_high = 0xfffff78000000000, km_low = 0xfffffe0000000000, km_high = 0xfffffffffffff000, rec_pt = 0xffff800000000000, 
  kasan_shadow_low = 0xfffff78000000000, kasan_shadow_high = 0xfffff80000000000, kmsan_shadow_low = 0xfffffc0000000000, 
  kmsan_shadow_high = 0xfffffe0000000000, kmsan_origin_low = 0xfffff60000000000, kmsan_origin_high = 0xfffff80000000000}

512GB makes sense, as that's one PML4 entry.

... but only 256GB is used, since the kernel map is 2TB and the shadow map scale is 1:8, as you noted. So this is ok after all, ignore me. :)

[zishun.yi.dev_gmail.com]

In D57129#1309087, @markj wrote:

In D57129#1309086, @markj wrote:

Sigh. I realized just after pushing this that the address range is wrong, not the comment:

(kgdb) p/x kva_layout
$1 = {kva_min = 0xffff800000000000, kva_max = 0xfffffffffffff000, dmap_low = 0xfffff80000000000, dmap_high = 0xfffffc0000000000, 
  lm_low = 0xffff808000000000, lm_high = 0xfffff78000000000, km_low = 0xfffffe0000000000, km_high = 0xfffffffffffff000, rec_pt = 0xffff800000000000, 
  kasan_shadow_low = 0xfffff78000000000, kasan_shadow_high = 0xfffff80000000000, kmsan_shadow_low = 0xfffffc0000000000, 
  kmsan_shadow_high = 0xfffffe0000000000, kmsan_origin_low = 0xfffff60000000000, kmsan_origin_high = 0xfffff80000000000}

512GB makes sense, as that's one PML4 entry.

... but only 256GB is used, since the kernel map is 2TB and the shadow map scale is 1:8, as you noted. So this is ok after all, ignore me. :)

Ah, looking at it this way, both 256GB and 512GB make sense in the comment.

Out of curiosity, I noticed the arm64 memory map has a 512GB KVA but a 128GB KASAN shadow map. However, 128GB is not the size of a single page table entry, so I feel like 64GB would be more reasonable. Or did I miss something?

*                  0xffff009fffffffff  End of KASAN shadow map
*                  0xffff008000000000  Start of KASAN shadow map
*
*                  0xffff007fffffffff  End of KVA
*                  0xffff000000000000  Kernel base address & start of KVA

[markj]

In D57129#1309094, @zishun.yi.dev_gmail.com wrote:

In D57129#1309087, @markj wrote:

In D57129#1309086, @markj wrote:

Sigh. I realized just after pushing this that the address range is wrong, not the comment:

(kgdb) p/x kva_layout
$1 = {kva_min = 0xffff800000000000, kva_max = 0xfffffffffffff000, dmap_low = 0xfffff80000000000, dmap_high = 0xfffffc0000000000, 
  lm_low = 0xffff808000000000, lm_high = 0xfffff78000000000, km_low = 0xfffffe0000000000, km_high = 0xfffffffffffff000, rec_pt = 0xffff800000000000, 
  kasan_shadow_low = 0xfffff78000000000, kasan_shadow_high = 0xfffff80000000000, kmsan_shadow_low = 0xfffffc0000000000, 
  kmsan_shadow_high = 0xfffffe0000000000, kmsan_origin_low = 0xfffff60000000000, kmsan_origin_high = 0xfffff80000000000}

512GB makes sense, as that's one PML4 entry.

... but only 256GB is used, since the kernel map is 2TB and the shadow map scale is 1:8, as you noted. So this is ok after all, ignore me. :)

Ah, looking at it this way, both 256GB and 512GB make sense in the comment.

Out of curiosity, I noticed the arm64 memory map has a 512GB KVA but a 128GB KASAN shadow map. However, 128GB is not the size of a single page table entry, so I feel like 64GB would be more reasonable. Or did I miss something?

*                  0xffff009fffffffff  End of KASAN shadow map
*                  0xffff008000000000  Start of KASAN shadow map
*
*                  0xffff007fffffffff  End of KVA
*                  0xffff000000000000  Kernel base address & start of KVA

It's the same phenomenon as on amd64, I think: it's easier to implement all of these different maps when they have their own PML4/L0 entries. You're right that the map is really limited to 64GB in practice, but nothing else is going to use that virtual address range, so it's just a cosmetic issue.