Mark the end of IA2 init #296
Conversation
There was a problem hiding this comment.
I don't personally mind the duplicated constant as long as you reference the other place it is defined. Alternatively, we could have an internal shared header for this that is included from the runtime? Can we include the whole internal header without picking up any actual code?
| /* during init, we allow re-mprotecting memory, which we need to alter | ||
| initially-RO destructors */ | ||
| else if (!memory_map_is_init_finished(map)) | ||
| return true; |
There was a problem hiding this comment.
Don't we want to track ownership of things like stacks mappings? If I read this correctly we won't actually mark these regions allocated during init as owned by a particular compartment?
There was a problem hiding this comment.
You're right that our memory map doesn't know about stack mappings and other "preexisting" mappings like the vDSO. If we want to fully mirror the kernel's idea of the process' memory map, we would need those, but I'm not 100% sure whether this is a security concern. Specifically, I guess an attack could involve unmapping the original stack and remapping other data in its place, which would then allow corrupting data used during process termination (post-main and dtors). But the original stack is also compartment zero anyway, right?
I'll punt on this for now but will file a bug. (EDIT: filed as #315)
There was a problem hiding this comment.
Note that allowing re-protecting memory during init here is not required because we don't know about stack mappings; these are separate concerns.
…partment's memory this is the policy we wanted in the first place, but required our PartitionAlloc changes that make each compartment use its own pool
… init has finished
fw-immunant
force-pushed
the
fw/mark-init-finished
branch
from
99a0653 to
f7548d8
Compare
This lets us avoid errors when running programs with destructors under the memory-map tracking runtime.
I want to factor out the magic constant--where should it live?