Language extension for maintenance of legacy application sounds a little bullsh1t to me.
0) If the application needs checks on anything (at the cost of performance) then higher level language (like C++) should be chosen at design time. No use for new application.
1) Existing applications will NOT port directly. Real-life applications are tightly coupled with supported compiler(s), so the compiler would need the update. Errors/exceptions (like overflows) would need handling and changes in logic. It could only deny read/write from illegal area, but without the feedback. The speed is also a major thing. Boundary check could possible prevent some bugs, but the performance will drop dramatically (example: commonly used libs like OpenSSL).
One use case I see is to add an extension (like GCC's for instance) for an existing compiler which does this. User could build a slower debug application and spot the silent errors during testing. An implementation thing, not the language extension.
I'm sensing a huge incomprehension in a great amount of posts. The key is to know the purpouse of tools. C is a "close-to-the-metal" type language. You can control a low-level things, execution time, "number of hops" when writing data, etc. If you want a friendly language with "no segfaults, no memory leaks" then go higher level (which in many cases is a better choice, i.e. a GUI desktop application with no performance constraint). If you have a problems wrigint in C then you simply still can't C and using the wrong tool for the task.
"But C? C's dead. It's the language for old programmers who want to debate section A.6.2 paragraph 4 of the undefined behavior of pointers"
Someone has to build the low-level stuff. Dear boys in too-tight pants and a hippie mustache: your high-level things and gluten-free snacks does not grow on trees.
Capturing the CPU instructions by a side-channel is indeed possible but the "real-life, working" use of the method described here is questionable for me. CPU in modern phones runs above 1GHz. USB sound card they're using provides max 192kHz which allows max 96kHz signal. 4 orders of magnitude less. There's also a lot of noise from different circuitry (GPU, display, wireless comm.) and laptop's noise as well which will obfuscate the signal.
It still strikes me as plausible. Sub-harmonics are a thing; it is entirely possible to leak data about what the CPU is or isn't doing down into the ultrasonic or audible bands.
As an example, one of my computers leaks a ton of noise into the onboard audio that quickly becomes audible with a moderate amount of gain. So much so, that I've learned to recognize changes in the noise pattern from various activities (shuffling windows around the gui, launching a program, compiling a program, etc).
How practical a real-life, working use of the method described here will depend in no small part how much noise the device being attacked casts off. There's some pretty bad devices out there.
You misunderstand the attack. You don't need to sample at 1GHz. Each 0 and each 1 in private key material leads to calculations taking thousands of tens of thousands of clock cycles. So you only need to sample EM radiations at around 100 kHz or 1 MHz.
I would recommend low power nRF51 chips. It's a Cortex M0 with integrated 2,4GHz radio. You can use is for Bluetooth Low Energy and communicate with other chips / smartphones / etc (manufacturer provides a BLE stack) or your own simple protocol. There are some modules below $10, but those would require additional USB chip (like ft232 or $2 pl2303 / ch341 module).
If you need a long distance (like 1km) communication then you need a "larger" radio which works in ISM band. For the cheapest solution I'd go with mass produced devices - two WiFi APs with 2 directional antennas + some custom boards ob both sides or APs with open firmware like openWRT.
0) If the application needs checks on anything (at the cost of performance) then higher level language (like C++) should be chosen at design time. No use for new application. 1) Existing applications will NOT port directly. Real-life applications are tightly coupled with supported compiler(s), so the compiler would need the update. Errors/exceptions (like overflows) would need handling and changes in logic. It could only deny read/write from illegal area, but without the feedback. The speed is also a major thing. Boundary check could possible prevent some bugs, but the performance will drop dramatically (example: commonly used libs like OpenSSL).
One use case I see is to add an extension (like GCC's for instance) for an existing compiler which does this. User could build a slower debug application and spot the silent errors during testing. An implementation thing, not the language extension.