blob: 2c5ecfb02cf3ebe952d03e37ef82d8a8f6299910 (
plain) (
blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
|
Support mixture of guest and host robust futexes
We can't safely modify the guest's robust list
- Memory might not be sufficient, or it will just overwrite our additions on change
We also can't safely consume the full guest robust and append it to our own
- We don't have a full view of glibc's robust list
- Might work if we capture all HOST get/set lists and modifying it? Needs seccomp filters then.
- Would require us to track our own list, append the glibc head to our tail, and append the guest one to that tail as well.
- Same problem where host glibc could potentially overwrite the and end that contains the guest.
- Can't guarantee no host robust-futex usage due to thunks.
We have no interface in to setting 32bit robust list
- Needs the syscall32 API
Proposal to the kernel?
- New robust list indexing API?
- Something that uses the key api?
- long set_robust_list_key(key_t key, struct robust_list_head *head, size_t len, int listflg);
- IPC_CREAT - Create a new robust list associated with key
- IPC_EXCL - same to ensure the syscall fails if already created
- long get_robust_list_key(key_t key, int pid, struct robust_list_head **head_ptr,
size_t *len_ptr);
- long del_robust_list_key(key_t key);
- Disassociates robust list of key from process and deletes?
Allows us to create multiple robust lists tied to a pid.
Still have the regular get/set robust list path, just additional list arrays on top of that.
Expectation is to only have a handful of robust lists, can be a linear scan lookup.
Expose the 32bit path through the "regular" 32bit syscall path.
I'm already dreading bringing this up on the mailing list.
|