@fishfry, may I ask for your opinion?

fishfry, may I ask for your opinion? — Shawn

I'm honored. I could not parse the following:

utilizing the ECC-RAM utilized nowadays in servers to be able to predetermine the state of a computer through directly interacting with the system OS itself. — Shawn

ECC Ram is just error-correcting memory. It wouldn't offer any functional difference from any other kind of RAM. So I didn't understand that part. How would it be able to "predetermine the state of a computer?" Are you talking about branch prediction? This is a 20 or 30 year old idea as far as I know.

What does it mean to directly interact with the OS? Of course the software directly interacts with the hardware, especially the privileged kernel. So I'm afraid I couldn't make sense of this line and kind of got stuck here.

Booting off RAM? Is this like a RAM disk?

I looked up TimeShift, it's a backup thingie, creates and restores snapshots.

https://wiki.debian.org/timeshift

I'm afraid I couldn't understand exactly what you're getting at. There's always Stackexchange or some of the Reddit groups for finding computer experts.

ECC Ram is just error-correcting memory. It wouldn't offer any functional difference from any other kind of RAM. So I didn't understand that part. — fishfry

In basic terms it would simply mean that the CPU could directly input values into the OS mounted on the RAM. But, that's irrelevant if you can workaround the issue by implementing direct control over the OS values (definitely not for a Windows OS) into the mounted OS on the RAM, where the OS would operate.

How would it be able to "predetermine the state of a computer?" Are you talking about branch prediction? This is a 20 or 30 year old idea as far as I know. — fishfry

No, not the latter. In basic terms it means to implement any changes in the OS , by directly imputing those values, for example through a application like TimeShift into the integer values of the RAM.

TimeShift saves the config file of a precious restore point of an OS in Debian Linux into a config bootable root tree folder of all applications and current settings into a root file, and then reimplements them when requested to. Now, with a booted OS on the RAM you can do that on the go, and potentially upload values to the OS from another computer to predetermine it's state.

What does it mean to directly interact with the OS? Of course the software directly interacts with the hardware. So I'm afraid I couldn't make sense of this line and kind of got stuck here. — fishfry

The CPU would simple directly input integer values into the OS by having mounted on the RAM and bypassing slow hard drives through an application like TimeShift.

Here's a link to TimeShift:
https://github.com/teejee2008/timeshift

The CPU would simple directly input integer values into the OS by having mounted on the RAM and bypassing slow hard drives through an application like TimeShift. — Shawn

I'm afraid I can't comment. But (for sake of discussion) how does the CPU input anything anywhere? It has to be instructed to do so by instructions stores in memory. And all instructions are in hardware at the time they're being executed. If the program (OS or application) is on disk, the page containing the currently executing instruction must be loaded into memory and into a CPU register for execution. So I am honestly not following your idea. But it could be me, my technical knowledge on operating systems and hardware is not current.

So, think about it like this. System Restore on Windows saves the configuration of the OS, and when something goes wrong you can restore your OS to a previous state.

But, the thing I'm trying to do is have this being a real time process by mounting the OS onto RAM and directly monitoring it (in Linux) by a program called TimeShift.

For example, when a hacker tries to alter the system, he would not be able to do so because the OS is predefined to always be restored to default settings when a change is detected by System Restore in Windows or TimeShift in Linux.

I've had this idea of making computing faster — Shawn

For example, when a hacker tries to alter the system — Shawn

These two are in direct conflict.

After all, any intrusion detection scheme must necessarily slow down a computer. It takes extra cpu cycles to detect intrusions. It's like the extra time it takes you to get in your front door because you need to use a key. Any security measure always takes extra time.

When a piece of code attempts to alter memory, how does your system know when it's legitimate or not? After all doesn't a computer operate by way of software constantly making changes to memory?

Or (perhaps?) you are saying that when a piece of code attempts to alter the OS code it's automatically restored to its default state. The problem is that you often have to alter the state of the OS in memory. That's why computers operate in either privileged mode or user mode. In user mode you're not allowed to change the OS, in priv mode you are. I don't see how a computer could function if you disallowed priv access.

As a simple use case, suppose you buy a new printer and connect it to your computer. You have to install a driver and register the computer with your OS. In Windows there's a clunky user procedure and in Mac it's automatic, but the same things are being done either way. In your scheme you would reject all attempts to add new hardware.

But, the thing I'm trying to do is have this being a real time process by mounting the OS onto RAM and directly monitoring it (in Linux) by a program called TimeShift.

