Linux Kernel Seeing Work To Implement MEMFD "Secret Memory Areas"

[phoronix]

Phoronix: Linux Kernel Seeing Work To Implement MEMFD "Secret Memory Areas"

There is experimental work pending that plumbs support into MEMFD for creating "secret" memory areas. This secret memory support would then be exposed to user-space for different use-cases...

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

[shmerl]

Hm, I just hope this won't be misused for some kind of anti-user purposes like DRM.

[Ironmask]

doubt this will be used by DRM, but I also doubt any noteworthy software will use it, after they're given a very generous, anonymous donation to explicitly neglect it.

[uid313]

Seems like a great place to hide malware.

[Raka555]

How immune will these be against spectre type vulnerabilities ...
Now the attackers will know where to focus.

[Britoid]

Seems like a great place to hide malware.

You'd have to somehow get malware onto your system in the first place.

[cybertraveler]

As long as you have the ability to compile your own Linux kernel, this new feature would not be effective for creating DRM, as you could just make a version of your kernel that allowed you to freely inspect "encrypted" memory of one process using another process. This feature, by itself, is not harmful to users. I'd certainly appreciate its presence in my kernels as it would allow my programs to conveniently create safer areas to store my cryptographic secrets.

It's the CPU & mainboard level, treacherous-processors & accompanying firmware that are the big threat to user control & freedom. Intel call their treacherous system the "Management Engine" and AMD call their treacherous system the "Platform Security Processor". They are both marketed as being "security" & "convenience" features. This would definitely be the first time in human history that something evil, treacherous & spying is marketed as being a good thing as it provides "security and convenience" /s

Even if there are no deliberate backdoors in these treacherous systems, there may as well be, as they create a subsystem within your computer which is outside of your ability to practically inspect its function and security. It's extremely rare for people to create systems without security flaws and thus the ability of the user to inspect, modify and control their software / hardware is essential to security.

I buy Intel & AMD processors purely for their compatibility and low price. I would not pay either company a dime or cent for their processors if another company came along with a widely compatible (AMD64), competitively priced CPU which did not have these treacherous systems embedded within it. POWER appears to be the closest to achieving this, but they are still more expensive last I checked and there are no good laptops I am aware of that make use of that chip.

[stormcrow]

You'd have to somehow get malware onto your system in the first place.

That's the easy part.

I really don't see how "secret areas" in RAM is useful though. Perhaps for encryption keys? Technically, every area is supposed to be secret from people not authorized to view it. And even that being the case, there's side channel software and hardware attacks that would render this useless. What's this supposed to protect against, what additional complexity using a language known to produce further security problems just by being used would nullify whatever this would nominally protect against?

I know the Linux development process isn't monolithic, but there's quite a bit of work fixing what's already in there that is in itself broken and ineffective that needs people to repair. Linux's ASLR is practically useless, for example, thanks to side channel attacks already in the kernel that allows derandomization and extrication via /proc tables. The more I read about Linux kernel "security" the more I'm reminded about Windows NT security back around 2001 or so where the NT security team had good ideas, but other teams so badly circumvented it or the implementations themselves were so poor, you ended up with *websites* able to completely take over computers via ActiveX controls via no interventions from the user. Left hand doesn't know what the Right hand is doing.

(Reference on the KASLR problem in Linux: https://blog.blazeinfosec.com/the-ne...oles-in-linux/ )

[Neraxa]

That's the easy part.

I really don't see how "secret areas" in RAM is useful though. Perhaps for encryption keys? Technically, every area is supposed to be secret from people not authorized to view it. And even that being the case, there's side channel software and hardware attacks that would render this useless. What's this supposed to protect against, what additional complexity using a language known to produce further security problems just by being used would nullify whatever this would nominally protect against?

I know the Linux development process isn't monolithic, but there's quite a bit of work fixing what's already in there that is in itself broken and ineffective that needs people to repair. Linux's ASLR is practically useless, for example, thanks to side channel attacks already in the kernel that allows derandomization and extrication via /proc tables. The more I read about Linux kernel "security" the more I'm reminded about Windows NT security back around 2001 or so where the NT security team had good ideas, but other teams so badly circumvented it or the implementations themselves were so poor, you ended up with *websites* able to completely take over computers via ActiveX controls via no interventions from the user. Left hand doesn't know what the Right hand is doing.

(Reference on the KASLR problem in Linux: https://blog.blazeinfosec.com/the-ne...oles-in-linux/ )

Everything you mentioned is why /proc itself is part of the solution to making Linux more secure, you just need to use a capable RBAC system to lock access to it. The flaw is not having a default policy that disallows access to other processes proc tables by default. The user could enable and allow access as needed by adding additional rules (via root user). There has to be some way for debugging programs to monitor another process. /proc allows existing filesystems permissions frameworks to be used to control what has access to it, this gives it an advantage over specialized system calls. Only a few programs would need to access /proc entries for other processes, mostly debugging programs. Therefore, you can use RBAC to give a few programs such as gdb, and only running under a special user for that purpose. So other programs could not access it, nor gdb unless it is running as that special user. Another way is to simply allow access to a processes /proc entries only for a processes child processes, this way if you launch a program with gdb programname, gdb can access the process it execs but cannot attach to other processes. This is something that would in the domain of AppArmor to provide. Linux's way of using /proc is better than FreeBSDs way of seperate system calls because you can easily use existing filesystem access controls to control access to /proc.

[starshipeleven]

You'd have to somehow get malware onto your system in the first place.

If the software running on your system is 100% trusted you live in a world of lies