On Tue, Feb 20, 2018 at 8:28 AM, Igor Stoppa [off-list ref] wrote:

On 14/02/18 21:29, Kees Cook wrote:

quoted

On Wed, Feb 14, 2018 at 11:06 AM, Laura Abbott [off-list ref] wrote:

[...]

quoted

quoted

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