On Sunday, 5 March 2017 at 11:48:23 UTC, Jacob Carlborg wrote:
On 2017-03-03 16:23, Moritz Maxeiner wrote:
That would be a good next step from an engineering standpoint,
I agree,
to proceed to minimize the amount of trust in people you need
to have vs
verifiable safety.
I have considered porting something like seL4[1] to Rust, but
ultimately
this would take a significant amount of time and even if done
you'd then
have the biggest problem any new kernel faces: Hardware
support. Driver
development is AFAIK mostly done by people working for the
hardware
manufacturer and you're going to have a hard (probably closer
to
impossible) time convincing them to spend money on driver
development
for you. And if they don't you'll have close to 30 years of
hardware
support to catch up on by yourself.
But suppose you limit yourself to a single (or at most a
handful of
homogeneous) platform(s) like [2], e.g. a new AArch64 board.
Suppose you
even take one where the hardware is open so you can audit its
schematics, then you'll *still* either have to use proprietary
firmware
for the (partially onboard) periphery (and have unsafe
interfaces to
them), or - once again - write all the device firmware
yourself.
And once you've done all of that you're still missing
userspace, i.e.
you have a nice new OS without any actual use for it (yet). So
you
either start writing your own incompatible, safe userspace, or
you're
going to decide to integrate the userspace of existing OSs
(probably
POSIX?) to your new OS, so you're going to be writing your own
(safe)
libc, (safe) pthread, etc, exposing (once again) unsafe APIs
to the top.
It will be safer than what we currently have on e.g Linux
since you can
probably make sure that unsafe use of them won't result in
kernel
exploits, though; this will, of course, take even more time.
Finally, at the arduous end of your journey you're likely
going to
notice what - in my experience - most new OSs I've observed of
the years
experience: Essentially nobody is interested in actually
switching to a
volunteer-based OS.
Honestly, I think you need serious corporate backing, a
dedicated team,
and like 5-10 years (low estimate) of guaranteed development
time to
have a snowballs chance in hell to pull this off and the only
possible
sponsors for this I'm both aware of and would currently trust
not to cut
you off in the middle are either already working on their own
OS[3], or
have dedicated their R&D to other things[4].
I agree. The only potential hope I see would be to port Linux
to a memory safe language.
By Linux, I hope you don't mean the kernel itself. Because
outside of being an entirely fruitless venture, it shows a lack
of understanding of what's involved in kernel programming.
Most memory safe languages I know don't take well to using bit
arithmetic with pointers, deliberately smashing the stack, self
modifying code, and a whole plethora of things required to work
with the CPU in a freestanding environment. Within the span of a
single function call, an address in memory is easily able to
refer to a different address on physical memory.
Forgive me if I'm wrong, but I don't think you can get that much
benefit out of memory safety when you change the address of the
stack pointer manually and start to manually prefill it with new
values for general registers.
