jcalvinowens

A much better title would be "A hardware backdoor in a historical VIA x86 CPU".

You stand to the side and pull it with one arm

A lawn mower cuts grass whether you push it forward or pull it backwards: my trick when I was a kid was just to push and pull it back and forth across the lawn without changing the direction it faced at all.

Remember that -Os is much much more aggressive in GCC than it is in LLVM, with LLVM you need to use -Oz to get the same result.

GCC has historically been a bit of a pig about -Os, my favorite example is on x86 where it will emit a runtime divide for a division by a compile time constant power of two because it saves a byte of text!

  int fn(int n)
  {
    return n / 8;
  }

..becomes:

  0000000000000000 <fn>:
   0:   89 f8                   mov    %edi,%eax
   2:   b9 08 00 00 00          mov    $0x8,%ecx
   7:   99                      cltd
   8:   f7 f9                   idiv   %ecx
   a:   c3                      ret

..versus:

  0000000000000000 <fn>:
   0:   8d 47 07                lea    0x7(%rdi),%eax
   3:   85 ff                   test   %edi,%edi
   5:   0f 49 c7                cmovns %edi,%eax
   8:   c1 f8 03                sar    $0x3,%eax
   b:   c3                      ret

> One thing that concerns me is the possibility of on-die ECC interacting with ECC on the motherboard and reducing it’s effectiveness

DDR5 on-die ECC detects and corrects one-bit errors. It cannot detect two-bit errors, so it will miscorrect some of them into three-bit errors. My understanding is that the on-die error correction scheme is specifically specially designed such that the resulting three-bit errors are mathematically guaranteed to be detected as uncorrectable two-bit errors by a standard full system-level ECC running on top of the on-die ECC. But I've never found a real authoritative reference that directly says that.

HDCP1 is completely broken, you can buy HDCP2.x strippers on amazon (they're often marketed as "converters").

+1 for btrfs

If a NAS has a 1G or even 2.5G NIC, improving the filesystem performance is a waste of time... the network is the bottleneck. My N100 two-disk btrfs-raid1 NAS hits line rate on a 2.5G NIC, that's all that matters to me.

It's actually faster than I remembered:

  {0}[calvinow@sousa ~/git/linux] git describe
  v7.1
  {0}[calvinow@sousa ~/git/linux] git clean -dffxq
  {0}[calvinow@sousa ~/git/linux] zcat /proc/config.gz > .config
  {0}[calvinow@sousa ~/git/linux] time make -skj32 tar-pkg
  './System.map' -> 'tar-install/boot/System.map-7.1.0'
  '.config' -> 'tar-install/boot/config-7.1.0'
  './vmlinux' -> 'tar-install/boot/vmlinux-7.1.0'
  'arch/x86/boot/bzImage' -> 'tar-install/boot/vmlinuz-7.1.0'
  
  real    0m56.539s
  user    18m41.863s
  sys     2m8.754s

No, 90 seconds is the clean build time without ccache.