For example, when a hacker tries to alter the system, he would be able to do so because the OS is predefined to always be restored to default settings when a change is detected by System Restore in Windows or TimeShift in Linux. — Shawn

I'm confused, the kernel is already "mounted" in RAM if you mean that it already has its code in some location in RAM. The kernel (and OS in general) needs to be in RAM so context switching to kernel space and subsequent kernel operations is as fast as possible. After all, the kernel is just another process which happens to have been given special privileges by the CPU during the boot sequence.

Are you proposing that the operating system monitors itself?

So are you proposing to speed up computers, or detect unauthorized intrusions? — fishfry

Well, as a direct outcome of having TimeShift running on the go, it would be a safer system by default. The root folder would restore itself once any alteration would be attempted on it by monitoring any attempted change to values on the kernel.

The part about speeding up the system would be in manner of speaking by running apps in refreshing in sync with the RAM and CPU. But, I don't have all the details on this hashed out...

I'm confused, the kernel is already "mounted" in RAM if you mean that it already has its code in some location in RAM. The kernel (and OS in general) needs to be in RAM so context switching to kernel space and subsequent kernel operations is as fast as possible. After all, the OS is just another process which happens to have been given special privileges by the CPU during the boot sequence. — darthbarracuda

I'm not going to muddy waters by talking about what I'm not good at explaining.

Are you proposing that the operating system monitors itself? — darthbarracuda

Yes, and that would be done by TimeShift. If you can set as default to have the base root folder with the kernel not altered by hacking attempts, especially rootkits, then if any attempt was made on root, then TimeShift would automatically restore the system when a hacking attempt on roots configs or filesystem folders.

What if a friendly actor needs to make a change to this root folder for legitimate reasons? What if this TimeShift program gets hacked in some way? It seems like a major security vulnerability for a program other than the kernel to have access to this sort of thing.

Couldn't you get a crypto hash of whatever files you're worried about and then set up a cronjob to periodically calculate the hash and compare it to the stored one? If the hashes don't match, time to restore a backup. That's an oversimplified idea that is already in use.

Well, as a direct outcome of having TimeShift running on the go, it would be a safer system by default. The root folder would restore itself once any alteration would be attempted on it by monitoring any attempted change to values on the kernel. — Shawn

How would necessary privileged mode (aka kernel mode or supervisor mode) operations be done? Such as adding a device, adding a new process to the process table, and so forth?

See Kernel.

The kernel is a computer program at the core of a computer's operating system and has complete control over everything in the system.[1] It is the "portion of the operating system code that is always resident in memory",[2] and facilitates interactions between hardware and software components. A full kernel controls all hardware resources (e.g. I/O, memory, Cryptography) via device drivers, arbitrates conflicts between processes concerning such resources, and optimizes the utilization of common resources e.g. CPU & cache usage, file systems, and network sockets. On most systems, the kernel is one of the first programs loaded on startup (after the bootloader). It handles the rest of startup as well as memory, peripherals, and input/output (I/O) requests from software, translating them into data-processing instructions for the central processing unit.

So the point is, how would the computer function if every time the OS needed to modify the kernel's data structures, you backed those changes out? How would you distinguish between legitimate and malicious alterations to the kernel?

What if a friendly actor needs to make a change to this root folder for legitimate reasons? — darthbarracuda

@Shawn, What he said.

What if a friendly actor needs to make a change to this root folder for legitimate reasons? — darthbarracuda

The idea is that this is for high fidelity operations to be utilized in such as servers or government computers.

What if this TimeShift program gets hacked in some way? It seems like a major security vulnerability for a program other than the kernel to have access to this sort of thing. — darthbarracuda

That could be an issue; but, the kernel would simply revert itself back to a default state after an intrusion attempt.

Couldn't you get a crypto hash of whatever files you're worried about and then set up a cronjob to periodically calculate the hash and compare it to the stored one? If the hashes don't match, time to restore a backup. That's an oversimplified idea that is already in use. — darthbarracuda

Could you point out where this is in use? Still once root is protected (in real time) by TimeShift then accessing root files couldn't result in anything since the system would restore too quickly... It would be more difficult once chron and other root files would back up on a cloud for example to retrieve work done.

So the point is, how would the computer function if every time the OS needed to modify the kernel's data structures, you backed those changes out?

Again, this is a antihacking toolkit for example on low desktop use, such as government computers or servers. And yes, you could backup the configs and folder structures after a process completes.

