I belive it is first a conflict of policy: the USER needs to have more privileges than SYSTEM in order to suspend execution of all (including system's) processes. WinNT is a multi-user OS. Nobody would allow the user to DDoS the system, even when that user has direct access to the reset button.
A second problem is that WinNT probably can't even open the Task Manager if some system processes are suspended (csrss?, lsass?).
It probably works in Linux console. Sysvinit has two keyboard signals (CTRL-ALT-DEL and CTRL-UP, I think), that can run any command, exec'd directly by init with root privileges, and both are configurable in inittab. It also has the SysRq.
I miss the magic SysRq key... Xorg / graphical systems blocked it decades ago, I've forgotten how to invoke it without looking it up, though I do remember REISUB.
The security perspective of the SysRq commands is: a human is on a hard-wired console. If they want they can pull the power or press buttons on the outside of the PC that aren't on the keyboard. It's probably OK to obey some small list of actions that are useful when the rest of the system might be unresponsive.
Yep that's my line of thinking, if you have physical access it's game over for security anyway (evil maid etc). Whether the kernel recognizes SysRq or CAD or whatever else is a matter of a patch, X11 or Wayland can't intercept (that's the entire point of having a very very low level kernel routine for that).
The funky part would be the user space integration, the kernel would probably have to selectively resume a couple key processes or take over the display with its own/embedded one. Sounds like too brittle and/or extra bloat.
I never thought I'd consider Windows 95 technically superior in some area, but holy hell that system ran in 4mb of memory and did one (even if only one) thing right.
Reboot gives you disk access. Access to the running system additionally gives you memory access. There may be something in memory you want to keep safe, like encryption keys and other credentials. Evil maid means you had to kill everything that was running, which may in itself signal that something is off.
Stealing my iPhone and replacing it with another is not the same as having access to my data on it.
It ran like shit in 4MB—I remember telling the IT boss that we’ll need 8MB on every W95 machine, unless we want to wait 5 seconds to open a menu or run only one app at a time. Still 8 is impressive for the functionality.
Yeah my own Win95 machine had 32MB and ran super happy. The 4MB machine was frankensteined from very random parts for a friend who fried the PSU on their 8MB - the difference between all 3 setups was crazy, I think at 4MB you had to use a 16-color palette? At 640x480x8bpp video memory alone should eat 300KB (I don't think there was double-buffering?)
I sometimes wonder, what would be the "smallest" machine you could feasibly DIY/build today, that would still allow you to be somewhat productive (e.g. write code, very basic web browsing, SSH, etc). I recently spent a week with a PowerBook G4 (2002) and it's very usable (save for the fan noise). There's probably a lot to explore with modern MCUs.
Video memory is on the graphics card. Screen image is (was) built directly in the framebuffer. Double buffering wasn't a thing in those days. Memory was too expensive. I had a Trident 9440 PCI. It barely had BitBlt acceleration.
I belive it is first a conflict of policy: the USER needs to have more privileges than SYSTEM in order to suspend execution of all (including system's) processes. WinNT is a multi-user OS. Nobody would allow the user to DDoS the system, even when that user has direct access to the reset button.
A second problem is that WinNT probably can't even open the Task Manager if some system processes are suspended (csrss?, lsass?).
It probably works in Linux console. Sysvinit has two keyboard signals (CTRL-ALT-DEL and CTRL-UP, I think), that can run any command, exec'd directly by init with root privileges, and both are configurable in inittab. It also has the SysRq.
https://en.wikipedia.org/wiki/Magic_SysRq_key