Security of restore
Security of restore
Posted Feb 25, 2010 11:30 UTC (Thu) by epa (subscriber, #39769)Parent article: A Checkpoint/restart update
Posted Feb 25, 2010 15:39 UTC (Thu)
by hallyn (subscriber, #22558)
[Link] (1 responses)
'We' (meaning a much larger community than what has been the core
Posted Feb 25, 2010 22:56 UTC (Thu)
by mhelsley (guest, #11324)
[Link]
What's more, some parts of restart are done in userspace when it allows us to keep the kernel code much simpler. The process tree is recreated in userspace for example. As another example we also plan on using execve() to ensure that checkpoint images containing 32 and 64-bit processes are restarted correctly.
The in-kernel alternative for the process tree tended to involve creating kernel threads and then stripping them of their "special" status as kernel threads. Doing it in userspace with clone() (or eclone()) will be much easier to review and maintain.
The in-kernel alternative for the second example is to have sys_restart() do the 32/64-bit mm switches. That switch had to be carefully orchestrated for execve() where the kernel can throw away lots of state. We can't throw away as much state in sys_restart() so orchestrating that switch is even harder there. Plus it adds to the maintenance burden of arch maintainers. By using execve() we'll avoid all of that.
Easing maintenance has been a concern of ours for a long time and we're open to new suggestions from maintainers for making it even easier.
Security of restore
p=cryodev.git;a=summary. There are a boatload of things you cannot do from
userspace. In particular, specifying identifiers for resources like
sysvipc.
contributing team) decided to finally dive fully into the in-kernel approach
at the 2008 containers mini-summit - meeting notes at
http://wiki.openvz.org/Containers/Mini-summit_2008_notes.
Security of restore