Menu
▾
▴
elysium-developers
You can subscribe to this list here.
| 2000 |
Jan
|
Feb
(81) |
Mar
(26) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Rogelio S. <ro...@ev...> - 2001-05-14 01:06:37
|
I have modified very heaavily my copy of elysium. I ported vcode to elysium. I also implemented a slab allocator on top of a list based best-fit allocator. Elysium now boots in paged mode. It is linked at 0xf0000000. just like the MIT exokernel. |
|
From: Kasper V. L. <ve...@da...> - 2000-03-27 08:09:41
|
Hi, The kernel project has been created -- look for 'Gemini Nucleus' on SourceForge. Alternatively use the URL http://gemini.sourceforge.net/ to gain access to the -- unfinished -- webpages. To get on the developers list please subscribe to 'gem...@li...' and send me a personal e-mail (ve...@da...). If you have special reasons for wanting to be on the developers list, but you still want to avoid being on the mailing list please let me know. The basic nucleus available from cvs (cvs.gemini.sourceforge.net) is a stripped version of the Elysium kernel. The reason I stripped some of the code from it is to allow us -- and our fellow developers from the Apostle project -- to get some of the basic code right. I wrote most of the initial code, but I still feel that some of it could be implemented a lot better. Comments? /Kasper -- ------------------------------------------------------------------- Kasper Verdich Lund, Computer Science Department, Aarhus University Office: 34P.218 | Phone: (+45) 8942 5680 Email: ve...@da... | WWW: http://www.daimi.au.dk/~verdich |
|
From: Kasper V. L. <ve...@da...> - 2000-03-19 11:39:06
|
Adam Langley wrote: > Ok the simple 'assembly-like language': > > A 32-bit virtual machine with 16 general purpose registers. 32-bit 'segment' > selector and 32-bit offset into each segment. The segments are disk blocks (the > owns() might need to read in other disk blocks). I think it's impossible to guarantee determinism of the owns() function if it's allowed to read in -- and use/examine -- other disk blocks. For other situations it might be useful though... /Kasper -- ------------------------------------------------------------------- Kasper Verdich Lund, Computer Science Department, Aarhus University Office: 34P.218 | Phone: (+45) 8942 5680 Email: ve...@da... | WWW: http://www.daimi.au.dk/~verdich |
|
From: Kasper V. L. <ve...@da...> - 2000-03-19 11:06:20
|
Adam Langley wrote: > I'd support a system of bootstrapping thou. The kernel must have some built-in > fs code, in order to launch the first process. That (init) could then load > owns() functions. The bootloader -- for now GNU GRUB -- will handle loading the initial fs code. IMHO there's no need to equip the kernel with built-in fs code. /Kasper -- ------------------------------------------------------------------- Kasper Verdich Lund, Computer Science Department, Aarhus University Office: 34P.218 | Phone: (+45) 8942 5680 Email: ve...@da... | WWW: http://www.daimi.au.dk/~verdich |
|
From: Adam L. <ag...@li...> - 2000-03-18 09:32:27
|
On Thu, Mar 16, 2000 at 10:08:35AM +0100, Kasper Verdich Lund wrote: > To > define a filesystem applications upload a function 'owns()' -- written > in a simple assembly-like language Ok the simple 'assembly-like language': A 32-bit virtual machine with 16 general purpose registers. 32-bit 'segment= '=20 selector and 32-bit offset into each segment. The segments are disk blocks = (the owns() might need to read in other disk blocks). The VM can write to a reserved segment (0xffffffff). it puts the block list into here. It has all the boolean op's, ADD, SUB, conditional tests and jum= ps (but can only jump to consant values). The compiler is half-written. An interpreter will be written first but there is no reason why a EPC->i386 Machine Code translator couldn't be written (E= PC-> Exo-kernel PseudoCode) I post when things are finished and then people can destroy it as needed ;) AGL --=20 Smoking is one of the leading causes of statistics. |
|
From: Adam L. <ag...@li...> - 2000-03-18 09:26:04
|
On Thu, Mar 16, 2000 at 10:08:35AM +0100, Kasper Verdich Lund wrote: > [this mail only considers harddisks -- sorry] >=20 > I suggest implementing the access to block devices -- e.g. harddisks -- > purely in user-space. A user-level server will initially request the I/O > port ranges (and perhaps some parts of physical memory) needed to access > todays sofisticated harddisks. Once the server has access to these > hardware resources the kernel ensures that it's impossible for any other > processes to gain access to the specific ports (and memory regions). Tiny annoyance here. You are using the order of process loading as security= - this is *not* a good thing security-wise. Rather I think init (or whatever = the kernel fork()/exec()'s) should pass the disk-server the capibilities for the I/O ports. But we are far from this point yet ;) > The server is capable of reading/writing any disk blocks (for efficiency > a disk block should have the same size as the hardware page -- 4kb) into > a buffer cache. A process can make a request to read a set of disk > blocks into the buffer cache. There should be no access checking on this > request, since reading blocks into the buffer cache does not -- in > itself -- give access to the blocks in question. Eccept that a process could flood request blocks and overfill the cache. Wh= at is the difference between a heavy load on a httpd and a nasty process flood= ing? But processes generally have far more valid data that they could legally re= ad (given IBM have just released 75GB drives) then the size of the BC. I don't= =20 think that access checking will solve this. Hmm. > Likewise > flushing/writing parts of the cache should be operations accessible by > user processes, but it might be that we need some kind of access > checking on these operations. see above. Processes could legally write lots of stuff, eating up I/O > IMHO the most interesting way of doing this is by using UDFs (untrusted > determistic functions). In this section I do not consider file > permissions (in the standard *NIX sense), but only explain how to ensure > that disk blocks that aren't parts of any file can't be accessed. To > define a filesystem applications upload a function 'owns()' -- written > in a simple assembly-like language -- that can be verified to be > deterministic. I think that UDF's are going to be used a lot in whatever Elysium becomes (how is the merge going?) so a library is in order. Not a shared library but a .a file. That sounds like a really Cool Thing (tm), I might start on one. > To allow maximum flexibility any process should be able to create a > filesystem (by specifying the 'owns()' function). To keep filesystems > across reboots (generally a good idea :-) the 'owns()' function should > be saved on disk along with information on the location of the > associated root meta-data block. >=20 Filesystems will have to be protected via standard means or by layering (wh= ere a filesystem is implimented in a file). If we store owns() functions in the filesystem it should be in meta language (not compiled). I'd support a system of bootstrapping thou. The kernel must have some built= -in fs code, in order to launch the first process. That (init) could then load owns() functions. And processes must have capabilites for a range of disk blocks before they can load owns() functions for them. AGL --=20 Smoking is one of the leading causes of statistics. |
|
From: Kasper V. L. <ve...@da...> - 2000-03-16 15:35:14
|
Hannu Heikkinen wrote: > I suggest: Exos It's a good name, but unfortunately it's already used by the exokernel implementation done by MIT. The default UNIX library operating system is called ExOS (and it runs on Xok). /Kasper -- ------------------------------------------------------------------- Kasper Verdich Lund, Computer Science Department, Aarhus University Office: 34P.218 | Phone: (+45) 8942 5680 Email: ve...@da... | WWW: http://www.daimi.au.dk/~verdich |
|
From: Kasper V. L. <ve...@da...> - 2000-03-16 09:13:50
|
[this mail only considers harddisks -- sorry] I suggest implementing the access to block devices -- e.g. harddisks -- purely in user-space. A user-level server will initially request the I/O port ranges (and perhaps some parts of physical memory) needed to access todays sofisticated harddisks. Once the server has access to these hardware resources the kernel ensures that it's impossible for any other processes to gain access to the specific ports (and memory regions). The server is capable of reading/writing any disk blocks (for efficiency a disk block should have the same size as the hardware page -- 4kb) into a buffer cache. A process can make a request to read a set of disk blocks into the buffer cache. There should be no access checking on this request, since reading blocks into the buffer cache does not -- in itself -- give access to the blocks in question. Likewise flushing/writing parts of the cache should be operations accessible by user processes, but it might be that we need some kind of access checking on these operations. When mapping a disk block from the buffer cache into application memory we need to check that the application is allowed to access the specified disk block. The real problem is that we don't want the disk block server to know anything about filesystems -- it should be easy for applications to define their own filesystem (performance-wise this is vital to an HTTP server for instance). If the server doesn't know anything about filesystems who do we check for access rights? IMHO the most interesting way of doing this is by using UDFs (untrusted determistic functions). In this section I do not consider file permissions (in the standard *NIX sense), but only explain how to ensure that disk blocks that aren't parts of any file can't be accessed. To define a filesystem applications upload a function 'owns()' -- written in a simple assembly-like language -- that can be verified to be deterministic. Once the function has been uploaded it cannot be changed. Given a disk block representing some kind of filesystem meta-data (such as inodes) the function should return the set of disk blocks the meta-data block refers to. To map a disk block from the buffer cache an application only has to prove that it has access to the meta-data block that refers to the disk block it wants to map. Normally the meta-data block will already be in the buffer cache, but in case it's not you just have to prove that you've got access to the (meta-)meta-data block that refers to the meta-data block, and so on. To make the process of proving terminate applications that need access to a filesystem simply has to have access to the root meta-data block. To create/extend files you'll have to modify meta-data blocks. The server cannot do this modification for you since it doesn't know enough about the meta-data (it only has the 'owns()' function) to alter it. To handle this situation the server allows applications to request a meta-data block modification by sending the (new) modified meta-data block along with a brief description of the change (such as "I've added disk block 17 to the set of blocks the meta-data refers to"). By running the 'owns()' function before and after the changes and comparing the resulting sets the server can verify that the modification indeed did add disk block 17 to the 'owns()' set. To allow maximum flexibility any process should be able to create a filesystem (by specifying the 'owns()' function). To keep filesystems across reboots (generally a good idea :-) the 'owns()' function should be saved on disk along with information on the location of the associated root meta-data block. /Kasper -- ------------------------------------------------------------------- Kasper Verdich Lund, Computer Science Department, Aarhus University Office: 34P.218 | Phone: (+45) 8942 5680 Email: ve...@da... | WWW: http://www.daimi.au.dk/~verdich |
|
From: Rogelio M. S. Jr. <ro...@ev...> - 2000-03-15 23:38:31
|
How do we protect blocks? By using a totally unpriviledged server which is more like a security monitor? exporting a low level interface with minimal abstractions? All it would do is manage capabilities to blocks. Nothing more. Then processes can do a pct to this server and carry out the request. This server would own all the io ports to the ide controller. But would this work for other kinds of hard disk? I could also think of programming the kernel. I would prefer this because it is more exo-ish than the first suggestion. This would require the kernel to compile handlers or device drivers given by a process requesting secure binding to the block device. This would allow the requesting process to access the block device controller the way it sees fit. The problem is security. I think one way we can do this, is for the kernel to examine the handler code and if it passes criteria, the io perm map of the requesting process could then be updated to allow access to block device controller and the handler code and relevant data mapped read-only in the process address space.This would all be a part of capability processing. This seems more complex because we have to use a compiler or interpreter and we have to design an interface for the driver code. I do not know how we can port existing drivers to this framework. How does the buffer cache mechanism on the MIT exokernel work? |
|
From: Kasper V. L. <ve...@da...> - 2000-03-15 20:44:46
|
> LemurOS ?? ;) > > armadillos > > cosmos > > infernos > > rhinoceros > > Taos > > volcanos > > > > I think my favourite has to be Taos (but that's just me and Taoism :) First of all there already is a system called Taos (http://www.uruk.org/emu/Taos.html), and secondly we only need a new name for the *kernel* -- not necessarily for the entire operating system, e.g. the name does not have to contain 'os' :-) /Kasper ------------------------------------------------------------------- Kasper Verdich Lund, Computer Science Department, Aarhus University Office: 34P.218 | Phone: (+45) 8942 5680 Email: ve...@da... | WWW: http://www.daimi.au.dk/~verdich |
|
From: Nick J. <ni...@na...> - 2000-03-15 20:23:58
|
what about 'Windows 1' :) or 'Torvaldix' or 'BestOS' or 'WinnerSystemOS'
serious suggestions:
Namodn
Yeaben
Horben
Niaj
Suffix
Nosif (nOSif)
but thats just me and my wierd made-up words. they hold no real dictionary
meaning.
LemurOS ?? ;)
On Wed, Mar 15, 2000 at 08:04:54PM +0000, Adam Langley wrote:
> On Tue, Mar 14, 2000 at 12:26:25PM +0100, Kasper Verdich Lund wrote:
> > - Gemini
> > - GNUcleus
> >
>
> Ok, well I suggest:
>
> egrep '.*os$' /usr/dict/words
>
> lets see (a selection):
>
> armadillos
> cosmos
> infernos
> rhinoceros
> Taos
> volcanos
>
> I think my favourite has to be Taos (but that's just me and Taoism :)
>
> AGL
>
> --
> Smoking is one of the leading causes of statistics.
--
- Nick Jennings
Email: ni...@na...
Web : http://nick.namodn.com
-
|
|
From: Adam L. <ag...@li...> - 2000-03-15 20:08:22
|
On Tue, Mar 14, 2000 at 12:26:25PM +0100, Kasper Verdich Lund wrote: > - Gemini > - GNUcleus >=20 Ok, well I suggest: egrep '.*os$' /usr/dict/words lets see (a selection): armadillos cosmos infernos rhinoceros Taos volcanos I think my favourite has to be Taos (but that's just me and Taoism :) AGL --=20 Smoking is one of the leading causes of statistics. |
|
From: Kasper V. L. <ve...@da...> - 2000-03-14 11:30:57
|
Hi, I'm working on an improved build environment for the 'new' kernel. I've only recently been introduced to 'automake' and 'autoconf', so I could probably use some help. Have a look at the environment -- and perhaps the code (borrowed from the Elysium kernel). The only thing that's present in the 'new' kernel at this moment is some debug printing facilities, but more will come in a few days. There's been two suggestions for naming the 'new' kernel: - Gemini - GNUcleus I'm not sure if we're allowed to put 'GNU' in the name, but I included it in my posting to inspire other -- better -- suggestions. /Kasper ------------------------------------------------------------------- Kasper Verdich Lund, Computer Science Department, Aarhus University Office: 34P.218 | Phone: (+45) 8942 5680 Email: ve...@da... | WWW: http://www.daimi.au.dk/~verdich |
|
From: Rogelio M. S. Jr. <ro...@ev...> - 2000-03-14 09:17:33
|
ok im joining i'll try to be more active this time Kasper Verdich Lund wrote: > > Why the merge? > > IMHO we need the few -- but good/active -- developers from the Apostle > project. > > > So how will the micro-kernel be like? Will it have a lower level interface than > > say mach or fluke? > > Much lower -- nothing like Mach or Fluke. > > > How exo-ish is it going to be? > > It's the current Elysium design. The current design is a 'micro-kernel > *based* exokernel' -- traditional micro-kernel aims for providing (and > enforcing) the best/right abstractions - we don't enforce any (at least > not any that aren't strictly necessary for protection). > > > I would rather stick to pure exo-principles. Im an exo nut. > > We will stick to pure exo-principles. The design of the 'new' kernel is > based on 100% pure exo-principles. I'm an exo-nut as well -- and I'm > sorry for not making that 100% clear in the previous posting. > > Let me make this clear once and for all: The Elysium *kernel* will > change name and become a separate project on SourceForge. The design > principles will *not* change, and most of the code already written will > be imported into the new project without modifications. In fact the most > important change will probably be that we'll be using 'autoconf' and > 'automake' for the makefiles, and that we'll have a few more developers > :-). > > > As for the code Im taking out my old exokernel code and revive it. I cant > > continue on developing the Elysium right? > > Of course you can :-) You just have to use > > cvs -d<something>@cvs.<somethingelse>.sourceforge.net co kernel > > instead of > > cvs -d<something>@cvs.elysium.sourceforge.net co kernel > > I'll keep you posted. > > /Kasper > > -- > ------------------------------------------------------------------- > Kasper Verdich Lund, Computer Science Department, Aarhus University > Office: 34P.218 | Phone: (+45) 8942 5680 > Email: ve...@da... | WWW: http://www.daimi.au.dk/~verdich > > _______________________________________________ > elysium-developers mailing list > ely...@li... > http://lists.sourceforge.net/mailman/listinfo/elysium-developers -- ----------------------------------------------------- Click here for Free Video!! http://www.gohip.com/freevideo/ |
|
From: Kasper V. L. <ve...@da...> - 2000-03-14 07:30:52
|
> Why the merge? IMHO we need the few -- but good/active -- developers from the Apostle project. > So how will the micro-kernel be like? Will it have a lower level interface than > say mach or fluke? Much lower -- nothing like Mach or Fluke. > How exo-ish is it going to be? It's the current Elysium design. The current design is a 'micro-kernel *based* exokernel' -- traditional micro-kernel aims for providing (and enforcing) the best/right abstractions - we don't enforce any (at least not any that aren't strictly necessary for protection). > I would rather stick to pure exo-principles. Im an exo nut. We will stick to pure exo-principles. The design of the 'new' kernel is based on 100% pure exo-principles. I'm an exo-nut as well -- and I'm sorry for not making that 100% clear in the previous posting. Let me make this clear once and for all: The Elysium *kernel* will change name and become a separate project on SourceForge. The design principles will *not* change, and most of the code already written will be imported into the new project without modifications. In fact the most important change will probably be that we'll be using 'autoconf' and 'automake' for the makefiles, and that we'll have a few more developers :-). > As for the code Im taking out my old exokernel code and revive it. I cant > continue on developing the Elysium right? Of course you can :-) You just have to use cvs -d<something>@cvs.<somethingelse>.sourceforge.net co kernel instead of cvs -d<something>@cvs.elysium.sourceforge.net co kernel I'll keep you posted. /Kasper -- ------------------------------------------------------------------- Kasper Verdich Lund, Computer Science Department, Aarhus University Office: 34P.218 | Phone: (+45) 8942 5680 Email: ve...@da... | WWW: http://www.daimi.au.dk/~verdich |
|
From: Rogelio M. S. Jr. <ro...@ev...> - 2000-03-13 23:14:10
|
Kasper Verdich Lund wrote: > Dear fellow developers, > > In a matter of days the Elysium Project is going to merge with the Apostle > Project. Please read the attachment following my signature. If you have any > questions/doubts regarding the merge please let me -- or at your option the > entire mailing list -- know. > > The plan is to combine our efforts to produce a GNU GPL'ed micro-kernel > (built on exokernel principles and the current Elysium design) suitable for > a wide variety of applications. As stated in the attachment the development > on the Elysium kernel will cease, but I expect to continue the Elysium > Project -- just for the sake of the name. The goal of the 'new' Elysium > Project will be to create an operating system environment based on the GNU > GPL'ed micro-kernel. > > We need a good name for the micro-kernel -- any good suggestions? > > /Kasper Why the merge? So how will the micro-kernel be like? Will it have a lower level inerface than say mach or fluke? How exo-ish is it going to be? I would rather stick to pure exo-principles. Im an exo nut. As for the code Im taking out my old exokernel code and revive it. I cant continue on developing the Elysium right? |
|
From: Kasper V. L. <ve...@da...> - 2000-03-13 13:23:25
|
Dear fellow developers, In a matter of days the Elysium Project is going to merge with the Apostle Project. Please read the attachment following my signature. If you have any questions/doubts regarding the merge please let me -- or at your option the entire mailing list -- know. The plan is to combine our efforts to produce a GNU GPL'ed micro-kernel (built on exokernel principles and the current Elysium design) suitable for a wide variety of applications. As stated in the attachment the development on the Elysium kernel will cease, but I expect to continue the Elysium Project -- just for the sake of the name. The goal of the 'new' Elysium Project will be to create an operating system environment based on the GNU GPL'ed micro-kernel. We need a good name for the micro-kernel -- any good suggestions? /Kasper ------------------------------------------------------------------- Kasper Verdich Lund, Computer Science Department, Aarhus University Office: 34P.218 | Phone: (+45) 8942 5680 Email: ve...@da... | WWW: http://www.daimi.au.dk/~verdich ----- Original Message ----- From: "Guido de Jong" <gu...@dd...> To: "Apostle Developers" <apo...@li...> Sent: Sunday, March 12, 2000 11:11 PM Subject: [apostle-developers] Apostle + Elysium = ? > Hi all! > > As you might know, Kasper (Apostle Project administrator "verdich"), is > also working on another OS project called Elysium. This weekend Kasper > and I (being the two most active developers of Apostle and Elysium) got > together digitally to discuss merging Apostle and Elysium. We agreed > that in stead of building two competing systems it would be better to > combine our efforts. It means that we will have a working system a lot > faster, for which - correct me if I'm wrong - most of you are really > waiting. > > We intend to create a whole new project on SourceForge for the kernel > development. Later on we will create another project containing > libraries/drivers and such. This also means that the development for > Apostle (and Elysium) will stop once we have our new project going. All > current developers are encouraged to join our new project. > > At this point, the biggest problem we are facing is a name for the new > kernel project. We thought that you might actually have some good ideas > for a name. So please feel free to make any suggestions! > > Guido > > _______________________________________________ > apostle-developers mailing list > apo...@li... > http://lists.sourceforge.net/mailman/listinfo/apostle-developers > |
|
From: Claus M. <cla...@ma...> - 2000-03-05 21:08:31
|
> As our project progresses, the need for a more advanced interaction > mechanism than a single-line command interpreter with only predefined > commands and no backspace becomes obvious. As implementing a normal > WIMP-style window manager on top of Elysium would be somewhat unimaginative, > Kasper Lund, Jakob Andersen and myself have been discussing user-interaction > techniques for some time. Especially the work by Michel Beaudouin-Lafon has > inspired our discussions, and since Kasper on a daily basis actually works > on implementing a CPN-editor based on Michels work we have had an excellent > chance to watch a post-WIMP system in action. > > WIMP stands for "Windows, Icons, Menus and Pointing" and is a result of the > Xerox Star system from the early eighties. WIMP is the system we associate > with a graphical interface today - System X, X/Motif and Windows are all > WIMP-style graphical interfaces. The main problem with such interfaces are > that the complex tasks they are able to perform result in quite large > amounts of screen real estate are occupied by Icons, task bars and suchlike. > What we want is a system that uses Direct Manipulation more efficiently than > today's interfaces, meaning that whenever we want to interact with an > object - a sheet of paper, for instance - the interaction does to a lesser > extend rely on icons, menus and dialogue boxes and more on actually > manipulating the document itself. When you want to change the font on a > subset of the text for example, this should be done by manipulating the text > directly instead of pressing an "italics" button. Various techniques have > been evolved to facilitate this, and some are used today in special > applications such as "Maya" but they lack a full-scale window-manager > implementation. > > To implement such a system using a traditional 2d-graphics library is > tedious and it seems that it would be very efficient to implement it in > OpenGL. OpenGL has many great adventages, none of which is being easy to > implement, and thus it would be a great help if we could adapt an already > existing driver model to our needs. It seems that the new DRI driver model > used in the upcoming xfree 4.0 (development release 3.9.18 is the latest > alpha) might suit these needs. Kasper has promised to look into what it > would take to make a DRI loader and if it seems that it is possible to use > the format, I would very much like some help in implementing such a loader. > Not because it is a great task (hopefully it isn't), but because I really > need it for further development of the user interface so I have something to > post for public comment. > > As always, I am looking forward to your comments > > - xmentor > |
|
From: Adam L. <ag...@li...> - 2000-03-05 17:01:08
|
On Sun, Mar 05, 2000 at 05:07:29PM +0100, Kasper Verdich Lund wrote:
<snip>
This looks about right, except:
> Restricting Capability Use
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D
> There might be situations where a process wants to give a capability to
> another process, but wants to make sure that the capability cannot be
> duplicated or transferred. By extending the capability data structure to
> with a cap_perm field it's possible to handle this situation. The
> sys_duplicate_cap() might be rewritten to something like:
>=20
> int
> sys_duplicate_cap(uint32_t ci, uint32_t nperm, uint32_t nci)
> {
> <<check that (C-list[ci].cap_perm & CAP_PERM_DUPLICABLE) !=3D 0>>
> <<.... as before ....>>
This is against the principle of capabilitys. If you give something a capab=
ility you trust it to use it. You thus trust it not to pass it on. I don't =
think this is needed
>=20
> of I/O ports we need to make sure that the (id,type,owner) tuple reveals
> the exact range of I/O ports in a simple way.
Given that the only think a kernel knows about a capability is in the cap s=
tructure, we can't fail to do this, unless we use weird lookup tables. if w=
e do, we must allow them to be mapped (read-only)
AGL
--=20
Smoking is one of the leading causes of statistics.
|
|
From: Kasper V. L. <ve...@da...> - 2000-03-05 16:12:56
|
Capabilities
============
Capabilities are stored in C-lists and protected by means of paging.
It's possible to map the C-list of any process read-only, but always
impossible to map read/write. Under Elysium a capability is represented
with the following data structure:
typedef struct cap_s
{
uint32_t obj_id;
uint32_t obj_type;
uint32_t obj_perm;
pid_t obj_owner;
} cap_t;
If the obj_owner field is 0 the capability refers to kernel objects,
otherwise it refers to objects created - and managed - by the process
with the given pid.
Kernel Objects
==============
The objects the kernel manages are:
* physical pages
* I/O ports
* CPU quanta
* ... what else?
Given access to a kernel object it's possible to create a capability
that allows access to the object. As an example of a system call
creating capabilities consider this system call that creates a
capability for a single physical page:
int
sys_create_page_cap(uint32_t pn, void *vptr, uint32_t ci)
{
<<check that the virtual address vptr
refers to the physical page pn in the current
address space>>
<<create cap c with id = pn, type = OBJ_TYPE_PAGE,
perm = OBJ_PERM_READ | OBJ_PERM_WRITE, and
owner = 0>>
<<insert cap c into current C-list at index ci>>
}
Server Objects
==============
Any process can create any (PRIVATE) capability as long as the obj_owner
field refers to the pid of the process. Consider the following system
call for doing just that:
int
sys_create_private_cap(uint32_t id, uint32_t type, uint32_t perm,
uint32_t ci)
{
<<create cap c with id = id, type = type, perm = perm,
and owner = current_process->pid>>
<<insert cap c into current C-list at index ci>>
}
Transferring Capabilities
=========================
It should be possible to give a capability to another process. One way
of doing this is extending the PCT mechanism to handle transferring a
single capability. The transferred capability could be put in the CPU
context, and accessible through the following system call:
int
sys_acquire_cap(uint32_t ci)
{
<<check the CPU context for a capability>>
<<get capability c from CPU context>>
<<insert cap c into current C-list at index ci>>
}
This system call only makes sense to call from a PCT handler - and only
in the situation where a capability was transferred.
Duplicating Capabilities
========================
Given a capability it should be possible to duplicate it (and maybe
restricting the access rights). The following system call should do the
trick:
int
sys_duplicate_cap(uint32_t ci, uint32_t nperm, uint32_t nci)
{
<<check that nperm is a subset of c-list[ci].perm>>
<<create new cap nc with id = C-list[ci].id, ...,
and perm = nperm>>
<<insert cap nc into C-list at index nci>>
}
Restricting Capability Use
==========================
There might be situations where a process wants to give a capability to
another process, but wants to make sure that the capability cannot be
duplicated or transferred. By extending the capability data structure to
with a cap_perm field it's possible to handle this situation. The
sys_duplicate_cap() might be rewritten to something like:
int
sys_duplicate_cap(uint32_t ci, uint32_t nperm, uint32_t nci)
{
<<check that (C-list[ci].cap_perm & CAP_PERM_DUPLICABLE) != 0>>
<<.... as before ....>>
}
Exo Considerations
==================
When using capabilities for allowing access to physical resources it's
really important that the (id,type,owner) tuple doesn't hide the
physical name of the resource. In the case of physical pages - for
instance - the id should encode the physical page number. For most
resources this is quite trivial, but a capability representing a range
of I/O ports we need to make sure that the (id,type,owner) tuple reveals
the exact range of I/O ports in a simple way.
The reason for exposing physical names of resources to applications is
that the physical names typically encode vital information for efficient
management. Consider disk blocks for a moment. A disk block number
encodes the physical position - the most important disk block property
performance-wise.
/Kasper
--
-------------------------------------------------------------------
Kasper Verdich Lund, Computer Science Department, Aarhus University
Office: 34P.218 | Phone: (+45) 8942 5680
Email: ve...@da... | WWW: http://www.daimi.au.dk/~verdich
|
|
From: Kasper V. L. <ve...@da...> - 2000-03-02 13:11:35
|
Adam Langley wrote: > The buffer cache not only fills up, it dynamically resizes. If there is any > free memory the buffer cache should eat it, and as soon as their is any > memory pressure the BC should shrink. > > I think (if we allow processes to map the BC) that we possibly must walk > page tables and remove mappings (Ouch!) It should be impossible to map the entire BC - you should only be allowed to map disk blocks that you can prove you have access to. We might consider keeping a reverse page mapping function in the kernel (should be accessible read-only from user-space). Given a physical page, p, the function should return the set of virtual addresses - and corresponding address spaces - that map p. /Kasper -- ------------------------------------------------------------------- Kasper Verdich Lund, Computer Science Department, Aarhus University Office: 34P.218 | Phone: (+45) 8942 5680 Email: ve...@da... | WWW: http://www.daimi.au.dk/~verdich |
|
From: Adam L. <ag...@li...> - 2000-03-01 20:05:55
|
On Wed, Mar 01, 2000 at 04:20:06PM +0100, Kasper Verdich Lund wrote: > We still need to figure out what to do when the buffer cache gets filled > up.=20 The buffer cache not only fills up, it dynamically resizes. If there is any free memory the buffer cache should eat it, and as soon as their is any memory pressure the BC should shrink. I think (if we allow processes to map the BC) that we possibly must walk page tables and remove mappings (Ouch!) If we keep BC linear we could protect it with segmentation (e.g. just shrin= k the segment and tell processes) This means more TLB entries. It also means less-then-100% BC. If A real 'go= od' (that means often accessed) page is at the beginning of the BC, then th= at page might have to be copied when BC is shrunk. Comments? AGL --=20 Smoking is one of the leading causes of statistics. |
|
From: Adam L. <ag...@li...> - 2000-03-01 19:56:33
|
Just to note - I haven't been hit by a bus ;) (and you should run, not walk= , to segfault.org about that ;) its One Of Those Weeks (tm), I'll start acting like someone alive just as s= oon as I can. AGL --=20 Smoking is one of the leading causes of statistics. |
|
From: Kasper V. L. <ve...@da...> - 2000-03-01 15:23:53
|
I've been looking at the XN code, and it seems that it uses a disk block size that's equal to the hardware page size (e.g. 4kb). The only problem with this approach is that it gives us quite a lot of internal fragmentation, but harddisks are quite cheap anyhow... The role of the disk block server is then to[1]: * load harddisk blocks into the buffer cache * allow mapping cached blocks into application address spaces * commit cached blocks to the harddisk The applications will implement their own filesystem(s) on top of this. We still need to figure out what to do when the buffer cache gets filled up. /Kasper [1] Please note that this is just the role of the initial - unprotected - disk block server. Later we'll put restrictions on which cached blocks can be mapped into application address spaces, but for now it should do the trick. -- ------------------------------------------------------------------- Kasper Verdich Lund, Computer Science Department, Aarhus University Office: 34P.218 | Phone: (+45) 8942 5680 Email: ve...@da... | WWW: http://www.daimi.au.dk/~verdich |
|
From: Rogelio M. S. Jr. <ro...@ev...> - 2000-03-01 03:20:35
|
>If capabilities are to reside in - unprotected - user space we'll need
>to use encryption, but AFAIK revocation isn't easier with encrypted
>capabilities than with clists in kernel space (IMHO it would be easier
>with the kernel controlled clists).
>
>/Kasper
OK I see it now. We don't have other abstactions to use like "ports" in
Amoeba and we would have a problem with randomizers and seeds and all.
And encrypion would need to use lengthy computations to be secure.
Quote from AGL:
_____________________________________________________
Well, I'd suggest using real 'capabilites', not EARs.
Let me try something like this:
struct cap {
int obj_type;
int obj_id;
int obj_meth;
int access;
};
'int' might not be the right datatype for some of these, but that's not
important right now. This system encodes an object and an access. The
@acce=
ss
field would be a bitmap like:
#define CAP_READ 1 << 0
#define CAP_WRITE 1 << 1
#define CAP_DELETE 1 << 2
#define CAP_APPEND 1 << 3
etc...
The @obj_type would be something like process, mem_page, I/O port etc.
The=
=20
@obj_id would define the actual process, memory page or port etc. The=20
@obj_meth would be one more level (like the method of a server).
A process would be granted capabilies when it started, in well known
table
indexes. Like STDIN, STDOUT and STDERR are fd 0, 1 and 2 in *NIX.=20
Lets say a process wanted to give another read-access to one of it's
pages.=
It
would make a capability.
obj_type =3D CAP_MEMPAGE
obj_id =3D <the page number>
obj_meth =3D 0 /* Not used */
obj_access =3D CAP_READ
It would then send this to the kernel. The kernel would check that it
had *=
at
least* read access to the page, and give it the capability (returning
the i=
ndex
id). It could then give the capability to the other process, like you
descr=
ibe.
For another example: a server.
The server generates the capability:
obj_type =3D CAP_PROCESS
obj_id =3D get_pid()
obj_meth =3D MY_SERVER_METHOD_READ;
access =3D CAP_READ | CAP_WRITE
It could then give the capabilites to any process it wants. When they do
a =
PCT,
they (via the kernel) present the capability. The server checks the
obj_met=
h and
access fields and does the requested work.
This (IMHO) is a far better system. I would recommend this paper:
http://www.eros-os.org/essays/capintro.html
As good reading.
AGL
_______________________________________________________
I Agree:
Thus:
a.The c-list would be in read-only in shared space.
b.The capability key-ring is also read-only in processes, modifiable
only by the kernel.
RMSJ
|
