secure

Simon Willcocks

Security within the Isembard kernel has to do with the data integrity of [maps]; data and code in one map is protected from code in all other maps, unless the program in the map chooses to make some of itself available to other maps.

In other words, a [map] can protect itself from malicious activities by providing a minimal interface to the outside world and only exporting objects to trusted clients.

"Leaking" of information between maps and threads over a context switch may occur in the initial (and later speed-optimised) builds, but that can be dealt with later.

When making an inter-map call, the caller may pass two simple numeric (32-bit) values to the called map, and receive one simple numeric (32-bit) value back. The kernel does not concern itself with the values being passed.

If the semantics of the interface define any of these values as being exports, the value can be verified as being a valid export using the [validate_object] [system call]. The value must not be used as an export until it has been validated.

In order for the validation to succeed, the export must be owned by the validating map. (A client export is passed to the system call to create an export to define the owner of new export.)

Trying to use an export before it has been validated, or validating an already validated export will throw an exception.


Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks