So first of all, it is not possible just like that to run 32 bit executable on a 64 bit system. So you don't need to translate the 32 bit address in a 64 bit address or something like that.
Second, 32 bit (without PAE) simply does not allow to map memory above the 4 GB border.
I thought a lot about the problem and by reading the section several times, I figured it out.
You may have seen the similar question on StackOverflow: Linux Kernel Memory Management Paging Levels
But I try to explain it how I understood it.
The thing I try to explain is how four level paging works on a 32 bit system.
The first sentence is essential
[...] eliminates the Page Upper Directory and the Page Middle Directory fields by saying that they contain zero bits.
This does not mean, that the kernel sets these fields to zero but it says these are zero without expressing this somewhere.
So you have the usual 32 bit address separation for a two level paging.
This means you use the 10 most significant bits of the virtual address for PML4 (Linux: PGD).
The PML4 (Linux: PGD) points to the PDPT (Linux: PUD) which has only one entry. Because the kernel says, the index/offset is zero, this only entry is taken.
The only entry of the PDPT (Linux: PUD) points to the PD (Linux: PMD) which again has only one entry. And again, the kernel says, the index/offset is zero, so this only entry is taken.
And finally, the only entry of the PD (Linux: PMD) points to the PT, where the intermediate 10 bits of the virtual address are used as the index to find the wanted page.
Summarized in short:
[1024 *] PML4 (Linux: PGD) -> 1 * PDPT (Linux: PUD) -> 1 * PD (Linux: PMD) -> 1024 * PT
The answer depends on whether kernel page-table isolation is enabled (which depends on the architecture and whether it supports KPTI).
Without KPTI, the kernel is fully mapped in each process’ address space, but as mentioned in the diagram, those mappings are inaccessible from user space (barring side-channel leaks).
With KPTI, the kernel page tables are separate from the userspace page tables, and only a minimal set of mappings are left in each process’ address space, as required to allow user space to call into the kernel, and to enable the processor to give control to the kernel when dealing with interrupts or exceptions.
In both cases, all processes have the same mappings for the kernel.
See also LWN’s article on KAISER.
Best Answer
Yes, the page tables are stored in the kernel address space. Each process has its own page table structure, which is set up so that the kernel portion of the address space is shared between processes. The kernel address space is not accessible from user space, however. The user space code communicates with the kernel in a controlled manner using system calls. After a successful system call the processor enters a privileged state in which the kernel address space is available.