On 14/02/18 21:29, Kees Cook wrote: > On Wed, Feb 14, 2018 at 11:06 AM, Laura Abbott <labbott@xxxxxxxxxx> wrote: [...] >> Kernel code should be fine, if it isn't that is a bug that should be >> fixed. Modules yes are not fully protected. The conclusion from past > > I think that's a pretty serious problem: we can't have aliases with > mismatched permissions; this degrades a deterministic protection > (read-only) to a probabilistic protection (knowing where the alias of > a target is mapped). Having an attack be "needs some info leaks" > instead of "need execution control to change perms" is a much lower > bar, IMO. Why "need execution control to change permission"? Or, iow, what does it mean exactly? ROP/JOP? Data-oriented control flow hijack? Unless I misunderstand the meaning of "need execution control", I think that "need write capability to arbitrary data address" should be sufficient, albeit uncomfortable to use. OTOH, "need read/write capability from/to arbitrary data address" would be enough, I think, assuming that one knows the offset where to write to - but that information could be inferred, for example, by scanning the memory for known patterns. IMHO the attack surface is so vast that it's not unreasonable to expect that it will be possible to fish out means to perform arbitrary R/W into kernel address space. Ex: some more recent/less tested driver. One can argue that this sort of R/W activity probably does require some form of execution control, but AFAIK, the only way to to prevent it, is to have CFI - btw, is there any standardization in that sense? So, from my (pessimistic?) perspective, the best that can be hoped for, is to make it much harder to figure out where the data is located. Virtual mapping has this side effect, compared to linear mapping. But, once easier attack targets are removed, I suspect the page mapping will become the next target. -- igor -- To unsubscribe, send a message with 'unsubscribe linux-mm' in the body to majordomo@xxxxxxxxx. For more info on Linux MM, see: http://www.linux-mm.org/ . Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a>
