both PAGEEXEC and SEGMEXEC predate the existence of the NX bit (2000/2002, respectively), be that amd's or intel's.
dude, you have NO idea what you're talking about. the problem was NOT with the bounds checking feature per se but how the KSPP botched up their attempt to rip off some code i wrote a year ago which has none of these issues.
2
2
he does when security is at odds with usability. in the USERCOPY case it isn't since our code works just fine unlike the upstream ripoff attempt ;).
2
Torvalds' rants about the incompetence of the KSPP: lkml.org/lkml/2017/11/17/423 and lkml.org/lkml/2017/11/17/767 . no wonder linux security suffers from both sides as the end result. the 90's idea of debugging == security has been dead ever since.
1
20
3
43
two tidbits about CVE-2017-5123: it's also a KASLR break (quiz: how?) and UDEREF on i386 makes it harmless (SMAP/etc are vulnerable).
2
6
7
perhaps @kurtseifried wants to chime in with another completely unwarranted CVE? :)
#grsecurity/PaX never affected by seclists.org/oss-sec/2017/q3… even prior to 2015 fix (which RHEL 6/<7.4 didn't apply), has separate ET_DYN base
1
1
5
...so do you have an exploit or not? the time you spent on twitter for the past year should have been enough for one... ;)
1
it's gcc code, not mine. bug vs. feature depends on intent, for security purposes i considered it a bug and fixed it.
1
that is a gcc codegen issue (fixed in RAP) and you never demonstrated anything with it. any other excuses? ;)
1
and what happens if those binaries and source code are redistributed to the public? service contract termination?
1
where are the broken out kernel patches for RHEL again? oh wait... Red Hat threatens service contract termination if anyone 'leaks' them.
1
3
i must have missed something here but why aren't we on good terms? feel free to email me if it's not the right medium.
1
well, it's an early testament to the KSPP's ability to 'innovate' and their way of acknowledging their source of knowledge ;P.
3