Doubts in step 3
Raunaque Khan
Dear Mark Seaborn,
Here is you claim how rowhammer works Sure, let's break down the steps for the Rowhammer exploit into 5 main parts:
Step1: Preparing Aggressor/Victim Addresses:
The process begins by using the mmap() system call to allocate blocks of memory. This memory block is often chosen to be significant in size to increase the chances of finding exploitable bit flips. The purpose of this memory block is to create a playground for the subsequent steps of the Rowhammer exploit. The memory is mapped into the process's virtual address space, making it accessible for manipulation and analysis.
Not every bit flip is useful for the exploit's objectives. Some bit flips may not lead to the desired outcome or may not provide the necessary access. If, during the Rowhammer attack, a bit flip occurs in an aggressor/victim pair that doesn't contribute to the exploit's goals, it is considered not useful. In such cases, the exploit skips these pairs, optimizing the process to focus on potentially exploitable bit flips.
Once useful aggressor/victim pairs are identified, the exploit takes steps to isolate these pages for further manipulation. The munmap() system call is used to unmap (remove from the process's virtual address space) all pages of the large block of memory except those containing the aggressor and victim addresses. The exploit removes unnecessary memory areas, focusing only on what's needed. This reduces the amount of memory it uses, making things simpler and faster.
Step2: Spraying the computer’s memory with the Page Tables:
For spraying page tables we have to create a file in /dev/shm with marker values on 4k pages. By using mmap() repeatedly to spray memory with page tables. It maps repeatedly with a file /dev/shm.
Step 3: Hammer Time:
The exploit removes a specific page from the computer's memory using munmap()..
Then rowhammer the aggressor addresses, inducing bit flips in the victim page.
Step 4: Checking for PTE Changes:
The exploit looks at the mapped memory region to see if there are any changes in the Page Table Entries (PTEs).If the exploit finds a mismatch with these markers, it knows something has changed. This mismatch suggests that it might have gained unauthorized access to a special memory page. Since in the 64 bit PTEs we hammer the second last
Step 5: Exploiting write access to page tables:
We now have write access to one of our process’s page tables. By modifying the page table, we can get access to any page in physical memory. We now have many options for how to exploit that, varying in portability, convenience and speed. The portable options work without requiring knowledge of kernel data structures. Faster options work in O(1) time, whereas slower options might require scanning all of physical memory to locate a data structure.
How to bit flip a particular range in virtual address so that the page table entry obtain is valid and belongs
to a valid page table
As of my understand i realize that I’m having two two big issues i.e.,
How to bit flip a particular range in virtual address(i.e., between bit 20 to 12 page table offset) so that the page table entry obtained is valid and belongs to a valid page table.
Can you Please explain briefly how you are exploiting write access to page tables and Please provide the actual code for Exploiting write access to page tables as the github code which you had provided with your blogspot (Exploiting the DRAM rowhammer bug to gain kernel privileges) that doesn't have the exploiting code.