How to programmatically tell that Linux is in PAE or non-PAE mode?

Question

Need to create a script to check to see if the kernel is in PAE mode or not. Surely, it is not enough to just check if the /proc/cpuinfo flags have this 'pae' setting.

We must know if the PAE mechanism has actually been not only implemented, but activated as well.

Because the PAE kernel is now the new default, and that if you need a non-PAE kernel, one has to make another kernel nowadays.

1. In other word, how do we tell if a kernel is non-PAE on a CPU having PAE (is one of two possible conditions to test for).

2. Other is, how to tell if a kernel is PAE on a CPU having no PAE-support.

And there's no way to tell if CONFIG_HIGHMEM or CONFIG_PAE kernel configuration option was used in a typical secured kernel.

Bohannan

/proc/cpuinfo is a reliable way to determine if a given processor runs in PAE mode. This being not enough for you seems to imply you want to test a BIOS setting through your Linux platform. Can you elaborate on what exactly you want to achieve? – Briefless

Because the PAE kernel is now the default, and that if you need a non-PAE kernel, one has to make it nowaday. In other word, how do I tell if a kernel is non-PAE on a CPU having PAE (is one of two possible conditions to test for). Other is, how to tell if a kernel is PAE on a CPU having no PAE-support. And there's no way to tell if CONFIG_HIGHMEM or CONFIG_PAE was used in a secured kernel setup. – Bohannan

updated question to reflect this. – Bohannan

Answer 1

One way is to read the CR4 register and look at bit 5. It will be 1 for PAE and 0 for no PAE. You can read that register in some code running in the kernel (e.g. a kernel driver). You may be able to write a tiny driver for this purpose. It shouldn't be very complicated.

Mahone

It would be great if you could include sample code to do this. I know this is a 6-year old post, but here's to hoping you can. Thanks in advance! – Verenaverene

Answer 2

unsigned long cr4 = read_cr4();

if (cr4 & 0x20)
        pr_info("PAE enabled\n");
else
        pr_info("PAE disabled\n");

Anemic

You should add explanation. – Swellhead

Answer 3

It's theoretically possible to be running in an emulator, or retro CPU, not supporting PAE. Or maybe even a VM that masks off that CPUID feature bit. But if you know the hardware supports it, then checking the kernel config will work: if CONFIG_PAE=y, then Linux will use PAE if available.

One observable new feature that requires PAE is the NX (no-exec) bit in page-table entries. With legacy 32-bit x86 page tables, PROT_READ effectively implies PROT_EXEC. This feature isn't baseline for PAE (which existed since P6, but NX was only supported since later generations of P4 Prescott/Nocona.) But if you're not on ancient hardware, NX works if your kernel is using PAE.

So an experimental test you can do is to make a page non-executable and see if you can call code in it without segfaulting. Perhaps mprotect(PROT_READ) on a page containing code, or mmap a fresh page with PROT_READ|PROT_WRITE and copy code into it, then cast to a function pointer and call. (0xc3 is the machine code for an x86 ret instruction, and the standard calling convention enters a function ready to return.) So void (*funcptr)(void). See How to get c code to execute hex machine code? for an example of mmapping a page and calling code in it.

If that works even without PROT_EXEC, either your kernel was built without PAE support, or your executable is running with READ_IMPLIES_EXEC "personality" like on older kernel with gcc -zexecstack or from linking .o files created from assembly source files without a .section .note.GNU-stack,"",@progbits or equivalent for other assemblers. (Linux default behavior of executable .data section changed between 5.4 and 5.9?)

If you built your C program normally, without -zexecstack or any hand-written asm, it will segfault on trying to execute code in a page without PROT_EXEC, on kernels + hardware that fully support PAE, or 64-bit kernels.

Haplite