Discussions on more advanced topics such as monolithic vs micro-kernels, transactional memory models, and paging vs segmentation should go here. Use this forum to expand and improve the wiki!
obfusc8or wrote:The downside with a SASOS could be lack of memory protection, unless you use a memory-safe programming language for application software.
Except that there's no way to enforce that a malicious developer uses a memory-safe programming language.
When you start writing an OS you do the minimum possible to get the x86 processor in a usable state, then you try to get as far away from it as possible.
Rusky wrote:Sure there is. It's a trade-off in flexibility, but it's easily possible.
Running everything in an interpreted bytecode (e.g. Java)?
When you start writing an OS you do the minimum possible to get the x86 processor in a usable state, then you try to get as far away from it as possible.
onlyonemac wrote:Running everything in an interpreted bytecode (e.g. Java)?
Running everything under wise management. Bytecode and stuff are just some small bits of the picture.
My previous account (embryo) was accidentally deleted, so I have no chance but to use something new. But may be it was a good lesson about software reliability
onlyonemac wrote:Running everything in an interpreted bytecode (e.g. Java)?
Running everything under wise management. Bytecode and stuff are just some small bits of the picture.
Like running heuristic binary code analysis before loading a binary to determine if it is memory-safe?
When you start writing an OS you do the minimum possible to get the x86 processor in a usable state, then you try to get as far away from it as possible.
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.
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.
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.
When you start writing an OS you do the minimum possible to get the x86 processor in a usable state, then you try to get as far away from it as possible.
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.
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.
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.
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.
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.
Except that, again, you can't ban what constructs the attacker's compiler generates.
When you start writing an OS you do the minimum possible to get the x86 processor in a usable state, then you try to get as far away from it as possible.
onlyonemac wrote:you can't ban what constructs the attacker's compiler generates.
It can generate whatever it wants, but OS's verifier will refuse to accept the bull $hit.
My previous account (embryo) was accidentally deleted, so I have no chance but to use something new. But may be it was a good lesson about software reliability
onlyonemac wrote:Except that, again, 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:you can't ban what constructs the attacker's compiler generates.
It can generate whatever it wants, but OS's verifier will refuse to accept the bull $hit.
So in other words, running heuristic binary code analysis as I suggested a few posts ago.
When you start writing an OS you do the minimum possible to get the x86 processor in a usable state, then you try to get as far away from it as possible.
onlyonemac wrote:So in other words, running heuristic binary code analysis as I suggested a few posts ago.
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.
My previous account (embryo) was accidentally deleted, so I have no chance but to use something new. But may be it was a good lesson about software reliability
