Live data from Hacker News

You gave me a u32. I gave you root. (io_uring ZCRX freelist LPE)

ze3tar.github.io

81–90 of 152 posts

Re: You gave me a u32. I gave you root. (io_uring ZCRX freelist LPE)

#81
post #63

Earlier quoted context omitted.

except nearly everyone uses unsafe rust

No they really don't. 95% of rust is safe rust[1]. Also unsafe rust doesn't remove bounds checks. arr[idx] is bounds checked in every context. You can opt out of array bounds checking by writing unsafe { arr.get_unchecked(idx) } . But thats incredibly rare in practice. [1] https://cs.stanford.edu/~aozdemir/blog/unsafe-rust-syntax/

> 95% of rust is safe rust.

Based on the raw number of assorted crates, which has no bearing on kernel code. The more relevant question is, can a performant, cross-architecture, kernel ring-buffer be written in safe Rust?

Re: You gave me a u32. I gave you root. (io_uring ZCRX freelist LPE)

#83
So this is another CVE? Or am I misreading this one? "Copy‑fail", "DirtyFrag", now "IUrinegOnYou :)"?

Joke aside, we'll see more CVEs in the coming months, and in a sense that's good: it leaves less maneuvering room for bad actors (especially those selling them to the highest bidder).

Re: You gave me a u32. I gave you root. (io_uring ZCRX freelist LPE)

#84
post #53
post #50

Earlier quoted context omitted.

sure, but with unsafe Rust you have a very clear marking for the section of code that requires additional care and attention. it is also customary to include a "SAFETY" comment outlining why using unsafe is OK here

You actually kind of don't, I use like a zillion crates which have unsafe Rust in them and it's not like I'm sitting here reading every single line of their code. I like Rust for various reasons, but its memory safety is (imo) overstated, especially when doing low-level stuff.

[dead]

Re: You gave me a u32. I gave you root. (io_uring ZCRX freelist LPE)

#85

Earlier quoted context omitted.

Static analysis and other tools can find this, but they're expensive; wonder what the kernel team has access to?

If static analysis could actually find these issues with a reasonable false positive rate, the companies behind them would be running them on Linux to get the publicity of having found the issues like all the AI companies are doing now. Imo the good static analysis heuristics are already built into compilers or in open source linters.

The cheap, low-hanging "fruit" lint rules have been added to today's C/C++ compilers. But these rules can be fragile, depending on what level the static analysis scan occurs - source-code-level-textual pattern matching or use of an AST/parse tree.

Possible problems within a function should be discoverable.

This particular bug would be hard to discover for a typical linter unless they knew/remembered that there are two execution paths for cleanup of a given element.

Re: You gave me a u32. I gave you root. (io_uring ZCRX freelist LPE)

#86
high privilege access required (CAP/NET admin), containers / sandboxing wins once again.

Can we make sandboxing the new default now? Flatpak does a good job, but we're still pretty far away for apt/yum/pacman installed packages. AppArmor was a decent step forward, but clearly not enough.

Re: You gave me a u32. I gave you root. (io_uring ZCRX freelist LPE)

#87
post #63

Earlier quoted context omitted.

No they really don't. 95% of rust is safe rust[1]. Also unsafe rust doesn't remove bounds checks. arr[idx] is bounds checked in every context. You can opt out of array bounds checking by writing unsafe { arr.get_unchecked(idx) } . But thats incredibly rare in practice. [1] https://cs.stanford.edu/~aozdemir/blog/unsafe-rust-syntax/

> 95% of rust is safe rust. Based on the raw number of assorted crates, which has no bearing on kernel code. The more relevant question is, can a performant, cross-architecture, kernel ring-buffer be written in safe Rust?

I doubt it, but you can probably get pretty close.

This is something a lot of people misunderstand about unsafe rust. The safe / unsafe distinction isn't at the crate level. You don't say "this entire module opts out of safety checks". Unsafe is a granular thing. The unsafe keyword doesn't turn off the borrow checker. It just lets you dereference pointers (and do a few other tricks).

Systems code written in rust often has a few unsafe functions which interact with the actual hardware. But all the high level logic - which is usually most of the code by volume - can be written using safe, higher level abstractions.

"Can all of io_uring be written in safe rust?" - probably not, no. But could you write the vast majority of io_uring in safe rust? Almost certainly. This bug is a great example. In this case, the problematic function was this one:

    static void io_zcrx_return_niov_freelist(struct net_iov *niov)
    {
        struct io_zcrx_area *area = io_zcrx_iov_to_area(niov);

        spin_lock_bh(&area->freelist_lock);
        area->freelist[area->free_count++] = net_iov_idx(niov);
        spin_unlock_bh(&area->freelist_lock);
    }
At a glance, this function absolutely could have been written in safe rust. And even if it was unsafe, array lookups in rust are still bounds checked.

Re: You gave me a u32. I gave you root. (io_uring ZCRX freelist LPE)

#89
post #31

[flagged]

> "No way to prevent this", Says Only Language Where This Regularly Happens clang -fbounds-safety ... also see lib0xc etc.: https://news.ycombinator.com/item?id=47978834

NOTE: This is a design document and the feature is not available for users yet.

https://clang.llvm.org/docs/BoundsSafety.html

Post reply on HN