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
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.
"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?
i answered it below, in case you missed it.
raks8877 said: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.
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.
raks8877 said: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.
Ah, something like a "private_malloc", which makes sure no other process (even kernel space) can access it. If that's it, I get the idea :-)
Yes exactly.
Can you explain a bit more on this.
is this memory fixed or can be programmed?