Wi-Fi software security bug could leave Android, Windows, Linux open to attack (Ars Technica) [LWN.net]

Wi-Fi software security bug could leave Android, Windows, Linux open to attack (Ars Technica)

Posted Apr 25, 2015 6:17 UTC (Sat) by Karellen (subscriber, #67644)
In reply to: Wi-Fi software security bug could leave Android, Windows, Linux open to attack (Ars Technica) by wahern
Parent article: Wi-Fi software security bug could leave Android, Windows, Linux open to attack (Ars Technica)

Cool. I didn't realise TCC did that - thanks for the info.

But, although I've not looked into it, I'm fairly sure that those pointer protections can't escape the current function. If the "while" loop was in another function (or especially in another translation unit) and "p" and "buf" were passed in as parameters, I seriously doubt that TCC would be able to catch the underrun.

IBM's implementation sounds more like the sort of thing I was thinking of.

to post comments

Wi-Fi software security bug could leave Android, Windows, Linux open to attack (Ars Technica)

Posted Apr 25, 2015 19:45 UTC (Sat) by wahern (subscriber, #37304) [Link]

Correct, TCC only adds instrumentation to the code that it compiles and for the objects that it allocates.

Regarding the IBM stuff, I think what I'm remembering is

http://en.wikipedia.org/wiki/IBM_System_i#Instruction_set
and
https://www.ibm.com/developerworks/community/files/basic/...

Basically, the IBM compilers for this environment translate C, Fortran, Cobol, etc programs to an intermediate representation, TIMI. When you first execute it on a new system, the OS translates TIMI to native code. When you move to new hardware, you just copy the program and the TIMI representation is automatically translated to the new instruction set. I guess it's one of the reasons so many ancient IBM mainframe and minicomputer programs continue to be migrated to newer and newer hardware, instead of being relegated to an emulator and abandoned as too slow.

I'm unclear on how and whether the full 128-bit pointers are used from C code, by the C compiler, or in the runtime environment. AFAICT, in TIMI pointers are more like file handles in the sense that they describe an object and control how you can manipulate the object. And the hardware protects the tagging bits, so you can't derive pointers to random resources.

A pointer could reference a program, an instance of a program, file, a service, or in the case of a running C program a heap object returned from malloc. But it's not clear to me if these capabilities are used to, e.g., restrict buffer overflows. For all I know all data pointers in a running C program simply index a single virtual address page map "object" assigned to the program instance, not unlike the way it works on x86 hardware.

It's really fascinating. Perhaps someone reading this could chime in. It basically sounds like the kind of persistent object store and addressing model that people claim will be arriving in the future, except these machines and the architecture have been around for over 30 years.

It makes sense now why IBM was so quick to jump on the Java bandwagon. They have this incredibly sophisticated hardware architecture that is well-suited for implementing, integrating, and running JREs.