FreeBSD security design flaws

[loveydovey]

We can basically close this thread now.

 

[waym0re]

The kernel can't do only memory safe operations by definition. That's why we separated the kernel from userland. The two serious attempts at a Rust OS are Redux and Asterinas. And at least one of them tries to separate the kernel in two: part with unsafe Rust, part with safe Rust. The other uses a microkernel, which will never work, and completely mixes safe and unsafe Rust together. Again, a pure safe Rust kernel is theoretically impossible: the kernel must do unsafe memory operations just as basic operations. Example: A user program calls read(). The kernel must copy bytes from a kernel buffer into a pointer the user provided. That pointer could be: null, unmapped, a kernel address (privilege escalation attempt), and maybe something else. In any case, the kernel must do an unsafe instruction to that pointer to do its job. There is no safe version of this operation

Memory safety is largely misunderstood and the arguments of it's proponents mostly come from people that don't understand the basics.

Even "Permissions are attached to users, not capabilities" is a failure of basic comprehension. Why and how are capability-based systems an obvious upgrade? How much resources went into seL4, Fuchsia/Zircon and other attempts? It's not even clear that such systems are well-defined.

There's also a failure to understand the actual historic sources of security flaws. Major kernel exploits don't usually come from "a rarely-used USB driver" being isolated. They come from core subsystems (memory management, syscall handling, privilege transitions) that a microkernel still has in its privileged layer. So you're really fixing a non-existent theoretical flaw and trading that for a geometric increase in transactions and complexity.

 

[T-Aoki]

And at least one of them tries to separate the kernel in two: part with unsafe Rust, part with safe Rust.

I feel it NOT logical.
Using Rust for memory-unsafe part would easily make confusions in the future.
Using C, asm or some other low to mid level language for unsafe part to clearly mark that the part is MUTUALLY memory-unsafe in mature would be far more cleaner. This way, UNSAFE part of Rust codes can be definitions for interfacing with C / asm / something else. Far more saner.

 

[bakul]

See r9os/r9 on github. It's a reimplementation of the plan9 kernel in Rust. There are 249 lines using unsafe, out of 9620 lines of rust code (and 884 lines of asm code). No idea how well it works or how complete but it shows that actual unsafe code is pretty small part of the kernel. No one is looking for "purity", it is more a matter of reducing the scope for screwing up.

My personal opinion is that given a better hardware design there would be *no* need for a higher privileged kernel. The *first* program to run after powerup would hold *all* the access rights to everything in a system (at hardware level) and a more structured system would be constructed from it (or "evolved") by ladling out subsets of access rights to more specialized processes. Various implementations of CHERI's hardware arch will hopefully provide a proof of concept which can then be analyzed (though AFAIK, such implementations still do have a higher privilege mode). Whether such an arch. ever becomes popular is unknown (but IMHO unlikely).

 

[waym0re]

I feel it NOT logical.
Using Rust for memory-unsafe part would easily make confusions in the future.
Using C, asm or some other low to mid level language for unsafe part to clearly mark that the part is MUTUALLY memory-unsafe in mature would be far more cleaner. This way, UNSAFE part of Rust codes can be definitions for interfacing with C / asm / something else. Far more saner.

You're correct, of course. But you've not met Rust evangelists. They don't even have those concepts in their periphery.

Edit: Not ASM. I want my OS portable.

 

[T-Aoki]

Edit: Not ASM. I want my OS portable.

If I recall correctly, it's one of the reason why C is developed.

 

[eternal_noob]

The fix is ... Rust

Stopped reading here.

 

[doul]

Edit: Not ASM. I want my OS portable.

As soon as you write low-level code, it's not portable, in C as well as in ASM.

void hal_timerSchedInit(void)
{
    // Set up timer1 interrupt for scheduler
    TCCR1B |= (uint8_t)(1u << WGM12); // CTC mode
    OCR1A = TIMER1_OVERFLOW_COUNT;
    TIMSK1 |= (uint8_t)(1u << OCIE1A);
}

This C code for atmega2560 is highly not portable, we have to go through HAL to get a portable code. There is no OS without ASM, even if it's just to make the initial wiring hardware -> C/compiler ABI.