Posts
170
Following
138
Followers
146
Probably some RISC-V stuff, but hopefully other things too ;)

Now you might wonder: how often does this actually happen? The common wisdom on this topic is that hardware failures are so rare that software bugs will always dwarf them. As I found out this is demonstrably false.

While investigating Firefox crashes I've come to the conclusion that several of the most common issues we were dealing with were likely caused by flaky hardware. This led me to come up with a simple heuristic to detect crashes potentially caused by bit-flips. 10/17

1
5
0
@gabrielesvelto IIRC the design point failure rate for consumer storage/memory was that it just had to be reliable enough that customers assumed it was Windows crashing and not the HW being broken.
0
0
2
@trini @lapis I've found washing soda is really good at getting some flavors of grime off, it's super good for tea/coffee residue. PBW is a mix of that and TSP, which is a super strong combo but isn't so good for the environment so I try and start with just the washing soda.
1
0
2

Hey Mastodon friends, it's Bike Month so we're running a discount in our official store. 10% off on everything, including apparel and stickers.

Use code BIKEMONTH at checkout.

We rely on listener support to keep the podcast going and this is another way we keep the lights on.

Thanks for your support!

https://the-war-on-cars.myshopify.com/

0
1
0
@pdp7 @tommythorn IIUC they're building their own cores, there's two I've seen references to so far.
0
0
2
@palmer Nono, I meant that my question from my last post was probably rhetorical.
0
1
0
@conor at this point I don't even think the questions are rhetorical, that would involve some sort of thought. I actually think we've just all been duped by some AI thing...
1
0
0
@conor I guess it's not so bad if Jim fell for it too ;)
1
0
1
I guess this is a bit embarrassing, but I finally fell for a May Fools joke...

https://lists.riscv.org/g/apps-tools-software/topic/risc_v_tech_unprivileged/105892640
2
0
2
When someone moved your cheese 20 years ago. :)

https://bugzilla.kernel.org/show_bug.cgi?id=218796
1
2
9

Mentioned this in passing, but want to publicly thank Dell for sponsoring a big test box. Tons of storage, tons of bandwidth, and now 100G connected in my little lab for great io_uring networking testing as well. They even stopped by my office for a day to rack mount it!

1
2
1

Cambridge Street, Cambridge.

This isn't a lack of parking; this is a driver who couldn't be bothered to pull all the way into the space.

0
2
0

updated my recommended network/firewall topology

4
12
1
Edited 6 months ago

I implemented Ken Thompson’s Reflections on Trusting Trust (1984 Turing Award Lecture) compiler for the GNU Compiler Collection (GCC). The backdoor maintains persistence by re-injecting itself to any new versions of the compiler built. The secondary payload modifies a test application by adding a backdoor password to allow authentication bypass:

$ cat testapp.c
<string.h>
<stdio.h>
<stdlib.h>

int main(int argc, char **argv)
{
if (argc == 2 && !strcmp(argv[1], "secret"))
{
printf("access granted!\n");
return EXIT_SUCCESS;
}
else
{
printf("access denied!\n");
return EXIT_FAILURE;
}
}
$ gcc -Wall -O2 -o testapp.c -o testapp
$ ./testapp kensentme
access granted!
$

I spent most time (around two hours) writing the generalized tooling that produces the final quine version of the malicious payload. Now that this is done, the actual code can be adjusted trivially to exploit more target code without any need to adjust the self-reproducing section of the code. This method of exploitation could be extended to target various binaries: SSH Server, Linux Kernel, Setuid binaries and similar. While itself written in C, the secondary payloads can target any programming languages supported by GCC.

It should be noted that GCC build checks for malicious compiler changes such as this. This check can – of course – also be bypassed. However, most serious projects have measures in place to avoid hacks of this nature.

Some links:
- Ken Thompson's "Reflections on Trusting Trust" paper: https://www.cs.cmu.edu/~rdriley/487/papers/Thompson_1984_ReflectionsonTrustingTrust.pdf
- David A. Wheeler: "Fully Countering Trusting Trust through Diverse Double-Compiling (DDC) - Countering Trojan Horse attacks on Compilers" https://dwheeler.com/trusting-trust/

@vegard

3
7
0
@etchedpixels @sjvn TBH, I'd love to be making other people's mistakes. We're just too busy making up new ones right now, maybe in a few years we'll get there ;)
0
0
1
@rjohnston @notjustbikes This is why people keep getting killed.
0
0
0
Show older