Google assigns a CVE for libwebp and gives it a 10.0 score

The design of io_uring has nothing to do with the language the Linux kernel is implemented in. And safer languages really can't provide guarantees when the issue at hand is designing a shared memory cross-executable (kernel⋄userspace) API.

The past 40+ years of CS research has created a huge number of tools for reducing the costs of memory safety. Some of these made it into Rust, but others are sitting in (often abandoned) academic projects. It is an abject failure of industry that we are still parsing untrusted input in languages like C.

WebP gets a slight pass because the code is so old; WebP is at least partly based on code from On2 that extends back at least until the early '00s. Rewriting working code is always going to be lower priority than writing new code (and it's not always a safety win either; being deployed for 10 years gets you an awful lot of real-world testing!).

But look at implementations for newer image formats and you see more of the same; C and C++ with the token java implementation that won't get used outside of the JVM.

Apple has actually measured the impact of adding bounds checking to commonly used libraries including media libraries and found no impact on overall power use. Audio and video encoding libraries took around a 1% performance impact.

https://llvm.org/devmtg/2023-05/slides/TechnicalTalks-May11/...

I don't think there is any evidence to support that bounds checking causes any significant increase in power consumption, and measurements currently available such as shown above show minimal runtime performance impact.

Bounds checking is the perfect situation for branch predictors, 99.9% of the time the branch is predicted correctly, and when it's not it doesn't matter because you're probably aborting the program!

There's also the point that you can opt out of bounds checking as-needed on hot loops if you really need to.

There is no technological reason to not use bounds checking as the default mode of operation today.

They aren't wasted if they are preventing security vulnerabilities.

I also wouldn't be surprised if patching, rebuilding and distributing this fixed version of libwebp to all of these devices would be comparable to the extra cost of decoding.

I think your intuition on the cost of not-taken bounds check branches is off, especially in the context of devices that spend most of their resources browsing the web, running radios, powering screen backlights. I bet any holistic measurement could not tell the difference.

I am surprised that you can even say "it's not very good." The sorts of prompts I'm imagining I would expect to trigger the "I'm afraid I can't do that Dave" safeguards every time. I guess yeah, I'm just imagining using it as an advanced fuzzer but I think the thing about using an LLM is you can take the fuzzer code and ask the LLM to just generate slight variations, feed that into a test and ask the LLM to flag ones that look like they might have been an exploit. And when it generates nonsense code, you just throw out those runs. But on the other hand hallucination feels like an advantage here since it's going to do things you never would have thought to test.

I would not expect an LLM to be good at this without specialized training. I have tried prompting for code generation.

I do not know of LLMs that have been specifically trained on, say, the testing corpus of some "lint" programs and against known vulns. As you point out, it wouldn't be possible as a user of an LLM AI to do the equivalent by showing it some vulns, while it would be perfectly reasonable to get an LLM to write, for example, business case studies by showing it examples.

Which ones, out of curiosity?

With infinite hardware, sure. LLMs are pretty expensive to run vs fuzzing.

It's this manufacturer https://www.ulefone.com/index.html and probably many more out there, typically in the budget segment.

I can say that their rugged designs served me well, but some of the newer phones apparently have this weird component for wireless earphones and I don't really want that, so my current and future purchases are from different manufacturers. Was actually pretty close to stock Android, though!

This is what I'm talking about:

https://support.google.com/product-documentation/answer/1141...

Good luck setting things up in such a way that you only get security patches and not a whole bunch of 'improvements' to go with them.

> We live in 2023. We can deal with slightly worse compression until someone rewrites it in a sane language.

not just sanity of implementation but also reliability and compatibility

{h264,jpg,zip} for life!

It's not just compression ratios that new formats provide though: it's also higher bit depths (meaning less banding for things like gradients, i.e. in skies at sunset) and HDR support (values over 1.0 in 'linear' space, rather than being clamped).

I'm sure this is what you meant, right ;)

https://github.com/Traneptora/jxlatte

I was under the impression that modern C++ is a "sane language" - it looks like "smart pointers" are a thing now?

Yes, not exactly "clicking a link" but still at the same level ("add to contacts"). Also many apps have users with profile pictures. An attacker can send a link that will open in an app (eg. Instagram, facebook). Also within browsers could this still leak whatever is currently rendering on the page?

> The extra ceremony ("unsafe { foo.get_unchecked(n) {" vs "foo[n]" makes this even simpler to catch in code review

Right, and in said code review, the webp author could have easily said “yup, we want unsafe here because we already checked up front that the buffer shall not exceed k elements”. Sure it’s easier to see that unchecked access is happening, but when the whole point of large sections of the huffman table code in webp is to make this very thing work, it wouldn’t cause any additional scrutiny in a code review. In other words, it would already be super clear to the reviewer that bounds checking is being disabled for performance sake, seeing the word `unsafe` as ceremony isn’t really adding any information here.

It’s possible webp could have been implemented in rust with a naive approach to early bounds checking and relying on the optimizer to elide it, but having looked at the code, with all the buffer sizes they’re passing around, it looks unlikely that equivalent rust code would have been able to auto-optimize it. I don’t think it’s unlikely at all that, in this parallel universe, they would have found the bounds checking to be a decent enough overhead that they would have reached for unchecked access, and would have passed code review the same way the current code did.

That’s not google’s webp library, that’s a totally different project. It doesn’t really matter what that project does.

Elsewhere in the comments someone linked to this: https://dropbox.tech/infrastructure/lossless-compression-wit...

It looks like dropbox experimented with disabling bounds checks in their huffman coding impl, and found that using the unsafe pattern increased throughput from 224 MB/s to 249 MB/s (11%-ish faster.) We don’t even need to hypothesize about whether webp would have elminated bounds checking, we can see that other companies arrived at the same conclusion: Disabling it can be worth it if you’re quite sure you’ve gotten the up-front checking right. We can imagine that if Dropbox went to prod with the unchecked huffman implementation (never mind that that article isn’t about webp in particular), we could imagine they could easily have the same bug. And I don’t think a naive code review saying “unsafe is bad” would have stopped them from doing it: they clearly did the work to show why it’s worth it.

It isn't, but there's a big difference between writing straight C and writing some unsafe Rust with safe wrappers. It's generally possible to have comparably few lines of unsafe Rust that do the heavy lifting and can be verified to maintain memory safety without sacrificing performance.

Exception gets caught somewhere up the call stack, like a webserver returning error 500. It's not the most user-friendly error handling, so you should avoid that whenever you can, but it's not a big problem. In some languages like C++, you'll trigger a crash instead, which can be more of an issue but still isn't nearly as bad as an undetected buffer overflow.

Ada has the bounds checking, but doesn't (AFAIK) have a safe way to deallocate dynamic memory. At least as of now, there is a proposal to add something like Rust in the future. It also has memory unsafe concepts like specifying an address for a variable.

They need a large runtime and are slow to start up.