You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Original Test case writev02:
The file is created and write() is called with valid buffer to write
at some 8k th offset. After that writev() will be called with invalid
vector. This should return EFAULT. And at the same time, try looking at
the 8kth offset whether the file is intact or not.
What is the invalid address? Is it inside the enclave? Until we are using LKL’s mmap, we have a very conservative response to access ok and will allow any access inside the enclave, even to kernel memory.
Okay, looking at the code, I understand this a bit better:
The test allocates a page with PROT_NONE
The writev call is called with a pointer to this page.
LKL tries to read from it and receives a trap.
This is precisely expected with the current code. The enclave_mmap implementation does not track page permissions (which causes some other issues as well) and so we can't usefully return failure in lkl_access_ok.
I think this will Just Work(tm) once #597 is fixed, so I think this it is low priority to make it work with the existing enclave_mem code.
Original Test case writev02:
The file is created and write() is called with valid buffer to write
at some 8k th offset. After that writev() will be called with invalid
vector. This should return EFAULT. And at the same time, try looking at
the 8kth offset whether the file is intact or not.
Problem: if invalid vector is passed to the writev syscall expected to return EFAULT. But it is causing segmentation fault.
GDB logs:
The text was updated successfully, but these errors were encountered: