marcan

marcan , 4 days ago to random

Apparently Apple just announced hardware-accelerated GIC support for Apple Silicon virtualization. Asahi Linux has had that feature for over two years now. Glad they caught up supporting features of their own hardware! 😁

marcan , 10 days ago to random

We really should just start calling non-conformant graphics API implementations (like Apple's OpenGL, or MoltenVK) "buggy".

If code doesn't pass tests we usually call that a bug and don't ship it until it passes them, right? It is exceptional that Apple is shipping OpenGL drivers that don't pass the tests and they are okay with that. They shouldn't really get credit for supporting "OpenGL 4.1" when they literally fail the OpenGL 4.1 tests (they even fail the OpenGL ES 2.0 tests!).*

• Nobody actually knows how to compile/run the full test suite on macOS OpenGL (because Apple would be the only entity who would care about that, and they don't), but we do know for a fact they have bugs the tests test for, so we can confidently say they'd fail the tests if someone were to actually port/run them.

0xabad1dea , 14 days ago to random

This is a graph of Discord’s algorithmically inferred gender (extracted from “request your data” json; axes are probability and days) for a user whose display name is “Tiffany”, whose bio is “she/her”, whose pfp is a drawing of a girl and whose profile theme color is pink.

Algorithmically inferred gender is worse than useless. Presumably the issue is that she talks about programming, and all the deliberate “I am explicitly telling you I am a girl” signaling in the world can’t convince a computer. I sometimes watch a livecoding streamer whose youtube stats claim his audience is 99% male even though you can see fem-coded chat participants regularly. Algorithms like this are deleting the women

marcan , 23 days ago to random

Just had another argument about curl|sh, so I'm going to say this top level for future reference.

The way we use curl|sh is as secure, or more secure, than traditional distro distribution mechanisms (e.g. ISO images with hashes or PGP signatures) for 99.9% of users. If you think otherwise, you don't understand the threat models involved, and you're wrong.

If you are in the 0.1% that actually cross-references PGP keys against multiple sources, exchanges keys in person, and that kind of thing, then you could indeed actually benefit from a more secure distribution mechanism. You're also, unfortunately, not a significant enough fraction of our user base for us to spend time catering to your increased security demands, that we could instead be spending improving security for everyone (such as by working on SEP support for hardware-backed crypto operations, or figuring out how to actually offer FDE reasonably in our installer).

And if you're not manually verifying fingerprints with friends, but curl|sh still gives you the ick even though you have no solid arguments against it (you don't, trust me, none of you do, I've had this argument too many times already), that's a you problem.

marcan , 24 days ago to random

So I've had this USB controller dying bug for months. The repro was "move data from USB disks for days". The symptoms were IOMMU faults. I thought we had some horrible heisenbug in our platform code.

I finally found a reliable repro today so I started poking around.

In xhci-ring.c: /* FIXME stream case, several stopped rings */

Gee, thanks, I love it when months-long anxiety over a bug ends up on a FIXME in the code. As far as I can tell, when USB streams are involved and stuff gets canceled, only one stream's TDs get canceled, leaving the others to still be processed by the HCD with DMA pointers now pointing to nowhere 🤦‍♂️​

Needless to say this is a Linux USB bug that has existed since the advent of xHCI and should affect all platforms.

marcan , 2 months ago to random

Found the DMP disable chicken bit. it's HID11_EL1<30> (at least on M2).

So yeah, as I predicted, GoFetch is entirely patchable. I'll write up a patch for Linux to hook it up as a CPU security bug workaround.

(HID4_EL1<4> also works, but we have a name for that and it looks like a big hammer: HID4_FORCE_CPU_OLDEST_IN_ORDER)

Code here: https://github.com/AsahiLinux/m1n1/blob/main/proxyclient/experiments/dmp.py (Thanks to @dkohlbre for the userspace C version this is based off of!)

One interesting finding is that the DMP is already disabled in EL2 (and presumably EL1), it only works in EL0. So it looks like the CPU designers already had some idea that it is a security liability, and chose to hard-disable it in kernel mode. This means kernel-mode crypto on Linux is already intrinsically safe.

marcan , 2 months ago to random

LB: Reimplementing trivial subsets of libraries is highly underrated. If all you need is a few lines of functionality, please don't link to a whole new dependency just for that. It's not worth it. I guarantee you're creating more maintenance burden with the dependency and the build/packaging/upgrade/compat churn that comes with it than you would be if you just vendored or reimplemented the little bit of code you need.