Re: HURDNG : Which type of OS design could we have to think nowadays ?

[Ernst Rohlicek jun.]

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