Re: [PATCH -mm v9 0/8] idle memory tracking

On Tue, Jul 21, 2015 at 4:34 PM, Andrew Morton
[off-list ref] wrote:

On Sun, 19 Jul 2015 15:31:09 +0300 Vladimir Davydov [off-list ref] wrote:

quoted

To mark a page idle one should set the bit corresponding to the
   page by writing to the file. A value written to the file is OR-ed with the
   current bitmap value. Only user memory pages can be marked idle, for other
   page types input is silently ignored. Writing to this file beyond max PFN
   results in the ENXIO error. Only available when CONFIG_IDLE_PAGE_TRACKING is
   set.

   This file can be used to estimate the amount of pages that are not
   used by a particular workload as follows:

   1. mark all pages of interest idle by setting corresponding bits in the
      /proc/kpageidle bitmap
   2. wait until the workload accesses its working set
   3. read /proc/kpageidle and count the number of bits set

Security implications.  This interface could be used to learn about a
sensitive application by poking data at it and then observing its
memory access patterns.  Perhaps this is why the proc files are
root-only (whcih I assume is sufficient).  Some words here about the
security side of things and the reasoning behind the chosen permissions
would be good to have.

As long as this stays true-root-only, I think it should be safe enough.

quoted

 * /proc/kpagecgroup.  This file contains a 64-bit inode number of the
   memory cgroup each page is charged to, indexed by PFN.

Actually "closest online ancestor".  This also should be in the
interface documentation.

quoted

Only available when CONFIG_MEMCG is set.

CONFIG_MEMCG and CONFIG_IDLE_PAGE_TRACKING I assume?

quoted

   This file can be used to find all pages (including unmapped file
   pages) accounted to a particular cgroup. Using /proc/kpageidle, one
   can then estimate the cgroup working set size.

For an example of using these files for estimating the amount of unused
memory pages per each memory cgroup, please see the script attached
below.

Why were these put in /proc anyway?  Rather than under /sys/fs/cgroup
somewhere?  Presumably because /proc/kpageidle is useful in non-memcg
setups.

Do we need a /proc/vm/ for holding these kinds of things? We're
collecting a lot there. Or invent some way for this to be sensible in
/sys?

-Kees

-- 
Kees Cook
Chrome OS Security