On Tue, Feb 20, 2018 at 8:28 AM, Igor Stoppa <igor.stoppa@xxxxxxxxxx> wrote: > > > 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? Right, I mean, if an attacker has already gained execute control, they can just call the needed functions to change memory permissions. But that isn't needed if there is a mismatch between physmap and virtmap: i.e. they can write to the physmap without needing to change perms first. > 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? I meant that I don't want a difference in protection between physmap and virtmap. I'd like to be able to reason the smae about the exposures in either. > 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. Right, this is good, for sure. No complaints there at all. It's why I think pmalloc and arm64 physmap perms are separate issues. -Kees -- Kees Cook Pixel Security -- 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>
