Skip to content

Commit

Permalink
Merge branch 'master' of https://github.com/CosmosOS/Cosmos into mkis…
Browse files Browse the repository at this point in the history 
…ofs-merged

Conflicts:
	.gitignore
  • Loading branch information
@tgiphil
tgiphil committed Dec 7, 2014
2 parents ca7b9aa + 2099f75 commit 447c050
Show file tree
Hide file tree
Showing 425 changed files with 3,477 additions and 2,858 deletions.
4 changes: 4 additions & 0 deletions .gitignore
View file
Original file line number Diff line number Diff line change
Expand Up @@ -31,10 +31,14 @@
*.mdb
*.docstates
*.vsp
*.pdb
Thumbs.db
build.force

Build/VSIP/
Setup/Output/
Build/VMWare/Workstation/Cosmos.vmsd
Build/VMWare/Workstation/Cosmos.vmxf

Setup/Current.iss
Cosmos.Assembler.Log
10 changes: 0 additions & 10 deletions Demos/Guess/Guess.Cosmos.vspscc
View file

This file was deleted.

10 changes: 0 additions & 10 deletions Demos/Guess/GuessKernel.csproj.vspscc
View file

This file was deleted.

148 changes: 91 additions & 57 deletions Docs/Kernel/Levels.html
View file
Original file line number Diff line number Diff line change
Expand Up @@ -7,130 +7,164 @@
<body>

<p>
The security model of&nbsp; Cosmos will evolve and mature as Cosmos does, however the base model is presented here.</p>
The security model of&nbsp; Cosmos will evolve and mature as Cosmos does, however the base model is presented here.
</p>
<h3>
Goals</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>
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>
Future
</h3>
<p>
Currently only the structure exists, no checking occurs but in the future will occur via attributes and other methods. Future checks to include:</p>
Currently only the structure exists, no checking occurs but in the future will occur via attributes and other methods. Future checks to include:
</p>
<ol>
<li>Restriction of core level exclusive abilities at the assembly level by attribute.</li>
<li>Restriction of references list to higher levels only. ie HAL can reference Core but not vice versa. Also via attribute. That is an assembly level attribute to mark which level an assembly is.</li>
<li>Restrict access to BCL and other assemblies. ie Core should never need XML or other higher level services. Make a defined list of what is allowed and verify against it.</li>
<li>Restriction of core level exclusive abilities at the assembly level by attribute.</li>
<li>Restriction of references list to higher levels only. ie HAL can reference Core but not vice versa. Also via attribute. That is an assembly level attribute to mark which level an assembly is.</li>
<li>Restrict access to BCL and other assemblies. ie Core should never need XML or other higher level services. Make a defined list of what is allowed and verify against it.</li>
</ol>
<p>
For now we must be vigilant to watch these restrictions manually.</p>
For now we must be vigilant to watch these restrictions manually.
</p>
<h3>
Levels</h3>
Levels
</h3>
<p>
Many operating systems refer to their security &quot;areas&quot; 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 &quot;areas&quot; as levels.</p>
Many operating systems refer to their security &quot;areas&quot; 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 &quot;areas&quot; as levels.
</p>
<p>
Cosmos is split into the following levels:</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>
<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>
Each level can only communicate with adjacent levels. That is User can only talk to System, but not Core.
</p>
<h3>0 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>
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 abilities that core has exclusively:</p>
Special abilities that core has exclusively:
</p>
<ol>
<li>Assembly plugs</li>
<li>Assembly plugs</li>
</ol>
<p>
Core 0 exists to provide access to direct hardware. C# code should mostly exist in level 1 instead, with level 0 being intended for code that can exist only in level 0 such as assembly code.</p>
Core 0 exists to provide access to direct hardware. C# code should mostly exist in level 1 instead, with level 0 being intended for code that can exist only in level 0 such as assembly code.
</p>
<p>
Examples:</p>
Examples:
</p>
<ol>
<li>Plugs that must be implemented in assembly</li>
<li>Memory management</li>
<li>Direct generic IO access to map to C# functions</li>
<li>Plugs that must be implemented in assembly</li>
<li>Memory management</li>
<li>Direct generic IO access to map to C# functions</li>
</ol>
<h3>1 HAL (Hardware) Level</h3>
<p>
From the HAL (hardware abstraction level) 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>
From the HAL (hardware abstraction level) 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>
<p>
HAL in some senses might be thought of as a sub level of level 0, but exists to help separate assembly and other such code. HAL must not simply proxy access to code. For example, level 0 will expose functions to directly access IO ports, but level 2 should never be able to perform such raw access. HAL must wrap and encapselate such access. For example, instead of proxying access to a specific port drivers exists in HAL to expose access to a specific device such as an IDE controller.</p>
HAL in some senses might be thought of as a sub level of level 0, but exists to help separate assembly and other such code. HAL must not simply proxy access to code. For example, level 0 will expose functions to directly access IO ports, but level 2 should never be able to perform such raw access. HAL must wrap and encapselate such access. For example, instead of proxying access to a specific port drivers exists in HAL to expose access to a specific device such as an IDE controller.
</p>
<p>
Examples:</p>
Examples:
</p>
<ol>
<li>Hardware specific drivers - any code that needs to talk to hardware via core.0.</li>
<li>Hardware specific drivers - any code that needs to talk to hardware via core.0.</li>
</ol>
<h3>2 System Level</h3>
<p>System level contains all such code that is not wrapping hardware directly but instead adding higher level functionality. ie file systems, etc. The distinction between level 1 and 2 is a manual one and no technical restrictions currently exist aside from the restriction of higher level reference only.</p>
<p>System.2 should not contain system applications, but instead system functionality.</p>
<p>Examples:</p>
<ol>
<li>File systems</li>
<li>BCL plugs</li>
<li>Network stacks</li>
<li>File systems</li>
<li>BCL plugs</li>
<li>Network stacks</li>
</ol>
<h3>3 User Level</h3>
<p>
No Cosmos.3.User project exists because level 3 is user code. ie applications. When a user creates a new application (or currently monolithic project) the code is level 3.</p>
No Cosmos.3.User project exists because level 3 is user code. ie applications. When a user creates a new application (or currently monolithic project) the code is level 3.
</p>
<p>
Examples:</p>
Examples:
</p>
<ol>
<li>User applications</li>
<li>System applications</li>
<li>User applications</li>
<li>System applications</li>
</ol>
<p>
We considered adding a special "playground" ring, which is able to do more. This would aid in adding new code in playground which is targetted at System level. However,
this adds a possibility you functionally don't really need: You only need to add 1 or maybe 2 extra projects, but this give you the physical separation from the start,
preventing you to make circular references.
</p>
<h1>
Older Ring Docs</h1>
Older Ring Docs
</h1>
<h3>
Core Ring</h3>
Core Ring
</h3>
<p>
In the core ring, &quot;anything goes&quot;. This also means that code which does not
require such privileges should not exist in the core ring. The core ring should
In the core ring, &quot;anything goes&quot;. 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>
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>
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>
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>
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>
Hardware Ring
</h3>
<p>
The hardware ring contains drivers and code for accessing hardware via more
generic objects exposed by the kernel ring.</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>
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>

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>

