Hi,

I’m using arm64 machine and checking the memory mapping entries that are fed into the MMU TLB. For some reason I keep seeing a 1G writable page mapped to the end of the physical dram. I tried to intercept this mapping on all three supported page table levels, I.e. set_pgd, set_pmd and set_pte (although I clearly see from HW signals that it’s mapped on first level - pgd) but I couldn’t catch any mapping like that on those functions. (BTW, I disabled hugepages but I still see this page).
Anyone has a clue from where this 1G writable page mapping could come from? And why I don’t see it explicitly in the set_pgd function?

Thanks!

Can you expand on what you’re doing and why?

I’m trying to check if there are any memory pages that are pointed by Linux kernel as both executable and writable. I didn’t see any page entry that is marked as both executable & writable, however I did see several occurrences where two different page table entries map the same physical page entry - one as executable and one as writable. I tried to sort these cases and found that most of them are 1GB page mapped at the end of the dram as writable while from Tim to time I see that the kernel allocates 4KB executable pages that are included in this 1GB region. I used all the defconfigs that should disallow writable/ executable conflicts but I couldn’t get rid of this specific one.

I still don’t understand the problem you are trying to solve. Instead of issues you’ve encountered with perceived solution, can you elaborate on the original problem that sent you down this course?

And why are you trying to check that?

We have some system that should serve high security bar solutions. One of our targets is to prevent attackers from running malicious code on our system. For that, we built a dedicated hardware that is capable of validating the integrity of each executable memory page that is being loaded. Now, in order for this hardware to be efficient, we need to make sure that the (valid) SW that is running on our system will never map an executable memory page as writable, since this means that even if we validated the executable page integrity when it was loaded, it can still be modified later on. Hence, we’re trying to define such state of executable / writable pages as invalid state. I.e. we detect it as “attack” situation. I’m trying to check whether Linux is capable of fulfilling this requirement.

You have not mentioned SELinux once. Can I assume you've already looked at it extensively, with a focus on what it can and cannot do with memory pages?

Yes we evaluated SE Linux. Our concern is more about kernel exploits that can enable attacker taking full control on the kernel on EL1. Hence, our solution is not based on the kernel but on dedicated HW.
But let me ask please - is my assumption really true? I.e. that Linux shouldn’t map the same physical regions as writable and executable at he same time? Or am I missing some basic fundamental mechanism of Linux kernel operation?

The kernel has a legitimate need to preclude page faults in "pinned" areas of memory.

Software like JITs has a legitimate need to write to executable pages.

I think your question can only be answered by studying the kernel source. You seem to have enough resources.
Ed

Thanks Ed.
Let me please focus on one aspect that I’m not totally understand.
When Linux kernel load a new user space process, I assume it reads it from the disk and copy it to memory pages that are pointed by kernel page table entries and marked as writable non-executable. Now, it prepare those pages for user space execution, so I assume it marks the .text region as executable non-writable for user space in the user space page table entries. Does the kernel at this point also changes the kernel page table entries that point on these .text pages to be non-writable? Or does it keep it as writable for kernel?
Can someone point me to the code that deals with it?

Thanks!

Read the mmap () and mprotect () man pages. Then, look at /proc/$PID/maps for some process.

A lot of pages are mapped to files. This works by DMA'ing data into main memory.

The relevant kernel source is in the mm directory. Arm64-specific code is in arch/arm64/mm.
Ed

Interesting topic! The 1G writable page mapped by the kernel could significantly enhance performance for large-scale operations. It suggests an optimized memory management approach, allowing faster access to large data sets. However, I'm curious about the security implications and potential vulnerability to buffer overflows or similar exploits. Thoughts on apps to write essays https://essaypro.app/?

Essentially, if you find some kernel exploit that can cause it writing into this page (which is possible since it’s defined as “writable”) - you could change executable pages of running processes since they are allocated from the same physical memory, so in case of I-Cache miss they will fetch the “tampered data” and execute it under their permissions.