Hello,
I am trying to make pmd level of the translation table as read only so that any writes in the pte entries should cause a permission fault.
Current steps which i am doing are:
1) inside kernel space, allocating 2 pointers (say p, q) and allocating memory using vmalloc (4k size to occupy entire page)
2) assigning int data to both (say p=10, q= 20)
3) setting APTable bit for readonly for both the pointers (By reading manual, bit 61 and 62 denotes APTable)
4) swapping pte value for both the pointer in translation table
5) printing value for both the pointer
At step 4, access permission fault is not occurring.
I tried flushing the TLB, still at point 4 fault does not occur, but fault is occurring at random places (sometimes after point 5 or in between any points)
Can anyone tell me possible reasons why this is happening or some solution to fix it?
thanks
Not sure what you really want to achieve. Is this academic or do you need this for something real?But IIRC the Linux page table and the hardware page table are different.And making the page table read-only in kernel space makes no sense to me. The kernel has to modify it.
This is for academic purpose. We are trying to do something similar to "Hypervision across worlds" paper, where secure world makes page table changes for the kernel.
42Bastian Schick said:But IIRC the Linux page table and the hardware page table are different.
what do you mean by this?
From what i can see is different architecture has different page table but Linux kernel has a generic code to support all architecture by having few common functionalities and also architecture dependent code.
raks8877 said:3) setting APTable bit for readonly for both the pointers (By reading manual, bit 61 and 62 denotes APTable)
You may want to set the page table read-only. Not the PTE.
As I understand, you want to capture manipulation of the page table, right?
This is the important part (from descriped paper):
"Memory translation tables, a.k.a. page tables, define thevirtual to physical address mapping and the access permis-sions of virtual memory. TZ-RKP ensures that translationtables cannot be modified by the normal world. Moreover,it modifies the kernel so that requests to update the trans-lation tables are routed through the secure world."
So you need also modify the relevant parts in the kernel.
But actually, I do not understand the benefit of it all. Esp. if your code runs with the same privilege as the kernel. If you run a user-mode Linux, your approach may work. But again, you need to protect the page-table memory. Not the PTE.
42Bastian Schick said:You may want to set the page table read-only. Not the PTE.
Wait, i think we are not on the same page.
Setting last level of the page table read only is working, but making upper level of the page table read only is not working.
Let's assume translation granule of 4kb with page size as 4kb. It will have 4 levels of page table.
4th level points to page. Here making ready only with AP[7:6] bits works.
3rd level pointing to 4th level, we need to set APTable[62:61]. Here its not working as it is supposed to.
I am confused that are there any system registers which disables hierarchical permission checks for page table.
42Bastian Schick said: I do not understand the benefit of it all. Esp. if your code runs with the same privilege as the kernel.
No, the point is to run our code in the secure world(EL3) which has more privileges than kernel(EL1). With this we can reduce our trusted computing base code size. Also we can add policies which can say when kernel is allowed to make changes.
raks8877 said:No, the point is to run our code in the secure world(EL3) which has more privileges than kernel(EL1). With this we can reduce our trusted computing base code size. Also we can add policies which can say when kernel is allowed to make changes.
Ok, an important information, at last. But then, you are doing the same as written in the paper. Where is the "new" approach?
we are planing to build something on top of it, so before that we need to build this approach.
raks8877 said:Setting last level of the page table read only is working, but making upper level of the page table read only is not working.
To clear things up for me: You want prevent someone to modify the page tables. So you want to map the memory the page table resides as read-only.
And whenever the Linux kernel wants to set a new PTE (means write to the page table) you like to get trapped into EL3?
Armv7-A or Armv8-A.
I ask, because the paper is oooold. And I am pretty sure, EL2 (Hyp mode) would serve for this better.
The question is: What shall be protected if the "guest" sets a wrong PTE?
yes exactly. If we make it read only then access permission fault should generate and inside page fault handler we can call smc to switch to secure world.
Ah, so instead of finding all accesses to the page table, you only need to "para-virtualize" the fault handler.
Still, I do not see the benefit as to run it in a VM.
Armv8-A.
Yes EL2 could also work but we are relaying on the stronger grantees of isolation provided by secure world.
42Bastian Schick said:The question is: What shall be protected if the "guest" sets a wrong PTE?
Is guest the kernel or secure world?
If secure world then it will depend on the policies which we can set.
if kernel, then anyhow it should not have the ability to set anything since secure world will make any changes.
Yes true. In this approach, hypervisor and underlying os will be in TCB. which is still huge.
By using trustzone we can reduce it significantly.
"guest" means anything running in the normal world. So here - I guess - the Linux kernel and application.
But again, I am not sure what you want to protect by not letting Linux set PTEs at will?
Do you want to have a fine grained protection? (Still try to get the use case clear)
We (SCIOPTA) have a product where we rely on the TZ protection given by the SoC. For example the ZYNQ 7000 can define 64MB chunks of the SDRAM as either normal or secure.
raks8877 said:Yes EL2 could also work but we are relaying on the stronger grantees of isolation provided by secure world.
To be honest, I have not yet seen an example where EL3 is more secure then EL2 or gives a better separation.
42Bastian Schick said:Do you want to have a fine grained protection?
Yes. Suppose you want to implement some privacy or security policies. How will you do in linux? well maybe use lsm hooks.
If we remove the ability from kernel to make any changes and let secure world have it on its behalf, we can easily implement such policies.
42Bastian Schick said:For example the ZYNQ 7000 can define 64MB chunks of the SDRAM
Can you program it to give more SDRAM? if yes how?