The new slab memory controller: Saving 30~40%+ Of Memory, Less Fragmentation

erek

[H]F Junkie
Joined
Dec 19, 2005
Messages
10,786
Pretty darn baller if you ask me! Amazing work!

"Obviously the amount of saved memory depend on the number of memory cgroups,
uptime and specific workloads, but overall it feels like the new controller
saves 30-40% of slab memory, sometimes more. Additionally, it should lead
to a lower memory fragmentation, just because of a smaller number of
non-movable pages and also because there is no more need to move all
slab objects to a new set of pages when a workload is restarted in a new
memory cgroup."

https://lkml.org/lkml/2019/9/5/1132
 
i scan the article and saw shared memory. makes me think this way will be exploited for other programs to read others memory
 
i scan the article and saw shared memory. makes me think this way will be exploited for other programs to read others memory

:(


so like the HyperThreading security issues of Spectre and or Meltdown? what if they got builtin isolation and segmentation?
 
i scan the article and saw shared memory. makes me think this way will be exploited for other programs to read others memory
Shared memory is by definition insecure. If you know the memory register, you can access the memory. If you want secure memory storage, you need to use private memory or obfuscate the contents (though there are issues with that as well).

Edit: well, Linux supports ACLs (access control lists) for files in the shm (shared memory) filesystem, but I don't know if that applies to programs directly accessing the register.
 
Shared memory is by definition insecure. If you know the memory register, you can access the memory. If you want secure memory storage, you need to use private memory or obfuscate the contents (though there are issues with that as well).

Edit: well, Linux supports ACLs (access control lists) for files in the shm (shared memory) filesystem, but I don't know if that applies to programs directly accessing the register.

what about using Semaphores for Inter-Process Communication of Shared Memory Segments for security?

@ Shared memory secured write using semaphore
 
  • Like
Reactions: Nobu
like this
what about using Semaphores for Inter-Process Communication of Shared Memory Segments for security?

@ Shared memory secured write using semaphore

Also

Securing Inter-process Communications in SELinux


"Exploration into the various forms of IPC in SELinux has revealed numerous information flows between processes. Most of these information flows are part of the IPC mechanism themselves, the forward channel. In addition, there are back channels typically used to transfer data related to the control of the forward channel. An optimal solution would provide IPC that is high bandwidth with no back channels. These back channels do not preclude the use of any of the mechanisms described here. Rather, the system architect must take the back channels into account and strike a balance between security and functionality. A similar balance is shown in the development of a combination of IPC mechanisms that possesses a high bandwidth forward channel with a low bandwidth back channel. A proof of concept of the implementation outlined in section 4 has been written and is available at http://oss.tresys.com. This library provides an API to create unidirectional IPC between processes and SELinux policy to ensure unidirectionality. In the proof of concept implementation IPC keys are determined at application build time so that there is no need for a heavy and bidirectional synchronization protocol."
 
  • Like
Reactions: Nobu
like this
Yeah, you can lock it down, but there is still some level of trust you have to establish between the applications who have access. Keep the keys safe, and all that.

Gotta make sure there's no pebkac. Lol
 
Back
Top