Yeap, it gets into a philosophical debate of what comprehension.
One could argue it's not about compression in bits but compression to primitives that makes sense to the human mind. But then the definition becomes to fuzzy because it naturally invites the question "Who's mind?"
Also it's clickbaity, it's basically saying that Putin will put the guy in solitary confinement or close to... which seems reasonable seeing as he's a dictator that hates the guy and wished to kill him (then failed).
Also, looking at the profile, the author seems to be peddling various cookie-cutter "products" he's trying to sell to "entrepreneurs"... I wonder if he read his first link.
A bit off topic, but I like the usage of "social engineering attack" instead of "anything to do with the word computers/cyber/hacking", because it places the onus on the correct parties and the correct systems that failed.
Suppose you want to defeat a "Reflections on Trusting Trust" attack and bootstrap a toolchain source code you believe is clean to produce binaries that are clean. You need to compile llvm/clang (or gcc). You start with something small you can audit manually, use it to build binaries that can compile llvm, then use llvm to build itself to get an optimized compiler that doesn't have malicious code to recognize the password check inside the login binary and emit machine code that is not faithful to the source code.
Interesting! Still, I believe this doesn't prevent malfunction resulting from a compromised silicon...Like a sequence of instruction executions or memory accesses resulting to sending over a packet via the network.
I wonder how can one prevent that? Even an open-source ISA could not be fully trusted since one can't know what is implemented on the actual die on hand.
It's true that the silicon is hard to audit, but it's also pretty static, and there's a huge variety of pretty effective obfuscation that can live on top of the silicon. The
You suggest that an adversary could use some compromised layer to send a packet over the network when something happens. For example, someone running `aesenclast xmm15, xmm10` could also secretly trigger a socket()/send()/close() syscall set that would transmit a packet over the network adapter. But what if the target code never calls the AES-NI instructions? A user could easily be using a library that processes the encryption in software; a simple ISA filter has an impossible task to determine which xor instructions are cryptographic and which are just ordinary compiler output. You could be running a virtual machine, in which you've loaded a browser Javascript engine, and using that Javascript engine to run a virtual machine (https://bellard.org/jslinux/), in which you're running a Python instance, which is finally performing the encryption.
Sure, if all those layers were efficient, they'd just pass it down the stack to eventually call `aesenc`, but modern software is anything but efficient. Yes, if your deeply nested Python calls "sum = num1 + num2", the x86 `add` instruction likely gets invoked somewhere, but to predict when some client code is handling a secret key or when some user input is actually a password seems really difficult.
tl;dr of a pamphlet I decided not to post: If you're [seriously] considering anything beyond "my firewall is strictly unable to report it", you're either building something like nuclear weapons or taking the first steps to sliding down the rabbit hole of paranoia, ending up in tinfoil-hat-wonderland ;-)
The topic is interesting from an academic point of view. Maybe something along "On trustworthy, verifiable execution on untrusted, adversary hardware". Like homomorphic encryption, but I think having the user supply the input would make for a difficult programming+debugging cycle :P
Anyway, the goal of this compiler here isn't to prevent ANY kind of attack. As the page says, it is "only" a tiny C compiler, and an obfuscated one at that. The "tiny" part makes it much easier to audit than say GCC or clang (and you don't need to audit GNU binutils, either - and I've seen that code, so trust me when I say: You don't want to go that route).
//edit: Obviously I don't want to insult the fine folks investing their time into projects such as binutils, they deserve quite some praise - but as someone who is not familiar with the code base I found it to be very overwhelming.
If you wanted to solve for that, you would have to build a computer like the monster6502 [1] to run the compiler on, and visually inspect the memory contents.
The ultimate question is: How far do you need to go until you believe that the earth is indeed not flat? Do you trust your teachers? Stand on a tall building? Take a balloon ride? A plane? A spaceship? Then still, at which point can you rule out that the earth just appears to be a ball due to some yet-to-be-explained phenomenon (gravitational anomaly?) but is indeed flat? (The correct answer of course is "turtles all the way down").
For some definition of 'easy', yes. You still need to know a lot about how a CPU works. I think a project to bootstrap a PC with code generated from a completely verifiable platform would be really cool, but in practise would be of limited usefulness above and beyond secure boot we already have, because you're still trusting all the binary BLOBs you can't control (BIOS/UEFI, Intel ME, microcode, etc)
At one point a variation of it could compile a Linux kernel (very fast too!) and boot from the same ISO. Of course GCC or LLVM produced better optimised code, but TCC, being so small runs so much faster.
Another practical application is using tinycc as a backend compiler for Nim [1]. I set up my nim.cfg to default to this for a rapid edit-compile-test cycle (usually under 250 millisec), with a quick define switch to move to gcc-optimized code.
Similar is likely possible for other prog.langs that emit C.
One helpful feature for the full round-trip to an executable file is a built-in object file linker.
Also, libtcc can be used as a library to "compile a string" and then run it which is the JIT application mentioned elsewhere in this thread.
Yes, for winning IOCCC competitions! Which would normally be a great CV badge to demonstrate your skills to prospective employers, but likely of little consequence if you're Fabrice.
If you have the sort of brain that makes winning IOCCC entries, it is highly probable that a candidate employer who has not heard of it is not, in fact, prospective.
Presumably no arrests made though means people didn't fight the medical professionals trying to incarcerate them? So I assume most of them went voluntarily.
Hopefully the article is enjoyable to those that haven't read his blog, I stumbled upon it because I'm a fan on nintil in general, but I think it's interesting even if you aren't familiar with his other writings.
One could argue it's not about compression in bits but compression to primitives that makes sense to the human mind. But then the definition becomes to fuzzy because it naturally invites the question "Who's mind?"