KSPP fairy tale du jour: openwall.com/lists/kernel-ha… … (hint: if RANDKSTACK was inspired by stackjacking then how could the supposed inspiring presentation have talked about it? perhaps because in reality it had already existed for almost a decade? :))
2
5
12
A Systematic Evaluation of Transient Execution Attacks and Defenses:
arxiv.org/abs/1811.05441
1
4
9
Looks like @paxteam was right by a decade... as usual.
The amount of people who trully understand (like, with knowing what's inside the kernel) all code interactions when creating/manipulating namespaces is IMO not that great. (btw, @_tsuro is one of them). Seems like ns's were created for functionality/features, not for security.
1
2
6
After we conjugated through all possible permutations of "apply ML wrongly to a security problem which is, in fact, adversarial", I really do not like how some people seem to like going through "conjugate through all possible permutations of how these can be broken"....
3
4
36
Sorry just frustrated to hear an arbitrary # that is violated by the the one setting it.I get comparing sec vs perf.Both MMU integrity and ROP defense are essential. I also get our 3% isn’t on a (claimed but debatably) better benchmark.Reconciling perf reqs?Can’t, it’s arbitrary.
4
as for RAP's impact, i never said i was happy with it but it's the best what a sw approcah can do and it's acceptable for many use cases already, just not necessarily for something like Windows/etc (perf impact is just but one reason for that too).
1
as you may have guessed, we had already thought of all this (and much more) way back in 2002-2003 when KERNEXEC and other self-proteciton ideas were born but never had a full implementation exactly because of the expected perf impact.
1
it's not an arbitrary number but what i heard from industry players and one of the reason why many defenses never made it to widely deployed commercial OSs. 3% for a half-baked implementation isn't going to cut it, especially when it grows further when fully implemented.
"As a demonstration of its high security benefit to performance cost ratio, we're also providing the following benchmarks below, where RAP demonstrates a 5.4% performance hit in a "worst-case" kernel-bounded workload." No one uses RAP then? I respect you but don't waste my time.
3
what's with the ad hominem? RAP's security value is proportional to its worst case impact (and can be further improved with hw support, like how it happened with NX/SMEP/SMAP/etc). also i don't set those expectations, industry players do (and are working hard to achieve them).
Not buying your arg on performance. You quote micro benchmarks, but in macro we see < 3% overhead (on FreeBSD) when compiling the kernel for MMU isolation alone. This without batching updates to the MMU, zero optimizations. We do however mess with superpages, a good arg from pax.
4
as for <3% overhead: it's WAY too much when in practice the TOTAL budget you have for ALL security related changes is single digit impact for the WORST case. consequently, the perf impact of any security enhancement must be proportional to its overall security value.
1
kernel compilation has a userland and a kernel side component. your change in the kernel cannot be measured by involving the userland component, you'd have to extract the kernel component for that. it's better to run a kernel-oriented test like 'du -s' which is 99% kernel time.
This is precisely why PaX/RAP will never be used broadly. ¯\_(ツ)_/¯ I openly document/evaluate an undocumented CFI implementation, share a pre-compiled plugin for reproduction (with links to GPL'd patch and kernel sources), then get threatened.
i think you had enough time to fix the GPL violation in your repo. if you don't remedy it now, you'll leave me no choice but to ask github to take it down. this is your last warning.
2
4
9
I assumed that the grsecurity homepage was a reasonable site to link to for source. As you claim otherwise, I've now included the patch in the repository. Note that I would only violate the GPL if the patch were no longer available on grsecurity. 🤗🙃
1
2
interesting paper from SP19: SoK: The Challenges, Pitfalls, and Perils of Using Hardware Performance Counters for Security
(pdf: computer.org/csdl/proceeding… abstract: computer.org/csdl/proceeding…)
15
26
Believing in numbers and fair evaluation, I've compared RAP and LLVM-CFI. RAP is faster, LLVM-CFI is more precise. RAP is incredibly hard to use and its future is uncertain while LLVM-CFI is just a command line argument away. Details at nebelwelt.net/blog/20181226-… Comments welcome 🤗
18
28
79
Linux kernel 4.20 included the KSMA mitigation completed by C0RE Team @_2freeman. Here's a post in Chinese: c0reteam.org/2019/01/02/ksma
1
23
3
40
But I think this came up even more recently (say within the past 2 or 3 years) when some researchers found they couldn't attack a grsec kernel's top level page tables like they could on some other OSes (but didn't understand why, iirc) Can't seem to find the tweets here about it
2
That doesn’t make sense to me. Virtual space has to be contiguously mapped and physical can be non-contiguous for LargePT right? And it works dyanamically I think: Just add small LargePT region allocator. I’m not convinced it’s any harder than any of the other Linux allocators.
1
large page maps are contiguous in both physical and virtual AS, that's what makes the TLB efficient and breaking them up not so good for performance.. if you don't break them up then you'll soon litter the AS with read-only maps (needed for PTs) and then users will complain :).
This is on you, not me. I offered several times to take this to email, yet you continue to harass me over twitter. My real name and email is public. I don't even know who's behind @grsecurity or @paxteam. Your choice.
2
1
as i asked you here nitter.vloup.ch/paxteam/status/1… already, you had all the time to actually reach out instead of 'offering' it. why haven't you? and did you or did you not evaluate RAP before your rampage of the past 2 weeks? either way, you got caught lying :).
what compatibility issues and why did you never report anything to me? FWIW, the public version works with linux fine, it's production quality.
2
DMAP: fun one that I haven’t looked at. Maybe handle by reserving large chunks of the address space for these data types? Roughly already do for code and the heap. So take a few GBs of address space for each type. Actually, just alloc in chunks of 1GB/2MB?
1
static reservation (of physical memory, address space doesn't matter, we have enough of that on 64 bit) doesn't scale in real life, there's always a workload somewhere that runs out of memory. the solution has to be dynamic (runtime) partitioning and have 0 impact, that's hard ;)
1
Why do you get so worked up about a couple of citations? IIRC we cite FPValidator in the survey (on mobile so can't check). There's almost 100 CFI papers, due to page limits most cite and discuss the most memorable ones. We also cited your non-exec work a couple of times
2
1
i care about holding people up to their own standards. AFAIK, you never cited FPValidator nor my non-exec work (it's MS/DEP or W^X). FPValidator is important 'cos it's the closest thing to RAP and being from 2009, it predates most academic CFI work.
Perf: only bad on PT updates (fork, mmap, etc) so kernel sees 0 overhead if not doing that. Codegen: pages mapped NX+W, then client requests code map, then scan, then RO+X. Large pages: not bad: only need 4 types: RO+NX (Const Data+PTs), RO+X (code), W+NX (data), USER (SMEP+SMAP)
2
how do you prevent JIT'ing in some useful code sequence that's executed as gadgets (i.e., code scanning, presumably, wouldn't flag it?). for large pages, how do you handle the very dynamic nature of page tables w/o breaking up large pages (1GB/2MB) in the direct map all the time?
2