The Linux Foundation's "security mobilization plan"
The Linux Foundation's "security mobilization plan"
Posted May 26, 2022 12:20 UTC (Thu) by rahulsundaram (subscriber, #21946)In reply to: The Linux Foundation's "security mobilization plan" by wtarreau
Parent article: The Linux Foundation's "security mobilization plan"
There have been several attempts at doing variants of C or coding standards to try to ease the transition (Misra C, Cyclone etc) and while atleast some have seen some limited adoption, I don't think they are sufficient. Otherwise, why hasn't it been done already in several decades.
Posted May 26, 2022 18:21 UTC (Thu)
by mpr22 (subscriber, #60784)
[Link] (1 responses)
What wtarreau seems to propose is a C variant where all UB is transmuted into some combination of "the behaviour of this construct is implementation defined" and "this construct is forbidden". I imagine a conservative version of that looking like:
Signed integer overflow? Well, it can trap, or it can wrap, or it can saturate, and it can refuse to compile code that provably causes signed integer overflow, but the implementation must say what it does. Caveats like "unless someone has altered the CPU control registers behind the implementation's back" are taken as read.
Assigning the value of a double of great magnitude to a float? Well, it can trap, or store Inf, or store a qNaN, or store an sNaN, or do whatever the OS has configured the CPU to do, and it can refuse to compile code that provably does it, but the implementation has to say what it does. Caveats like "unless someone has altered the CPU control registers behind the implementation's back" are taken as read.
Read or write through a null pointer? Well, it can trap, or it can return the contents of the address corresponding to the bit pattern used for the stored representation of NULL, or whatever, but the implementation must say what it does. ("What the hardware and OS decide to do when you dereference the address represented by the all-zeroes bit pattern" is an acceptable answer.)
memcpy() between overlapping regions? It can copy forward, or backward, or from the middle out, or from the outside in, and it can refuse to compile code that provably does it, but whatever the result, the implementation has to document what it does.
Invoking a function without having a prototype in scope is forbidden.
Defining a function without a prototype is forbidden.
If two pointers have fully identical bit patterns, they refer to the same object.
etc.
Posted May 28, 2022 8:59 UTC (Sat)
by tialaramex (subscriber, #21167)
[Link]
First it has places where it requires certain constructions that the authors believe (in some cases with good justification from studies showing this works, in others it seems like just a weird style preference) are safer or encourage safer programming.
For example MISRA insists you use C's switch statement to write exhaustive and irrefutable matches. You must write break after each case clause, and you must provide a default case and these are to be presented in a particular order.
Second it has a bunch of unenforceable rules about engineering practice. For example your code should be documented and tested. C doesn't actually provide you with any help actually doing this, but MISRA does at least tell you that you should do it.
I'm sure MISRA or anything like it would make wtarreau miserable while providing very little benefit.
The Linux Foundation's "security mobilization plan"
The Linux Foundation's "security mobilization plan"