That could be an issue; but, the kernel would simply revert itself back to a default state after an intrusion attempt. — Shawn

How? If this TimeShift program gets hacked, it could have its revert abilities removed.

Could you point out where this is in use? — Shawn

Hashes are used all over cryptography and data integrity. I don't any specific examples on hand, but the simple implementation of what I said before can be done by anyone who is familiar with the shell.

How? — darthbarracuda

Because the way it's designed is recursive. Root can monitor itself through timeshift operating in the background. So, yeah, the system monitors itself for example by checking matching hashes or even a repository of completed hashes hypothetically...

If this TimeShift program gets hacked, it could have its revert abilities removed. — darthbarracuda

I don't think the way the OS for Debian would allow elevated privilege before the OS would restore default vales and the administrator informed of a hacking attempt on root.

I don't think the way the OS for Debian would allow elevated privilege before the OS would restore default vales and the administrator informed of a hacking attempt on root. — Shawn

You could have the kernel monitor whenever write operations are attempted on root, and report them then. Processes can't open files without going through the kernel, which checks the permissions of the user against the permissions of the file.

If software is somehow able to access and modify files without the kernel first checking its authorization, then you have a bigger security problem. That just shouldn't happen.

You could have the kernel monitor whenever write operations are attempted on root, and report them then. — darthbarracuda

That's, not really the goal with this approach. It's kinda set it up and leave the system alone. No hassle or issues with that.

Processes can't open files without going through the kernel, which checks the permissions of the user against the permissions of the file. — darthbarracuda

Yeah, I don't think I have anything to say about this. If timeshift just has one operation to execute with sudo privileges, then it's not an issue then, no?

I'm not following. Anyway, SO or Reddit would be a better place to discuss this.

Well if you want a perfectly unhackable root, this idea might suffice.

Well if you want a perfectly unhackable root, this idea might suffice. — Shawn

Do you know that in normal operations, the OS needs to constantly make changes to the kernel in privileged mode? How would you determine what's a legitimate change versus a malicious one? If you disallow all kernel changes the computer won't boot and won't run.

Yes, I know, and hence a configuration file for all allowable operations would be necessary, otherwise the issue you pointed out.

Meaning that as long as the same programs are running and are not tampered with in root, then all system files can be reset to default values once tampering is noticed by timeshift.

You want to create a system that is completely useless and crippled, because the second any changes are made it reverts back to some previous state? Is that what you're asking? Have you heard of read only?

Edit: btw modern computers are already Turing complete.

@Michael, may I ask for your opinion on this idea?

Thanks and sorry for the bother.

It wouldn't be useless as long as an normal processes wouldn't try and alter the root folder. You can obviously design a config that would not allow reversions as long as chron allows it to happen.

That doesn't even make sense. ’Normal processes' with the appropriate privilege level must and do have constant read/write access to root. What you are describing would completely fubar basic functionality of the OS.

’Normal processes' with the appropriate privilege level must and do have constant read/write access to root. — emancipate

Last time I used Debian, that wasn't true. I might be wrong. But, either way with a system that doesn't do any user input, such as a steady state system, then TimeShift would simply nullify any intrusion attempts and modifications to the kernel or root folder.

If some processes need to have access to root, then I don't see the issue with making exemptions for TimeShift not to alter the directory or file class they would need to operate in.

There is no such thing as a steady state system in computing. What exactly are you talking about? Non-volatile memory? Give an example of a 'steady state system'.

Yes Debian, and every other linux distro (all OS's period), must allow certain processes constant access to root to even be able to function correctly.

If some processes need to have access to root, then I don't see the issue with making exemptions for TimeShift not to alter the directory or file class they would need to operate in — Shawn

Alternatively, simply use a dedicated IDS rather than software designed for a completely different purpose (rollback functionality).

There is no such thing as a steady state system in computing. What exactly are you talking about? Non-volatile memory? Give an example of a 'steady state system'. — emancipate

Where user input is minimal. Such as high security databases, government computers, or computers for critical infrastructure...

Alternatively, simply use a dedicated IDS rather than software designed for a completely different purpose (rollback functionality). — emancipate

Well that would work in tandem. Again, you can make sure that root is unhackable with this potential application of TimeShift...

Seems the idea has very limited application but that's no bar for a patent application.

If a computer programmer of reasonable skill can setup what you're suggesting to do based on the above descriptions, then the idea has already been released into the public, which means it's no longer patentable.