[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: HURDNG : Which type of OS design could we have to think nowadays ?
From: |
Ernst Rohlicek jun. |
Subject: |
Re: HURDNG : Which type of OS design could we have to think nowadays ? |
Date: |
Fri, 11 Aug 2006 22:12:40 +0200 |
User-agent: |
Thunderbird 1.5.0.4 (X11/20060702) |
>> Persistence: Well, I'm not sure whether orthogonal persistence (in my
>> interpretation this is quite similar to hiberation / suspend to disk)
>> is really required - better: what it's benefits in a general-purpose
>> OS for non-embedded CPUs are...
>>
>> After all you can still store your caps on disk, if youwould like to.
>
> You can, but if you do not save all the state, but only part of it,
> you face the non-trivial question which state to save and how to
> reconstruct the state that you don't safe (if it needs to be
> reconstructed). Clearly most of the state in your machine at any
> given time is junk. If you tell me which 90% of it is junk, I'd be
> very happy to drop the rest.
>
> So, to answer this question, we need to look at all the state and need
> to be able to label it with "save this" or "don't save this".
> ...being able to store capabilities is just a technical requirement
> for a solution, not the solution itself. The real problem lies in
> identifying the state that needs to be captured, not how to capture it
> technically. It's semantics, not syntax.
As I see it, there are a few options:
- Not saving caps and re-issuing caps every machine reboot and server
restart; processes are giving their children the caps they need.
- Reconstruct environment.
- Save all (if I remember correctly, EROS was doing this continuously
in the background).
The first point is the safest and easiest. You never restore a
check-pointed process back into the running system with the system
having changed state in a way which negatively impacts the program.
If you re-create the same environment security-wise and start it, the
program should run the same way. The environment is the POSIX-compatible
environment (env vars, working directory, user:group) and the
Hurd-specific environment (capabilities / ports, grants / memory maps).
I'm not sure as to what is the best place to save these things to (a
protected configuration file? into the filesystem inode?) though this
should be sufficient to run the program with the same privileges and
avoid the Confused Deputy Problem.
The third has a performance impact; though not as big as it is
subjectively assumed in the first moment, it is still there and I'm
still unsure what the advantages are...
Anyway, you will not be able to restore the same state as before
check-pointing because in case of a crash the underlying hardware was
reset and all remote connections were cut off. As soon as you have
non-local dependencies, processes & kernel & drivers will (1) not be in
the same state as when they were check-pointed because they get back
errors because hardware is not in the same state as before
check-pointing and (2) because network connections and especially the
remote parties will not be there or in the same protocol-wise state as
before.
In the best case, processes might be able to recover from the state
change, but I'm skeptical about that.
As a solution, you can just save process images of selected processes,
ie. no Hurd servers, kernel and drivers, just the applications and store
what caps they had, what files they had open ...
For Linux, this exists, though it is very limited (works only for daemon
processes as they say):
http://www.openmosixview.com/chpox/
-> http://www.cluster.kiev.ua/tasks/chpx_eng.html
(also with a paper about it)
-> http://www.checkpointing.org/
Please post what you think of this whole question or ping me on IRC (my
nick there is erj).
> Case in point: The Hurd passive translators are supposed to capture
> the state of a server in a command line string associated with an
> inode (the "name server entry" if you want). But in the current
> implementation, this fails to capture the complete state of the server
> process. This allows for rather simple attacks to escape a chroot
> environment, for example (because the filesystem jail of the server
> process is not captured state), and the system will reconstitute it
> with the wrong value).
I'm afraid, I do not know enough internals of the Hurd's current
implementation to think of a solution, sorry.
Greetings,
Ernst Rohlicek jun.
- HURDNG : Which type of OS design could we have to think nowadays ?, (continued)
- HURDNG : Which type of OS design could we have to think nowadays ?, Guillaume FORTAINE, 2006/08/06
- Re: HURDNG : Which type of OS design could we have to think nowadays ?, Neal H. Walfield, 2006/08/07
- Re: HURDNG : Which type of OS design could we have to think nowadays ?, Jonathan S. Shapiro, 2006/08/07
- Re: HURDNG : Which type of OS design could we have to think nowadays ?, Guillaume FORTAINE, 2006/08/07
- Re: HURDNG : Which type of OS design could we have to think nowadays ?, Jonathan S. Shapiro, 2006/08/07
- Re: HURDNG : Which type of OS design could we have to thinknowadays ?, Nigel Williams, 2006/08/07
- Re: HURDNG : Which type of OS design could we have to thinknowadays ?, Jonathan S. Shapiro, 2006/08/07
- Re: HURDNG : Which type of OS design could we have to thinknowadays ?, Nigel Williams, 2006/08/07
- Re: HURDNG : Which type of OS design could we have to think nowadays ?, Ernst Rohlicek jun., 2006/08/07
- Re: HURDNG : Which type of OS design could we have to think nowadays ?, Marcus Brinkmann, 2006/08/08
- Re: HURDNG : Which type of OS design could we have to think nowadays ?,
Ernst Rohlicek jun. <=
- Re: HURDNG : Which type of OS design could we have to think nowadays ?, Marcus Brinkmann, 2006/08/11
- Re: HURDNG : Which type of OS design could we have to think nowadays ?, Jonathan S. Shapiro, 2006/08/12
- Re: HURDNG : Which type of OS design could we have to think nowadays ?, Jonathan S. Shapiro, 2006/08/12
Re: Can we really think at a new OS design nowadays ?, Benno, 2006/08/05