If you needed any more evidence that memory safety is the future...

[Paulo Pinto via Digitalmars-d]

On Wednesday, 8 March 2017 at 13:12:12 UTC, Minty Fresh wrote:
> 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.

I will just leave this here.

https://muen.codelabs.ch/