manawyrm

+1, if your threat model is actually this severe, use physical hardware with physical interlocks and physical security mechanisms.

Software/virtualization is just helpless against such a threat model.

It's an AMD platform, so it's the native AMD HD Audio Controller (17h/19h/1ah), with a Realtek ALC245 codec behind it. I have no idea what other hardware is involved, presumably an external Class-D amplifier IC (but I don't know as there doesn't seem to be a datasheet for the ALC245 available).

Awful, around 3h. It's a nice machine if you need x86 and graphics power.

I'm still keeping my M1 Pro.

> Is there any technical reason it couldn't be generic though? It includes 2 .wav files containing a measured, real-life calibration data for this specific laptop.

If you measure your own device (and it's frequency/impulse response) and replace those .wav files with that -- you're good to go! There's just no universal format/place to put such calibration yet, which is why I published a custom package (incl. the filter config).

I'm kinda hoping more people generate such files for their laptops and share them, maybe we can build a collection of such profiles for many laptops :)

Get familiar with REW and then maybe https://www.youtube.com/watch?v=5YcH7j2-L1Y and you should get pretty close results.

REW can generate a set of peaking/shelf equalizer filters, but why would I want to do that instead of just applying the inverse impulse response instead? It's just more work for a less perfect solution/result...

Exactly correct, that was my thought process while doing it. I tried it without that 300 Hz slope first of course, but that did try to murder my speakers. :)

Same. I really didn't expect that (and thus didn't even test it at first).

lol! The IP stack does not have forwarding support, but I guess you could implement some rudimentary loopback announcement support.

Depends on what you want to do :) If you just want to read/write sectors of 512 bytes at a time, it's pretty easy to implement even on a simple MCU.

There's a couple of registers which need to be set: https://wiki.osdev.org/ATA_PIO_Mode and you can then just read/write the data from the parallel lines.

Here's a similar project using an ATmega32: https://github.com/zwostein/idetrol (i used this code, ported to ARM to check my hardware before I wrote the kerneldriver)