[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 (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.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.

Ernst Rohlicek jun.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]