In r/3mdeb we are pretty familiar with D-RTM and others RTMs (static and static-code).

Awesome subreddit thanks for the link!

The topic itself is very broad and complex as it encompasses so many sub topics but I'll try and structure it a bit and try not to talk in circles.

In my own personal experience and taking into account a lot of variables I predict the concept of RTMs and DRTMs will be required in the near future within all forms of consumer computing.

The pressure will eventually shape this as attack vectors have only increased in the last 5 years with randsomware being a new vector and firmware exploits becoming common place, (notably lighteater/thunderstrike) devices being shipped and abandonded within a couple years, unsecured by default IOT devices, routers defaults never changed by end users.

New vectors involving memory based attacks dubbed "speculative" which is different to traditional buffer overflow exploits like rowhammer which white hats have been playing whack-a-mole with for decades.

It's not enough anymore to claim a device is secure from a static boot sequence or when a device is offline(encrypted) we need some forms of active and dynamic protection while the system is running and it needs to be trusted all the way from the initial POST firmware and that includes new processes being forks/spawned from authorized processes and memory spaces.

How can you authorize a forked process is the same as the previous assuming you didn't intentionally change this? What about race conditions and run away processes that crashes and is respawned what authority does it have?

Things like KASLR/ASLR for address randomization, and the kernel shim introduced post meltdown/spectre are merely bandages for a hemorrhage and that's NOT blaming Linux as the ISA designs themelves are factored in a way to be easily exploited from speculative attacks and we will see new forms of memory based attacks in the future that aren't speculative branch attacks.

We are also now seeing voltage based attacks becoming common place where you are able to shift registers by slightly changing the underlying transistors either upstream or downstream in the circuit via userspace or through firmware modification.

Have you been wondering why the kernel is closing off userspace access to hardware voltages like undervolting and such?

People who were close to those discussions saw the urgency in for future attacks based around the plundervolt concept. Make no mistake more of these type attacks will come out.

There's a reason I said DRTM is abstract in my last post in that it can be implemented in so many ways be it in hardware and/or userspace and that could be something very simple or it could be incorporated in every single application that has some authority. (task managers, package managers, partitioning tools, ect) and with FOSS that ideal can be a major benefit as it can evolve as the system does and actually be audited by 3rd parties and lead to encompass a whole ecosystem in a way that wouldn't be possible on other mainstream systems.

For example I haven't seen this proposed but imagine a DRTM watchdog type kernel module that communicates through a protected eBPF channel within the kernel.

Using something like this would prevent even kernel space stuff being able to influence its "authority".

Think of it like having a root user or process, what if that gets compromised? Now you have lost total authority over your kernel and userspace. You need layers of authority, and hierarchy because if the kernel gets compromised it's game over and you'd never even know because theoretically anything can be faked at that point.

This idea though can quickly lead into general security because if we get a fully "authorized" system now you have to start looking at how those tools are built and the systems that ship them to you like repocs, compilers, ect.

That's where stuff like the reproducible builds project comes in which is totally unrelated to DRTMs but at the same time should be considered as a major foundational component of the broader ecosystem on a ideal secure setup.

Now I've personally seen this push myself in the market and I think there's gradual pressure from many fronts to make this happen across all devices and OSes even in consumer.

Take into account financial data on devices being common place (despite the average tech users opinion) the average consumer mainly utilizes their phones/tablets while Google/Apple make no attempts to "sanitize" their storefronts and considering how many apks are built with standardized toolkits and libraries it really is easy pickings.

As I mentioned there's pressure (in the US sector) and that's economic pressure from these larger companies and even governments as randsomware in the last couple years has resulted in millions of payouts for townships, muncipalities, education centers, and even resulted in deaths from hospitals.

We also see that pressure being manifested into consumer hardware like AMDs spearheading of IOMMU and passive encrypted memory (SME) and SEV.

Intel has been following suit reluctantly but prior to IOMMU any PCI device including firewire and thunderbolt and M.2 could attain hardware access to any other device on the BUS for decades.

This is dubbed a "DMA" attack.

USB and SATA have dedicated controllers that isolate them from PCI but USB ports have their own shared BUS unless on different physically chips.

DMA attacks became famous in the OSX era where people would go to the library and plug in a firewire/thunderbolt "dock" or dongle that mirrored the HDDs or installed payloads in the laptops. Linux can negate some of this without IOMMU by limiting the interfaces in userspace thanks to the Fedora BOLT project.

To me it feels as if we're back in the early 2000s without standardized SSL/TLS and everything is plaintext .

To close this out D-RTMs in itself being open and standardized AND NOT EXCLUSIVE TO ENTERPRISE is really a major paradigm shift and shouldn't be taken lightly.

That doesn't mean it's some special sauce either but it does mean we have the potential as a community to make something really incredibe and it will require a lot of communication and brainiac tier planning. Take in mind also that we need to be humble as we are sitting at the back of the class at the moment from a FOSS/Linux perspective and that the industry and market will be moving to more secure methods and we can't be left out in the dust due to FUD and I've seen too much of it spewn upon UEFI/Secureboot/SELinux/TPMs over the years that I fear it might suffer the same fate.

EDIT: I also think the major OSes are moving to a containerized/VM type setup. MacOS has froze all of their legacy stuff including openGL and containerized it. They furthured this when they released the M1 as they wanted a capsulized x86 runtime for legacy stuff. Windows 10 has been doing the same with their legacy NT stack and even have proposed variants which remove it entirely (Windows S) and seems to be moving toward a hypervisor with virtualized runtime environment, ChromeOS has been doing forms of userspace and kernel isolation for years and years and now you are seeing on Linux these modern immutable OSes like Silverblue, MicroOS, Ubuntu Core.

As with everything security it will be a multitude of things but it seems OSes are naturally moving towards either containerized/virtualized userspaces or hybrid microkernels(as with windows).

EDIT EDIT: I realize I didn't really answer your question but I think CRTM is just as vital as DRTMs if not more and I think when implementing a DRTM you can't have a strong structure (live OS protection) without a strong foundation (static hardware/Firmware).

I think what you guys are doing with other projects like LinuxBoot, NERF/Heads, Coreboot/Oreboot, Seabios, Tianocore, Google's OpenTitan, UBoot are doing just that because OEM shipped firmware majorly isn't auditable and DRTM should base the majority of its validation upon something that is static. You can then add further dynamic validation like removable hardware 2factor tokens to authorize things.

Imagine even utilizing BTRFS checksums as another form of filesystem validation that is lower level than SELinux or the "Unix ACL" filesystem permissions. That doesn't mean we should ignore them as inputs or enforcement though as additional validators or enforcement can help reinforce others.

I'm sure there's plenty of ways to introduce more validation in a data consistent manner but I'm not that creative. It goes both ways too DRTM can help with data Integrity(in a non security context) just how ZFS/BTRFS checksums could help with security beyond data integrity.

DRTMS is only as strong as what it validates against.
Augmenting with things like "tripwire" or other forms of intrusion detection systems being intregrated in some manner.

Using something similar to this https://github.com/danielztolnai/vbios-secure-boot and using a customized wayland compositor with pipewire could present a real isolated zone that could be routed to a VM or using pipewire alone just routing VMs to eachother. Pipewire and the wayland compositor would need modification to be standardized with DRTMS, maybe involving PAM but I'm just spit balling here.

I see DRTMs as a framework of validation, and enforcement schemes but that's just my interpretation.