Osmium OS, IPC, PIC, and the rest

[Crazed123]

Pages can be marked writable or readable, present or not present. Loading a library, even if it's another process (like in my model, I don't know if JoeKayzA is allowing that) can almost definitely remain a system call for the sake of security. The loader would designate which processes could load which, and what pages would be writable.

Thusly, a loader could be created that say... left the code/text/executable section of a process/library (can we work on a convenient TLA or slang term for those?) read-only, but granted write access to data, bss and heap sections , providing additional security by making new instances of those sections for each loading/calling process as the loaded process specifies.

Or you could leave those pages read only and decide whether or not to grant write access when the page faults occur.

[JoeKayzA]

Assuming you use multiple page directories that all show the same address space but with various parts being inaccessible depending on whose page directory is being used... I can see how that provides protection. But then, you still have gratuitous TLB flushes on every task switch (at least on x86). So where's the big advantage?

The advantage has nothing to do with preserving TLB entries (although this is mainly the cpu's fault), normally you still use seperate page directories. The idea behind this is (I guess) that every object in the system can be addressed via a unique virtual memory address - no need to translate pointers when you map things to another address space, no need to construct a message when you send an RPC to another process - just call, send a set of keys with the call (the keys make an object accessible to another partial address space), and the receiver can read-access and copy data out of, and possibly write-access and dump a result into the callers address space. According to the mungi-people, this _does_ improve ipc performance. (Again - if I got the point right)

OTOH, it might slowdown the programs a bit. (guess why?)

But on an architecture with IP-relative addressing (like the amd64) the slowdown won't be really noticeable, it's mainly the x86 on which PIC is really a nightmare.

cheers Joe

[JoeKayzA]

Thinking of it more closely, really position independent code might not even be needed in a single address space OS, provided that you don't migrate partial address spaces from another machine (over the net) to an already running system. You don't need PIC because every binary (even a shared one) could get its unique base address at load time, and since all processes are running more or less in the same address space, a base address collision is impossible by design.

When you map a process' memory from another machine into your system's address space however, an address collision might occur (in the remote system, a process could sit at a base address that is already used by someone else in your system). So you would either have to coordinate the assignment of base addresses with other machines across the network (which is manageable in small networks like clusters, where only freshly booted nodes are added, no already running ones), or make the process inherently position independent, so you could map it in at any address that is free in your local address space.

The latter however is a problem: The idea of single address space requires any object or entry point in the system to have a unique address, and when a process gets mapped at different base addresses on different machines, its objects won't have a unique address anymore....

Thoughts? Input? Comments? Ah, before I forget, this is where these things come from: http://www.disy.cse.unsw.edu.au/Software/Mungi/

cheers Joe

[Legend]

Don't you need either segmentation or a relocateable file to have different base addresses for each process?

[JoeKayzA]

Don't you need either segmentation or a relocateable file to have different base addresses for each process?

A relocatable file would suffice. The talk was about position independent code at first, and a relocation, in contrast, only takes place at load time, it won't influence the runtime behaviour of the code later on. Let's forget about segmentation for now. ;D

cheers Joe

[Legend]

True.

However, with "traditional" native code, I don't see any protection left, if you place every process in the same address space.

[distantvoices]

@solar: He, what's up with you,wincing all the time when talking about AmigaOS? - it almost looks as if you've got a severe toothache to deal with. *rofl*

@others: sorry for me not being constructive - but I just canna imagine that this separate ipc server could help performance. Well - that's just my opinion.

STay safe

[Solar]

@solar: He, what's up with you,wincing all the time when talking about AmigaOS?

Got flamed once too often for always bringing up AmigaOS in OS design discussions. People didn't realize that I was bringing it up both for good and bad examples.

It's just so different from either Windows and Linux / BSD / OS X that it serves well to remind people that there are more than two choices, really.

[JoeKayzA]

However, with "traditional" native code, I don't see any protection left, if you place every process in the same address space.

The point is that they are only virtually put in the same address space, physically every process has its own page directory, and cannot directly access other process' portions of the space. Advantages have been listed above.

And, btw, I just put this talk about single address space OSs here because I found that it fits (because of direct rpc without messages), it's not yet another sick idea by me ::).

@beyond infinity: I think the 'seperate ipc server' discussion has already been cleared.

cheers Joe

[Crazed123]

Direct RPC without messages can also be done. I've had this idea of "mounting" one tree of virtual pages on another in much the way filesystems are mounted under Unix, so that a duplicate and relocated tree is produced that points to the same physical pages. This copied and relocated tree is then attached to the destination tree. A bit is set in a longword to indicate whether or not a virtual page is a mounted copy. If so, then it can't be unbound (seperated from its physical storage) or deleted unless an unmount operation is being done.

I'm thinking it could use some improvement or speeding up, but it'll work when done right.

[Pype.Clicker]

[small]<doh> i've not actively followed the thread, so i might be not so accurate... however,</doh>[/small]

the advantage of a "message" when doing RPC is that you can restrict access to what's in the message. Even when you use dynamic page mapping among two address spaces, if you call

Code: Select all

Playlist::append("some-tune-you-like",USER_REQUESTED_QUEUE);

what can prevent the music player to access the last entered URL "http://paypal.com/?myid=somenumber&myvisa=someothernumber" that you might wish to keep private ?
Especially if you have no apriori control on how the heap allocator will dispatch data on pages.

Things get even worse if you want some data to be returned, e.g.

Code: Select all

char* nowplaying=malloc(256);
Playlist::whatsonair(nowplaying,256);

How do you prevent the music player to mess with other data on that page ??

[Crazed123]

How do you prevent a C library from messing with everything else on that page?

The answer is that you don't. C libraries get write access to the process that loaded them (since you don't go making a kernel call with protection switch for every C library call), and the loading process takes responsibility for what the C library might do to it.

Now for processes it isn't that simple, since you can load something that will have an impact outside the loading process. Hence my idea in the OS Design thread that processes can have a function that the kernel attempts to call with the loading PID or a capability in order to determine privilege to load the thing.

[JoeKayzA]

the advantage of a "message" when doing RPC is that you can restrict access to what's in the message.

Got your point, and it's quite true. I still haven't completely decided for how the primitive IPC mechanism in my OS will look like. But I tend torwards a capability/port based messaging system with register, indirect string and memory mapping arguments.

Especially if you have no apriori control on how the heap allocator will dispatch data on pages.

That is a problem anyway. For things that are relevant to IPC, like buffers, parameter objects..., you should take care in advance that they are allocated within a certain page, so they could be mapped into the target's address space efficiently. If you don't, you'd have to copy strings at some point anyway - you could specify a scatter/gather list with the message, that the kernel copies into appropriate buffer regions in the target address space when the message gets delivered (this is the L4 way), same for the returned result.

When the kernel does not support such a mechanism, user space needs to take care of it - through copying prior to rpc.

cheers Joe