</body>
</html>
Binary file added Resources/Dependencies/ILSpy/ICSharpCode.AvalonEdit.dll
View file
Binary file not shown.
Binary file added Resources/Dependencies/ILSpy/ICSharpCode.Decompiler.dll
View file
Binary file not shown.
Binary file added Resources/Dependencies/ILSpy/ICSharpCode.NRefactory.CSharp.dll
View file
Binary file not shown.
Binary file added Resources/Dependencies/ILSpy/ICSharpCode.NRefactory.VB.dll
View file
Binary file not shown.
Binary file added Resources/Dependencies/ILSpy/ICSharpCode.NRefactory.dll
View file
Binary file not shown.
Binary file added Resources/Dependencies/ILSpy/ICSharpCode.TreeView.dll
View file
Binary file not shown.
Binary file added Resources/Dependencies/ILSpy/ILSpy.BamlDecompiler.Plugin.dll
View file
Binary file not shown.
Binary file added Resources/Dependencies/ILSpy/ILSpy.exe
View file
Binary file not shown.
48 changes: 48 additions & 0 deletions Resources/Dependencies/ILSpy/ILSpy.exe.config
View file
Original file line number Diff line number Diff line change
@@ -0,0 +1,48 @@
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<startup>
<supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.0,Profile=Client" />
</startup>
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<!-- The redirects allow using AddIns with a different ILSpy version than they were compiled against. -->
<!-- No guarantee they'll work correctly, though (there might be breaking API changes in ILSpy). -->
<dependentAssembly>
<assemblyIdentity name="ICSharpCode.TreeView" publicKeyToken="d4bfe873e7598c49" culture="neutral"/>
<bindingRedirect oldVersion="4.1.0.0-99.9.9.9" newVersion="4.2.0.8752"/>
</dependentAssembly>
<dependentAssembly>
<assemblyIdentity name="ICSharpCode.AvalonEdit" publicKeyToken="9cc39be672370310" culture="neutral"/>
<bindingRedirect oldVersion="4.1.0.0-99.9.9.9" newVersion="4.2.0.8752"/>
</dependentAssembly>
<dependentAssembly>
<assemblyIdentity name="ICSharpCode.NRefactory" publicKeyToken="d4bfe873e7598c49" culture="neutral"/>
<bindingRedirect oldVersion="5.0.0.0-99.9.9.9" newVersion="5.0.0.0"/>
</dependentAssembly>
<dependentAssembly>
<assemblyIdentity name="ICSharpCode.NRefactory.CSharp" publicKeyToken="d4bfe873e7598c49" culture="neutral"/>
<bindingRedirect oldVersion="5.0.0.0-99.9.9.9" newVersion="5.0.0.0"/>
</dependentAssembly>
<dependentAssembly>
<assemblyIdentity name="ICSharpCode.NRefactory.VB" publicKeyToken="d4bfe873e7598c49" culture="neutral"/>
<bindingRedirect oldVersion="5.0.0.0-99.9.9.9" newVersion="5.0.0.0"/>
</dependentAssembly>
<dependentAssembly>
<assemblyIdentity name="ICSharpCode.Decompiler" publicKeyToken="d4bfe873e7598c49" culture="neutral"/>
<bindingRedirect oldVersion="1.0.0.0-99.9.9.9" newVersion="2.2.0.1706"/>
</dependentAssembly>
<dependentAssembly>
<assemblyIdentity name="ILSpy" publicKeyToken="d4bfe873e7598c49" culture="neutral"/>
<bindingRedirect oldVersion="1.0.0.0-99.9.9.9" newVersion="2.2.0.1706"/>
</dependentAssembly>
<dependentAssembly>
<assemblyIdentity name="Mono.Cecil" publicKeyToken="0738eb9f132ed756" culture="neutral"/>
<bindingRedirect oldVersion="0.0.0.0-99.9.9.9" newVersion="0.9.5.0"/>
</dependentAssembly>
<dependentAssembly>
<assemblyIdentity name="Mono.Cecil.Pdb" publicKeyToken="0738eb9f132ed756" culture="neutral"/>
<bindingRedirect oldVersion="0.0.0.0-99.9.9.9" newVersion="0.9.5.0"/>
</dependentAssembly>
</assemblyBinding>
</runtime>
</configuration>
Binary file added Resources/Dependencies/ILSpy/Mono.Cecil.Pdb.dll
View file
Binary file not shown.
Binary file added Resources/Dependencies/ILSpy/Mono.Cecil.dll
View file
Binary file not shown.
1 change: 0 additions & 1 deletion Resources/Dependencies/Mosa/..svnbridge/Mosa.Utility.IsoImage.dll
View file

