Linux 5.14 Can Create Secret Memory Areas With memfd_secret

[Vorpal]

But there is already Trusted Computing Module (TPM). Or is this for systems without that?
Maybe TPM is better.
Or is this just a way to sneak in DRM?

TPM is a completely unrelated technology solving diffrent issues in different ways.

Also it would be difficult to use the secret memory functionality for effective DRM: you could patch your kernel and the userspace would never know. And on platforms where that is difficult (e.g. Android or Chromebook) the system is sufficiently locked down that this feature won't come into play anyway when it comes to jailbreaking.

[Turbine]

Wouldn't that make it easier to get sensitive data on compromised systems?

How did you come to this conclusion?

There's a lot of misinformation. This is a great idea to improve the security of reading out information from memory, without reducing performance.

[arQon]

I haven't looked at the patches, but I'm assuming any memory used this way would implicitly become non-pageable. "Real" use is likely to be small amounts only, but buggy code / malware would potentially be able to use this to exhaust all physical RAM, I expect, creating a new DoS vector.

Given how terrible Linux's memory-exhaustion handling code is anyway though, it probably won't make any difference in practice. :P

[Vorpal]

How did you come to this conclusion?

There's a lot of misinformation. This is a great idea to improve the security of reading out information from memory, without reducing performance.

Are there good tests on that yet? It could at least in theory decrease the performance slightly (at least in an earlier version of the patch) since it would result in a hole in the linear mapping of the physical ram that the kernel has. This would result in not being able to use huge pages for said mapping, instead needing to split that into smaller sizes, which in turn results in more tlb misses.

I haven't checked if the current version is also affected by this.

[ddriver]

How did you come to this conclusion?

There's a lot of misinformation. This is a great idea to improve the security of reading out information from memory, without reducing performance.

What misinformation? And while on the subject, where is your countering "legit information"?

I forgot we read our super duper secret keys like all the time - gigabytes and gigabytes per second, so every last drop of perf matters, right? It is not like this will be used rarely, to establish sessions and such, and maybe penalizing it has close to no actual effect on system performance and is well worth the increase in security?

My initial thought was that by using a dedicated system call we are simply putting a label "critical security information right here" on said allocations. That's like having a separate stacks of needles and stacks of hay, making needles much easier to find them compared to looking for the needles in the hay stacks. That's just basic common sense, not in any way the product of any of that so called "misinformation".

But also, if the kernel doesn't "know" about this memory, what mechanism would prevent it from allocating for something else? Would it be a discrete pool of memory reserved for that purpose alone, and if so, wouldn't that just condense critical security information into an even consolidated chunk of memory, making it trivial to be obtained by firmware attacks or low level hardware management features?

Seems like a god-sent feature for corporate espionage, making it essentially trivial for firmware vendors to obtain master keys and such and auction to interested parties... I am sure those guys feel left out and missing out, given the massive revenue some corporations make on selling regular Joe's private data, and this would be a tremendously more lucrative prospect.

Dunno, maybe I am a bit too suspicious, but security advancements seem a tad lopsided. It just doesn't seem all potential threats are treated equally, instead the features seem to make it harder for more trivial, "third party" attacks, at the cost of making it much easier for insiders to abuse, requiring an increasing amount of trust into hardware and firmware vendors, increasing the reward for such exploits. IMO good security comes from mistrusting everyone, especially those that work for you and those you lie in bed with so to speak, but again, that might be just me.

[coder]

Would this work correctly with suspend/hibernation? If it supports swap, then I'm guessing the answer is yes?

[hoohoo]

... There's a lot of misinformation. ...

You got that right! I had a knee jerk chain reaction, and I had to deliberately take a step back and think it over: hiding data on the system... rootkit... bad things. I don't think that is what is enabled here though.

[hoohoo]

Would this work correctly with suspend/hibernation? If it supports swap, then I'm guessing the answer is yes?

Lots of questions about this tech, and I think you have just asked a goood on. What happens to secrecy when the secret data gets written to a disk file or partition?

[oiaohm]

Would this work correctly with suspend/hibernation? If it supports swap, then I'm guessing the answer is yes?

Does not pay to guess.

Lots of questions about this tech, and I think you have just asked a goood on. What happens to secrecy when the secret data gets written to a disk file or partition?

https://www.spinics.net/lists/linux-kselftest/msg22189.html

Pages in the secretmem regions are unevictable and unmovable to avoid accidental exposure of the sensitive data via swap or during page migration.

That right you suspend/hibenation to disc the secretmem data going by by is the default setup. When you think secretmen holding items like TLS openssl one time keys when wake computer up from suspend/hibernation those values in majority of cases be expired anyhow so better to be gone.

Please note a privileged process can still ptrace into application using secretmem and see all the secretmem contents so this does not really hide malware as most malware scanners on Linux run in userspace.

Secretmem is more making sure items that should not be written to disc are not written to disc. It also making sure that kernel minor error don't expose some of this information. Yes it is possible with this secretmem stuff to grant the kernel access to the secretmem to perform particular tasks.

Mind you by default secretmem will be off. If you have not noticed the unmovable is a issue because this block you means to use huge pages. Yes the question how to-do secret memory storage and be move-able is a problem no one has a solution to. Yes the historic fix to unmovable memory being in way of creating a huge page under Linux was shove unmovable memory to swap then put them back in a different location cannot be done with secret memory. Even that the feature is in the new version of Linux coming out don't expect it enabled by default any time soon. There are still finer details to sort out.

[coder]

Does not pay to guess.

Right. If/when I had any reason to know, I would seek a definite answer. I was only speculating because it's currently just a fleeting curiosity to me.

That right you suspend/hibenation to disc the secretmem data going bye-bye (SP) is the default setup. When you think secretmen holding items like TLS openssl one time keys when wake computer up from suspend/hibernation those values in majority of cases be expired anyhow so better to be gone.

Hmmm... I hope there's a better solution to that. Maybe something like a signal, to tell the process that it's about to lose its secret mem contents. After resuming, perhaps invalidate those pages so it gets a segfault if it actually tries to use them.

Anyway, thanks for the info.