The Place to Start for Operating System Developers
https://f.osdev.org/
Except that there's no way to enforce that a malicious developer uses a memory-safe programming language.obfusc8or wrote:The downside with a SASOS could be lack of memory protection, unless you use a memory-safe programming language for application software.
Running everything in an interpreted bytecode (e.g. Java)?Rusky wrote:Sure there is. It's a trade-off in flexibility, but it's easily possible.
Running everything under wise management. Bytecode and stuff are just some small bits of the picture.onlyonemac wrote:Running everything in an interpreted bytecode (e.g. Java)?
Like running heuristic binary code analysis before loading a binary to determine if it is memory-safe?embryo2 wrote:Running everything under wise management. Bytecode and stuff are just some small bits of the picture.onlyonemac wrote:Running everything in an interpreted bytecode (e.g. Java)?
So is your proposed "memory-safe programming language" compiled or interpreted? Because if it's compiled, the OS is going to have a hard time "verifying" that it is memory-safe.Rusky wrote:The point is, the OS has complete control over which code runs, so if the only format it accepts is something it can verify, it can enforce that everything is written in a memory safe way.
Unless all code is compiled and signed by a trusted party (you), and OS checks code signature before running it.onlyonemac wrote:So is your proposed "memory-safe programming language" compiled or interpreted? Because if it's compiled, the OS is going to have a hard time "verifying" that it is memory-safe.Rusky wrote:The point is, the OS has complete control over which code runs, so if the only format it accepts is something it can verify, it can enforce that everything is written in a memory safe way.
Nope, compiled-vs-interpreted has absolutely nothing to do with it. Compilers and interpreters both control 100% of the code they generate, so if you want to ban certain constructs or enforce run-time checks, they're both equally capable of doing so.onlyonemac wrote:So is your proposed "memory-safe programming language" compiled or interpreted? Because if it's compiled, the OS is going to have a hard time "verifying" that it is memory-safe.
Except that, again, you can't ban what constructs the attacker's compiler generates.Rusky wrote:Nope, compiled-vs-interpreted has absolutely nothing to do with it. Compilers and interpreters both control 100% of the code they generate, so if you want to ban certain constructs or enforce run-time checks, they're both equally capable of doing so.onlyonemac wrote:So is your proposed "memory-safe programming language" compiled or interpreted? Because if it's compiled, the OS is going to have a hard time "verifying" that it is memory-safe.
It can generate whatever it wants, but OS's verifier will refuse to accept the bull $hit.onlyonemac wrote:you can't ban what constructs the attacker's compiler generates.
So don't use the attacker's compiler. Distribute apps in some pre-machine-code form (e.g. source, AST, CFG, bytecode) and run the compiler locally, like alexander suggests. This has the added benefit that you can optimize for the local CPU, re-optimize apps on compiler updates, etc.onlyonemac wrote:Except that, again, you can't ban what constructs the attacker's compiler generates.
So in other words, running heuristic binary code analysis as I suggested a few posts ago.embryo2 wrote:It can generate whatever it wants, but OS's verifier will refuse to accept the bull $hit.onlyonemac wrote:you can't ban what constructs the attacker's compiler generates.
Depends on the OS. If OS accepts binary code then it can use protection or it can employ the analysis. If OS doesn't accept binary then there are more options.onlyonemac wrote:So in other words, running heuristic binary code analysis as I suggested a few posts ago.