Here's a thorough overview of security considerations in the design and implementation of XukutOS:
* XukutOS does not include source code that I personally do not trust.
* XukutOS does not have any networking capability worthy of mention, so it cannot steal your data in a way that matters.
* Er...
* That's it.
Put in other words, if you have anything important that depends on XukutOS's ability to stop your computer from doing any specific thing, you are screwed already, and there's no way I can help you.
Moreover, security in the traditional sense (the creators of the software on your computer ensuring the computer cannot do anything on their list of Bad Things) is pretty much an antifeature in XukutOS's context. If you want total control over your computation, then letting someone else decide that certain things are not allowed, is basically the opposite of that.
That said, many security issues are just normal bugs that have extra bad consequences. We don't want a misbehaving process to bring down the whole system, or at least that shouldn't happen too often, or at least not when we can prevent it from happening. Here are a couple of specific changes that could count as security fixes, and definitely fall in line with the goals of XukutOS:
* Processes, including the kernel, shouldn't share one memory allocator that they can mess up by forgetting to use the correct concurrent operations.
* The kernel should do more than zero validity checks on its input, and should not panic when something does go wrong (instead it should make the offending process crash).
* Stack overflows should be caught and handled gracefully.
* Processes should not be able to grab all processor time by waiting for a timestamp in the past.
* Everything should not share a single memory space, or at least less-trusted code should run in a sandboxed-ish memory space.
* Operations that require locks should test that the lock is held, and locking operations should test for deadlocks.
Any questions? Contact me:
By email at vierkantor@vierkantor.com