

"Strong" stack protection for GCC - robrenaud
http://lwn.net/Articles/584225/

======
willvarfar
I know everyone is a bit tired of hearing about the new Mill CPU, but one of
the things we've done with the architecture is to have the hardware track
return addresses. This is not only much faster and efficient; it is also
_immune_ to these kinds of attacks.

There's an upcoming "Security" talk which will cover lots of other ways we've
worked to improve the fundamental protection offered by the CPU, but the stack
is covered in the Memory talk:
[http://ootbcomp.com/topic/memory/](http://ootbcomp.com/topic/memory/) and
ootbcomp.com/topic/introduction-to-the-mill-cpu-programming-model-2/

~~~
pohl
_I know everyone is a bit tired of hearing about the new Mill CPU_

Well, damn, I must be late to the party. The Mill just caught my attention a
week ago, and I'm far from being tired of hearing about it.

Thank you for sharing what you can.

~~~
haberman
Agree -- I've seen only one article on it so far and found it fascinating.

~~~
gizmo686
Check out [http://ootbcomp.com/docs/](http://ootbcomp.com/docs/) if you want
more on the Mill.

------
neur0mancer
I wish all distros will start compiling all its packages with a _consistent_
policy to enable at least some level of stack protection (like Ubuntu and
unlike Debian).

~~~
gizmo686
Doesn't Ubuntu take most of their packages from Debian?

~~~
habitue
Ubuntu uses the packages that have been maintained and integrated by Debian,
but they don't necessarily take the binaries. They compile it themselves, and
that means they can specify whatever compile options they want.

------
pjmlp
How would the computing world be, if compiler and OS vendors weren't required
to keep on fixing the issues caused by C's widespread into the industry?

~~~
twoodfin
If C did not exist, it would be necessary to invent it.

There is CPU-bound code out there, where every cycle saved in an inner loop
equates to hours of improved runtime or thousands of additional client
transactions/second. Safer languages have made great strides in the kinds of
dynamic profiling and optimization that can equal the performance of optimized
C/C++, but there remain real penalties in startup and profiling time.

~~~
habitue
I think some things like null terminated strings etc are not inevitable in a
fast language like C. There were definitely design mistakes that cost security
and don't directly affect performance significantly.

~~~
_delirium
If anything, null-terminated strings are bad for performance as often as good
for it. One example that comes up reasonably often: comparing strings that
have different lengths but common prefixes is fast with length-tagged (Pascal-
style) strings, but expensive with C-style strings, because you have to scan
both strings until you find either a string end, or a difference. So instead
of quickly answering "not equal" after one integer comparison, you could end
up doing hundreds (or thousands) of byte comparisons in degenerate cases.
Anything that calls strlen() also ends up doing extra work.

~~~
adobriyan
Well, as far as kernel is concerned strings aren't a problem. Outside VFS they
don't exist. Inside VFS everything is chopped into usually short pathname
components which are hashed for dcache consumption. On x86_64 hashing is not
byte-by-byte anymore.

Fixing pathetic macro system and type system (if that qualifies at all) would
get rid of many many bugs.

------
d0
Isn't this the same as what the OpenBSD guys added to their GCC fork? I think
it was called ProPolice.

~~~
Someone
According to
[http://en.wikipedia.org/wiki/Buffer_overflow_protection#GNU_...](http://en.wikipedia.org/wiki/Buffer_overflow_protection#GNU_Compiler_Collection_.28GCC.29),
it was IBM that developed ProPolice, and this is an evolution of a
reimplementation by RedHat.

~~~
d0
Gotcha - thanks for the correction. Checked my sources and it was W^X they
implemented at the same time as ProPolice and indeed it was IBM who built
that.

