Messages in this thread | | | From | Kees Cook <> | Date | Wed, 21 Feb 2018 14:22:10 -0800 | Subject | Re: arm64 physmap (was Re: [kernel-hardening] [PATCH 4/6] Protectable Memory) |
| |
On Tue, Feb 20, 2018 at 8:28 AM, Igor Stoppa <igor.stoppa@huawei.com> wrote: > > > On 14/02/18 21:29, Kees Cook wrote: >> On Wed, Feb 14, 2018 at 11:06 AM, Laura Abbott <labbott@redhat.com> 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
| |