| Message ID | 20230314204557.3863923-1-shr@devkernel.io (mailing list archive) |
|---|---|
| State | New |
| Headers | show |
| Series | [v1] docs/mm: extend ksm doc | expand |
On Tue, Mar 14, 2023 at 01:45:57PM -0700, Stefan Roesch wrote: > +to cancel that advice and restore unshared pages: whereupon KSM > +unmerges whatever is merged for that process. Note: this unmerging call > +may suddenly require more memory than is available - possibly failing > +with EAGAIN, but more probably arousing the Out-Of-Memory killer. "... to disable KSM and let it unmerges ... . Note that this unmerging call may exhaust memory and triggers OOM killer." > +However, if the system is dedicated to running multiple jobs within the > +same security domain, there is a usecase where multiple instances of the > +same job are running inside a safe shared security domain and using the > +same sensitive data. "... it is possible for multiple instances ... and share the same sensitive data." Thanks.
Hi-- On 3/14/23 20:59, Bagas Sanjaya wrote: > On Tue, Mar 14, 2023 at 01:45:57PM -0700, Stefan Roesch wrote: >> +to cancel that advice and restore unshared pages: whereupon KSM >> +unmerges whatever is merged for that process. Note: this unmerging call >> +may suddenly require more memory than is available - possibly failing >> +with EAGAIN, but more probably arousing the Out-Of-Memory killer. > > "... to disable KSM and let it unmerges ... . Note that this unmerging > call may exhaust memory and triggers OOM killer." I can't tell exactly what is being proposed here, but "let it unmerges" is not good & proper... Perhaps fewer ellipses and more complete sentences are in order. >> +However, if the system is dedicated to running multiple jobs within the >> +same security domain, there is a usecase where multiple instances of the >> +same job are running inside a safe shared security domain and using the >> +same sensitive data. > > "... it is possible for multiple instances ... and share the same > sensitive data." > > Thanks. >
Bagas Sanjaya <bagasdotme@gmail.com> writes: > [[PGP Signed Part:Undecided]] > On Tue, Mar 14, 2023 at 01:45:57PM -0700, Stefan Roesch wrote: >> +to cancel that advice and restore unshared pages: whereupon KSM >> +unmerges whatever is merged for that process. Note: this unmerging call >> +may suddenly require more memory than is available - possibly failing >> +with EAGAIN, but more probably arousing the Out-Of-Memory killer. > This follows the wording in the previous paragraph, do you also want to change the previous paragraph? > "... to disable KSM and let it unmerges ... . Note that this unmerging > call may exhaust memory and triggers OOM killer." > >> +However, if the system is dedicated to running multiple jobs within the >> +same security domain, there is a usecase where multiple instances of the >> +same job are running inside a safe shared security domain and using the >> +same sensitive data. > > "... it is possible for multiple instances ... and share the same > sensitive data." > Something like this? >> +However, if the system is dedicated to running multiple jobs within the >> +same security domain, there is a usecase where multiple instances of the >> +same job are running inside a safe shared security domain and share the >> +same sensitive data. > The is possible I think is less clear. Thanks.
diff --git a/Documentation/admin-guide/mm/ksm.rst b/Documentation/admin-guide/mm/ksm.rst index d2929964cd0f..ba75d628f6d7 100644 --- a/Documentation/admin-guide/mm/ksm.rst +++ b/Documentation/admin-guide/mm/ksm.rst @@ -20,13 +20,15 @@ content which can be replaced by a single write-protected page (which is automatically copied if a process later wants to update its content). The amount of pages that KSM daemon scans in a single pass and the time between the passes are configured using :ref:`sysfs -intraface <ksm_sysfs>` +interface <ksm_sysfs>` KSM only merges anonymous (private) pages, never pagecache (file) pages. KSM's merged pages were originally locked into kernel memory, but can now be swapped out just like other user pages (but sharing is broken when they are swapped back in: ksmd must rediscover their identity and merge again). +.. _ksm_madvise: + Controlling KSM with madvise ============================ @@ -68,6 +70,43 @@ Applications should be considerate in their use of MADV_MERGEABLE, restricting its use to areas likely to benefit. KSM's scans may use a lot of processing power: some installations will disable KSM for that reason. +Controlling KSM with prctl +============================ + +KSM can be enabled for a process or a cgroup, by using the prctl(2) system +call:: + + int prctl(PR_SET_MEMORY_MERGE, 1) + +The app may call + +:: + + int prctl(PR_SET_MEMORY_MERGE, 0) + +to cancel that advice and restore unshared pages: whereupon KSM +unmerges whatever is merged for that process. Note: this unmerging call +may suddenly require more memory than is available - possibly failing +with EAGAIN, but more probably arousing the Out-Of-Memory killer. + +The restrictions mentioned in :ref:`Controlling KSM with madvise <ksm_madvise>`' +also apply here. Also consider the security implications of using KSM. + +KSM security concerns +======================= + +KSM has the possibility of memory side channel attacks. When individual +VMA's have KSM enabled, the security aspect needs to be considered. + +An individual workload doesn't know what else is running on +the machine, so it needs to be highly conservative about what it can +give up for system-wide merging. + +However, if the system is dedicated to running multiple jobs within the +same security domain, there is a usecase where multiple instances of the +same job are running inside a safe shared security domain and using the +same sensitive data. + .. _ksm_sysfs: KSM daemon sysfs interface
This adds a description of the new prctl interface for KSM and also adds a general section on security concerns. Signed-off-by: Stefan Roesch <shr@devkernel.io> --- Documentation/admin-guide/mm/ksm.rst | 41 +++++++++++++++++++++++++++- 1 file changed, 40 insertions(+), 1 deletion(-) base-commit: 5faf25f023d8816a49e168930218ffdb75d5d853