Joined February 2010
blame is what you're trying to do, identifying the root cause isn't ;).
1
it's not a bug but a problem with gcc (recognized by gcc devs too).
defenses don't create bugs, humans do ;).
1
no, the first problem (not bug per se) was due to gcc internals, the defense itself was fine.
there're many bugs our defenses caught over the years, just browse lkml or our forums.
1
no, the bug was human error, whereas the defense was automated.
1
Replying to @Evil_X_ @rootkovska
size overflow, RAP, etc work in userland too and we're not done yet ;).
1
sure, it's proven itself time and again, not many defenses can say the same.
1
Replying to @rootkovska
they have the same computing power. that's where unbreakable sandboxes come into the picture. the race's on ;).
1
@lolhaq @Snowden @subgraph @QubesOS @marcan42 that's a great example of how our defenses protect against even our own bugs. thanks!
2
Replying to @i0n1c
that wouldn't be a fix since you can't click what doesn't exist ;).
Replying to @rootkovska
sure, that's the whole raison d'etre of my work.
3
2
Replying to @rootkovska
and PaX is more than memory corruption prevention. think grsec, sandboxes, etc. it's just not me who does all the work ;).
1
3
the whole point of PaX is that you *can* click any OK button without getting owned. not there yet but close :).
1
11
2
18
Replying to @kangsterizer
'free' in english is ambiguous, see gnu.org/philosophy/free-sw.h…
Replying to @kangsterizer
so the stable code is libre but not gratuit. i find the use of 'freely' in that context rather disingenuous.
1
Replying to @kangsterizer
perhaps something got lost in translation as the license never changed, it's still GPLv2 (that of the kernel).
but if you know of a better way that also meets the other features of RAP (e.g., performance, scalability), do share.
and with type diversification (programmer action) it can be arbitrarily refined to approach the intended CFG.
the RAP type hash extracts the maximum information i could think of and what the languges allow.