Reverse Engineering the DualShock 4 (opens in new tab)

Yeah, crashes from hardware driver are fairly common on Windows. And without any surprise, USB is the most common one (I'd say network devices (Ethernet, Wifi, or BT) are a close second).

I remember OpenBSD panicking over some USB hubs a few releases ago. USB is hell.

Ah nice do we try to find excuses that monolithic kernel's are not so bad at all right?

And it's totally ok that those (any) "high-quality" driver can crash the system?

>Linux uses modules, some other BSD not.

Has nothing todo with modules, if it's loaded it's in kernel-space. Not others...OpenBSD is the ONE.

BTW: For those butt-hurt ones (that i blatantly attacked poor linux), it not just about linux but should we no create operating-systems where this is not possible? Just asking...

Both, surely? The hardware shouldn't give bad input, and the kernel should tolerate it if it does.

Edit: Sorry, I take it back: That data is weird, but not malformed; the hardware isn't out of line and I think the driver is fully at fault.

USB sucks everywhere. OpenBSD can panic over USB too. It happened to me. Hubs, faulty USB drives, Chinese gamepads, noname ElCheapo USB Ralink WiFi dongles with dubious designs...

I think the only truly secure OS for this would be Hurd or SeL4+Genode.

If you stepped into a dog turd and it leaked into your socks do you blame your open source shoe designer or your lazy dog?

A traditional videogame controller is not much more than a few switches and perhaps a few potentiometers, see for instance the pinout for the Master System: https://www.smspower.org/Development/ControllerPort

That is, someone who started playing videogames in the SMS/NES days might have formed a mental model of the controller being mostly a passive device, with at most a few active chips to multiplex the pins in the interface, to allow for more buttons than there are pins.

it is obvious in hindsight, but I never put a thought on it before reading that sentence

While I've never tried it in that way, I understand it should function as a standard USB game controller when wired, but its real gem would be fully leveraging its wireless support.

I'd wager a bad/worn NAND block, 'cosmic ray' or other electrical glitch was more likely to cause a checksum issue than anything else. It might be sudden battery disconnect caused due to the controller being dropped (per the first page), but there should be local capacitance on the NAND supply voltage size to last a page write cycle as sudden power loss is going to happen in a lot of situations.

I would generally critique the use of a checksum on this config data without a backup or ping-pong writing system specifically because in the case of a 1 bit failure on something critical like cal or configuration data, really you want the data anyway and just hope that the 1 bit wasn't that important and also be ok if the bit flips back again on the next go around.

Thanks for that, I missed it in TFA. But ouch, that feels like an extreme design choice. What's the logic here to erasing the flash on a failed checksum, or requiring a checksum in the first place? Is there a non-obvious security threat?