Hacker News Reader

Comment by benlwalker | Hacker News Reader

We tried to standardize exactly this - eBPF programs offloaded onto the device. The NVMe standard now has a lot of infrastructure for this standardized, including commands to discover device memory topology, transfer to/from that memory, and discover and upload programs. But one of the blockers is that eBPF isn't itself standardized. The other blockers are vendors ready and willing to build these devices and customers ready to buy them in volume. The extra compute ability will introduce some extra cost.

I'm still hopeful that we see it happen some day.

View on HN

> The NVMe standard now has a lot of infrastructure for this standardized, including commands to discover device memory topology, transfer to/from that memory, and discover and upload programs.

On the other hand, Windows and Linux still cannot just upgrade the vast majority of firmwares on NVMe devices, least of all consumer ones, despite being completely and utterly standardized.

You have to wonder, if Samsung makes bullshit, and then this https://github.com/chrivers/samsung-firmware-magic becomes part of the ecosystem, why trust the vendors with anything else?

I think i remember upgrading the nvme disk firmware in work dell laptop (dell latitude 7390) from 2019 using fwupd some years ago (not more than 3 years ago).

Also i think i remember fixing (upgrading?) the firmware on a crucial ssd like 5 or 6 years ago using some live linux system (downloaded off the crucial website i think?)

Not sure about windows, but linux is getting incredibly better at this.

That repo was last updated 3 years ago, things seem to have changed since.

There seem to be a lot of ISOs for download at https://semiconductor.samsung.com/consumer-storage/support/t...

The ISO contains an EFI filesystem with grub etc and boots fine without needing Windows.

So, could you upload malware to the drive that way?

The eBPF programs are strictly bounded. And they're scoped to their own memory that you have to pre-load from the actual storage with separate commands issued from the CPU (presumably from the kernel driver which is doing access control checks). It's no different than uploading a shader to a GPU. You can burn resources but that's about the extent of the damage you can cause.

It was only a week ago that Google disclosed an exploit to get a root shell via eBPF.

https://bughunters.google.com/blog/6303226026131456/a-deep-d...

I wouldn't want random applications (or web pages) to be able to load eBPF modules in the same way they can send shaders to a GPU through a graphics driver.

Reply on news.ycombinator.com