This file was deleted.

5 changes: 0 additions & 5 deletions TeamProjectConfig/TeamProject.config
View file

This file was deleted.

10 changes: 0 additions & 10 deletions Users/BlueSkeye/GuessForBochs/GuessForBochs.Cosmos.vspscc
View file

This file was deleted.

9 changes: 0 additions & 9 deletions Users/Clearosdev/StandAloneDebug/StandAloneDebug.sln
View file
Original file line number Diff line number Diff line change
Expand Up @@ -4,15 +4,6 @@ Microsoft Visual Studio Solution File, Format Version 11.00
Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "StandAloneDebug", "StandAloneDebug\StandAloneDebug.csproj", "{C9C9EA4D-587F-48E4-B207-792F21886A92}"
EndProject
Global
GlobalSection(TeamFoundationVersionControl) = preSolution
SccNumberOfProjects = 2
SccEnterpriseProvider = {4CA58AB2-18FA-4F8D-95D4-32DDF27D184C}
SccTeamFoundationServer = https://tfs.codeplex.com/tfs/tfs04
SccLocalPath0 = .
SccProjectUniqueName1 = StandAloneDebug\\StandAloneDebug.csproj
SccProjectName1 = StandAloneDebug
SccLocalPath1 = StandAloneDebug
EndGlobalSection
GlobalSection(SolutionConfigurationPlatforms) = preSolution
Debug|x86 = Debug|x86
Release|x86 = Release|x86
Expand Down
10 changes: 0 additions & 10 deletions Users/Clearosdev/StandAloneDebug/StandAloneDebug/StandAloneDebug.csproj.vspscc
View file

This file was deleted.

10 changes: 0 additions & 10 deletions Users/EdNutting/EdNuttingsTest/EdNuttingsTest.csproj.vspscc
View file

This file was deleted.

10 changes: 0 additions & 10 deletions Users/EdNutting/EdNuttingsTest/EdNuttingsTestBoot.Cosmos.vspscc
View file

This file was deleted.

10 changes: 0 additions & 10 deletions Users/Geramy/GeramyLovelessTest/GeramyLovelessTest.csproj.vspscc
View file

This file was deleted.

10 changes: 0 additions & 10 deletions Users/Geramy/GeramyLovelessTest/GeramyLovelessTestBoot.Cosmos.vspscc
View file

This file was deleted.

Loading

0 comments on commit 447c050

Please sign in to comment.