mirror of
https://github.com/danbulant/Cosmos
synced 2026-05-21 21:38:52 +00:00
147 lines
6 KiB
HTML
147 lines
6 KiB
HTML
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
|
|
|
|
<html xmlns="http://www.w3.org/1999/xhtml">
|
|
<head>
|
|
<title></title>
|
|
</head>
|
|
<body>
|
|
|
|
<p>
|
|
The security model of Cosmos will evolve and mature as Cosmos does, however the base model is presented here.</p>
|
|
<h3>
|
|
Goals</h3>
|
|
<p>
|
|
Most operating systems today use hardware to enforce security between the kernel, user code, etc. This creates a lot of overhead at runtime and decreases performance. Intel CPUs have built this into the hardware, but adds a fair bit of circuitry and complexity. Despite being in hardware, it still incurs a measureable performance penalty. Since Cosmos can control execution and rebuild its compiler and recompile all code at any time, Cosmos can be much more flexible and most restrictions can be enforced at compile or installation time rather than the need to perform such CPU checks in live CPU code. This creates huge performance gains but also allows a lot more flexibility.</p>
|
|
<h3>
|
|
Future</h3>
|
|
<p>
|
|
Currently only the structure exists, no checking occurs but in the future will occur via attributes and other methods.</p>
|
|
<h3>
|
|
Levels</h3>
|
|
<p>
|
|
Many operating systems refer to their security "areas" as rings. ie Kernel ring, etc. Rings are harder to draw in text and make diagramming a bit harder, so for now we will refer to our "areas" as levels.</p>
|
|
<p>
|
|
Cosmos is split into the following levels:</p>
|
|
<ul>
|
|
<li>0 Core</li>
|
|
<li>1 Hardware</li>
|
|
<li>2 System</li>
|
|
<li>3 User</li>
|
|
</ul>
|
|
<p>
|
|
Each level can only communicate with adjacent levels. That is User can only talk to System, but not Core.</p>
|
|
<h3>Core Level</h3>
|
|
<p>
|
|
Core level has special permissions which basically let it do anyting it wants. core code should be very limited with most kernel code existing in the System level. Core code should be kept to a minimum with code not requiring special permissions should be moved or split into the system level.</p>
|
|
<p>
|
|
Special permissions that core has exclusively:</p>
|
|
<ol>
|
|
<li>Assembly plugs</li>
|
|
</ol>
|
|
<h3>Hardware Level</h3>
|
|
<h3>System Level</h3>
|
|
<p>
|
|
From the system level up, none of the special permissions available in core level are available. If such code is needed, it must be split between system and core.</p>
|
|
<h3>User Level</h3>
|
|
<p>
|
|
</p>
|
|
<h3>Namespace</h3>
|
|
<p>
|
|
</p>
|
|
<h1>
|
|
Older Ring Docs</h1>
|
|
<p>
|
|
Surely our security model will evolve as Cosmos evolves. However we need
|
|
something simple, efficient, and with minimal impact to the users. I feel this
|
|
is something most operating systems today fail greatly at.</p>
|
|
<p>
|
|
A new assembly level attribute will be created for processing by IL2CPU. If the
|
|
attribute is not present User Ring is the default.</p>
|
|
<p>
|
|
Rings from highest to lowest:</p>
|
|
<ul>
|
|
<li>User<ul>
|
|
<li>System<ul>
|
|
<li>Hardware<ul>
|
|
<li>Core</li>
|
|
</ul>
|
|
</li>
|
|
</ul>
|
|
</li>
|
|
</ul>
|
|
</li>
|
|
</ul>
|
|
<h3>
|
|
Ring Control</h3>
|
|
<p>
|
|
Rings can only access assemblies in the same ring, or the next lower ring.</p>
|
|
<p style="margin-left: 40px">
|
|
Core <-- Hardware <-- System <-- User</p>
|
|
<p>
|
|
For example, System can consume classes in Hardware but not Kernel.</p>
|
|
<h3>
|
|
Core Ring</h3>
|
|
<p>
|
|
In the core ring, "anything goes". This also means that code which does not
|
|
require such privileges should not exist in the core ring. The core ring should
|
|
be restricted to code which truly needs such unfettered access.
|
|
</p>
|
|
<p>
|
|
Priviliges that exist only in the core ring:</p>
|
|
<ul>
|
|
<li>Use of pointers and direct access to memory</li>
|
|
<li>Access to x86 IO ports.</li>
|
|
<li>Explicit assembly language code</li>
|
|
<li>Unsafe code</li>
|
|
</ul>
|
|
<p>
|
|
The core ring includes functionality such as:</p>
|
|
<ul>
|
|
<li>Threading</li>
|
|
<li>Memory management</li>
|
|
</ul>
|
|
<p>
|
|
Assemblies which are part of the core are restricted.</p>
|
|
<p>
|
|
The core ring exposes objects which allow the hardware ring to access memory
|
|
indirectly, and in a controlled restricted fashion. For example to allow a
|
|
driver to acccess video RAM, a memory object can be created by the core ring
|
|
which allows access to only the specific block of memory needed by the video
|
|
driver.</p>
|
|
<h3>
|
|
Hardware Ring</h3>
|
|
<p>
|
|
The hardware ring contains drivers and code for accessing hardware via more
|
|
generic objects exposed by the kernel ring.</p>
|
|
<p>
|
|
The hardware ring includes functionality such as:</p>
|
|
<ul>
|
|
<li>IDE</li>
|
|
<li>SATA</li>
|
|
<li>Ethernet</li>
|
|
<li>USB Controller</li>
|
|
</ul>
|
|
<p>
|
|
The hardware ring may be further split into two levels at a later date. For
|
|
example, a driver may exist for the USB Controller and it would require access
|
|
to the core ring. But drivers implementing USB devices do not need to talk to
|
|
hardware directly, but instead talk to the USB Controller driver.</p>
|
|
<h3>
|
|
System Ring</h3>
|
|
<p>
|
|
The system ring contains code which builds functionality on top of hardware or
|
|
other system assemblies.</p>
|
|
<p>
|
|
The system ring includes functionality such as:</p>
|
|
<ul>
|
|
<li>File systems</li>
|
|
<li>TCP/IP</li>
|
|
</ul>
|
|
<h3>
|
|
User Ring</h3>
|
|
<p>
|
|
The user ring is compromised of all user code including applications and
|
|
services.</p>
|
|
|
|
</body>
|
|
</html>
|