Linux Secret Memory "secretmemfd" System Call Remains Under Review

[phoronix]

Phoronix: Linux Secret Memory "secretmemfd" System Call Remains Under Review

A few months back we wrote of experimental work for creating "secret" memory areas with memfd and now that work has turned into the secretmemfd system call that is under review...

http://www.phoronix.com/scan.php?page=news_item&px=Linux-Secret-secretmemfd

[ddriver]

Umm, isn't process mapped memory only visible to that process the default, and if not, why isn't it?

It would seem that process memory should be exclusive to that process, unless some explicit and authorized mechanism for inter process communication is involved, and even then it should be carefully scoped and interfaced.

[bridgman]

Umm, isn't process mapped memory only visible to that process the default, and if not, why isn't it?

I think this is more about hiding from things like /dev/mem, and from the hypervisor when running in a VM.

[Jakobson]

I think this is more about hiding from things like /dev/mem, and from the hypervisor when running in a VM.

Neither kernel or root user can see the content of that memory area.

[cjcox]

You had the opportunity to call it seatecastronomyd and you didn't?

[Lycanthropist]

A debugger is also able to read the memory contents of another process. I assume this won't be possible with those secret memory pages.

[Etherman]

Umm, isn't process mapped memory only visible to that process the default, and if not, why isn't it?

It would seem that process memory should be exclusive to that process, unless some explicit and authorized mechanism for inter process communication is involved, and even then it should be carefully scoped and interfaced.

The kernel needs access to the memory for swapping to disk.

[ix900]

I don't know, would think if it can be hidden then it can be found and that someone will eventually find a way to get at it in a non-legit way. Maybe it will be better to have it than to not but also maybe the added complexity will cause added security holes.

This is one that should probably be heavily scrutinized.

[waxhead]

I don't know anything about the to secretmemfd stuff but I would assume it is intended to prevent memory pages from being swaoped to disk and prevent the memory pages from being reused by another process without zeroing it out first. E.g turning a malloc() to a calloc() or putting used pages in a blacklist which can be zeroed at some point.

[ddriver]

A debugger is also able to read the memory contents of another process. I assume this won't be possible with those secret memory pages.

Debugging requires a debug build, which has a tremendous amount of additional hooks and whatnot, which is why it is also so important to be careful not to ship debug builds by mistake.