Re: RFC v2: post-init-read-only protection for data allocated dynamically

[Igor Stoppa]

On 04/05/17 17:30, Dave Hansen wrote:
> On 05/04/2017 01:17 AM, Igor Stoppa wrote:
>> Or, let me put it differently: my goal is to not fracture more pages
>> than needed.
>> It will probably require some profiling to figure out what is the
>> ballpark of the memory footprint.
> 
> This is easy to say, but hard to do.  What if someone loads a different
> set of LSMs, or uses a very different configuration?  How could this
> possibly work generally without vastly over-reserving in most cases?

I am probably making some implicit assumptions.
Let me try to make them explicit and let's see if they survive public
scrutiny, and btw while writing it, I see that it probably won't :-S

Observations
------------

* The memory that might need sealing is less or equal to the total
  r/w memory - whatever that might be.

* In practice only a subset of the r/w memory will qualify for sealing.

* The over-reserving might be abysmal, in terms of percentage of
  actually used memory, but it might not affect too much the system, in
  absolute terms.

* On my machine (Ubuntu 16.10 64bit):

  ~$ dmesg |grep Memory
  [    0.000000] Memory: 32662956K/33474640K available (8848K kernel
  code, 1441K rwdata, 3828K rodata, 1552K init, 1296K bss, 811684K
  reserved, 0K cma-reserved)

* This is the memory at boot, I am not sure what would be the right way
to get the same info at runtime.


Speculations
------------

* after loading enough modules, the rwdata is 2-3 times larger

* the amount of rwdata that can be converted to rodata is 50%;
  this is purely a working assumption I am making, as I have no
  measurement yet and needs to be revised.

* on a system like mine, it would mean 2-3 MB


Conclusions
-----------

* 2-3 MB with possibly 50% of utilization might be an acceptable
compromise for a distro - as user I probably wouldn't mind too much.

* if someone is not happy with the distro defaults, every major distro
provides means to reconfigure and rebuild its kernel (the expectation is
that the only distro users who are not happy are those who would
probably reconfigure the kernel anyway, like a data center)

* non distro-users, like mobile, embedded, IoT, etc would do
optimizations and tweaking also without this feature mandating it.

--

In my defense, I can only say that my idea for this feature was to make
it as opt-in, where if one chooses to enable it, it is known upfront
what it will entail.
Now we are talking about distros, with the feature enabled by default.

TBH I am not sure there even is a truly generic solution, because we are
talking about dynamically allocated data, where the amount is not known
upfront (if it was, probably the data would be static).


I have the impression that it's a situation like:
- efficient memory occupation
- no need for profiling
- non fragmented pages

Choose 2 of them.


Of course, there might be a better way, but I haven't found it yet,
other than the usual way out: make it a command line option and let the
unhappy user modify the command line that the bootloader passes to the
kernel.

[...]

> I'm starting with the assumption that a new zone isn't feasible. :)

I really have no bias: I have a problem and I am trying to solve it.
I think the improvement could be useful also for others.

If the problem can be solved in a better way than what I proposed, it is
still good for me.

---
igor