[PATCHv2 00/18] arm64: mm: rework page table creation

[mark.rutland@arm.com (Mark Rutland)]

On Tue, Jan 05, 2016 at 11:17:55AM -0800, Laura Abbott wrote:
> On 01/05/2016 10:58 AM, Mark Rutland wrote:
> >>>>This series points out that my attempt to allow set_memory_* to
> >>>>work on regular kernel memory[1] is broken right now because it breaks down
> >>>>the larger block sizes.
> >>>
> >>>What's the rationale for set_memory_* on kernel mappings? I see
> >>>"security", but I couldn't figure out a concrete use-case. Is there any
> >>>example of a subsystem that wants to use this?
> >>
> >> From the description, it sounded like this was possibly new work but
> >>the eBPF interpreter currently supports setting a page read only via
> >>set_memory_ro (see 60a3b2253c413cf601783b070507d7dd6620c954
> >>"net: bpf: make eBPF interpreter images read-only") so it's not
> >>unheard of.
> >
> >Oh. For some reason I thought that used the vmalloc area, but evidently
> >I was mistaken.
> >
> >That is unfortunate, it would be good to protect the JITed code.
> >
> >>>For statically-allocated data, an alternative approach would be for such
> >>>memory to be mapped with minimal permissions from the outset (e.g. being
> >>>placed in .rodata), and when elevated permissions are required a
> >>>(temporary) memremap'd alias could be used, like what patch_map does to
> >>>modify ROX kernel/module text.
> >>>
> >>>For dynamically-allocated data, we could create (minimal permission)
> >>>mappings in the vmalloc region and pass those around. The linear map
> >>>alias would still be writeable, but as the offset between the two isn't
> >>>linear (and the owner of that allocation doesn't have to know/care about
> >>>the linear map address), it would be much harder to find the linear map
> >>>address to attack. An alias with elevated permissions could be used as
> >>>required, or if it's a one-time RW->RO switch, the mapping could me
> >>>modified in-place as the granularity wouldn't change.
> >>
> >>This would work for new features but probably not for existing features
> >>such as the eBPF interpreter.
> >
> >Sure.
> >
> >For eBPF it might be possible to rework the code to support using
> >separate aliases, but that's probably not going to be easy and that
> >probably works against some performance requirement. :/
> 
> Ah no, you are correct, I misread how the code was working. The eBPF code
> does use vmalloc so that can easily be fixed up.

Ah, phew. Thanks for digging into that.

> I think your suggestion of either using vmalloc or a special static
> section is the best recommendation. If anyone really thinks they need
> to change any other memory they can make a proposal.

Sounds good to me.

> Sorry for the confusion.

No worries.

Thanks,
Mark.