On 5/14/19 9:09 AM, Peter Zijlstra wrote:
On Mon, May 13, 2019 at 11:18:41AM -0700, Andy Lutomirski wrote:
On Mon, May 13, 2019 at 7:39 AM Alexandre Chartre
<alexandre.chartre@xxxxxxxxxx> wrote:
pcpu_base_addr is already mapped to the KVM address space, but this
represents the first percpu chunk. To access a per-cpu buffer not
allocated in the first chunk, add a function which maps all cpu
buffers corresponding to that per-cpu buffer.
Also add function to clear page table entries for a percpu buffer.
This needs some kind of clarification so that readers can tell whether
you're trying to map all percpu memory or just map a specific
variable. In either case, you're making a dubious assumption that
percpu memory contains no secrets.
I'm thinking the per-cpu random pool is a secrit. IOW, it demonstrably
does contain secrits, invalidating that premise.
The current code unconditionally maps the entire first percpu chunk
(pcpu_base_addr). So it assumes it doesn't contain any secret. That is
mainly a simplification for the POC because a lot of core information
that we need, for example just to switch mm, are stored there (like
cpu_tlbstate, current_task...).
If the entire first percpu chunk effectively has secret then we will
need to individually map only buffers we need. The kvm_copy_percpu_mapping()
function is added to copy mapping for a specified percpu buffer, so
this used to map percpu buffers which are not in the first percpu chunk.
Also note that mapping is constrained by PTE (4K), so mapped buffers
(percpu or not) which do not fill a whole set of pages can leak adjacent
data store on the same pages.
alex.
