The Place to Start for Operating System Developers
https://f.osdev.org/
You say SASOS reduces management costs but don't say why. I say you owe me a million dollars and I won't say why. Because you didn't provide an explanation I have no choice but to assume you were unable to provide a reason, and therefore must be wrong about SASOS management costs. Because I didn't provide an explanation you might want to assume I'm wrong about that million dollars.AlexHully wrote:SASOS is also able to reduce management cost.
I don't remember saying these things. If you think electricity consumption is a concern but performance isn't; then I can teach you how to build a computer from hydraulics that doesn't use or consume electricity at all (but will consume energy, and will be very slow).AlexHully wrote:You say that a system can consume electricity, and that it is not a concern. It is. No matter how fast it is done.
The problem isn't task switch speed (which is the same regardless of how many TLB misses occur after the task switch). The problem is switching from one process' working set to another process' working set; where all caches (including TLB) are full of data for the previous process and contain nothing useful for the new process. SASOS doesn't help in almost all cases (excluding artificial "ping ping" micro-benchmarks, and silly micro-kernels that use synchronous messaging and need multiple tasks switches that can't be avoided/postponed any time anything trivial needs to be done). What does help is doing task switches less often (intelligent scheduling algorithms and asynchronous communication).AlexHully wrote:And context switches are among those things (stack, permission management) that cost cpu cycles and add up. No matter how fast they are.
You'd be running existing software without "compiler guaranteed safety" which will make your SASOS plans seem better than they would be in practice. Also; I very much doubt that the kernel or the user-space software will be optimal for SASOS (e.g. where things like shared memory and IPC can be done in much more efficient ways) which will make your SASOS plans seem worse than they would be in practice.AlexHully wrote:I propose to post a benchmark sasos and the normal way in real conditions. If proven wrong, i would have wasted a few days. Otherwise.. Actually, the only thing I can do is timing during an hour in the exact same conditions and use performance monitor to make an overall -and possibly flacky- decision.
Let me guess. You're going to spend 2 days modifying Linux for SASOS, then 10 days implementing the compiler required to "guarantee" safety and competitive performance, and by the end of November you'll have the GUI, web browser, office apps, 3D games, etc all ported to and/or rewritten in your new language. Then you'll spend the first half of December doing beta testing; and the entire OS will be completed and entirely usable in time for the end of year holiday period?AlexHully wrote:But still. It will not take ten years to create. Single address space is just a few days of work (when you specialize your context).
For a normal OS, tagged TLB allows you to invalidate an entire virtual address space cheaply, without invalidating all virtual address spaces. This means that (when you know a process can't be running on another CPU) you can skip the multi-TLB shootdown and invalidate the process' virtual address space on the other CPU if/when the other CPU actually does switch to that process.AlexHully wrote:What is the difference between a tagged tlb after a context switch in a "normal" system and a sasos?
When there is a miss, you end up doing the exact same thing possibly at the exact same rate. Same thing for a hit.
But you don't change the stacks don't make permission checks.
For a normal (unmanaged) OS malicious code can be injected into trusted pieces (e.g. the kernel itself). This is why everyone is moving towards things like Secure Boot (so that hardware and/or firmware can guarantee that those trusted pieces have not been tampered with).embryo2 wrote:And what is the difference between managed and unmanaged OS in case of malicious code injected in some sensitive area? Are you trying to tell us that there's nothing absolutely secure? Yes, there's nothing. But it's senseless to discuss issues like "A-bomb can melt any armor". It's better to discuss why a particular thing is better. Are "unmanaged" OSes protected from code injection? No. So, why you are using such argument against "managed" OS? I miss your point here.Brendan wrote:If you can (e.g.) inject malicious code into the native executable that was created during installation...
I was only using this to explain the difference between "managed environment" and "unmanaged environment". The obvious solution to prevent this is cryptography (e.g. auto-create a digital signature or secure hash when the compiler generates the "safe" native code).Rusky wrote:Then I guess we're not talking about a managed environment or language. Call it something else if it makes you happy. The point is that you could enforce a particular verifiable program representation that is at least as fast (more, once you start doing optimizations like inlining between applications and the kernel) and just as secure as a hardware-protected system running unverified code.Brendan wrote:Haven't we been through this before? A "managed environment" is an environment where software is relied on to provide protection/isolation at run-time. A "managed language" is something designed for a managed environment (but that's entirely irrelevant because nothing prevents code written in a managed language from being executed in an unmanaged environment, and nothing prevents code written in an unmanaged language from being executed in an managed environment).
You can't do the latter without also doing the former; unless you insert run-time checks.Rusky wrote:There's an enormous difference between proving code and its translation is bug-free (impossible) and proving that it's memory-safe (quite possible and already done in many languages and implementations).
Code: Select all
int foo(int bar) {
return lookup_table[bar];
}For "myArray" you have to prove that i is correct, and to do that you have to prove that everything that directly influenced i is correct, and to do that you have to prove that everything that indirectly influenced i is correct.Rusky wrote:The only thing you have to prove about the compiler's output is that it doesn't access memory it doesn't own. That is a significantly smaller and more tractable problem than proving program correctness. You don't have to unconditionally insert runtime checks or do whole-program analysis or nerf the language to do that, though it helps if the source program includes some annotations for ownership or number ranges.
Right, you have to prove that the compiler's output corresponds to the input that it verified. But even this is not impossible, especially if you do the verification on a simplified bytecode rather than a whole human-centric programming language. A translation at that scale can be (and has been) mathematically proven correct.Brendan wrote:For "myArray" you have to prove that i is correct, and to do that you have to prove that everything that directly influenced i is correct, and to do that you have to prove that everything that indirectly influenced i is correct.
Not a problem if the install-time compiler enforces them.Brendan wrote:Note that annotations for ownership or number ranges are completely useless for security because a programmer who is intentionally writing malicious source code will not use them "safely".
Are you talking about existing compilers? Why limit the scope to it?Brendan wrote: You must assume that the compiler is unable to guarantee that the code it compiled is safe.
I guess you make too many assumptions and you are too pretentious here. Many people are smart enough to think as well as you do. I hate to talk about it (and never did anywhere else), but as your tone is despising: I have a "pretty" high IQ myself, even if not as experienced as you are because I fell in computer science quite late. But, I have a need and a plan for it.Brendan wrote:The difference between you and me is that I've spent time researching what is/isn't possible and I know that getting a rating of 100 on that scale is impossible, and you probably haven't even started thinking about how you're going to achieve it
No I'm not talking about existing compilers. I'm talking about overall code quality. The industry average varies (depending on things like how much effort is spent on unit testing, etc) but is around 10 to 50 errors per 1000 lines of code. In a normal application this isn't really good, but there's almost always "something" to shield the OS from bugs in a normal application. For things like kernels, and for your compiler, nothing shields the OS from these bugs.AlexHully wrote:Are you talking about existing compilers? Why limit the scope to it?Brendan wrote: You must assume that the compiler is unable to guarantee that the code it compiled is safe.
Wrong. It can inject safety checks (as you already know, but refuse to consider this option).Brendan wrote:That brings me to unsolvable problems. What does the compiler do if it can't possibly determine if a piece of code is safe or not?
The only thing it can do is "false negatives".
It is common problem for all software, would it be managed or not. So, let's forget about this common thing while talking about managed vs unmanaged.Brendan wrote:Your entire OS's security will depend on this compiler. Your entire OS's security will depend on something that's expected to have between 80000 and 400000 errors.
The same is true for both worlds - managed and unmanaged. Because unmanaged OS has to have privileged code and this code can be compromised. But to compromise the code with safety checks injected, most probably you need to inject your code right into the privileged part of the managed OS (in it's compiler). And while there's no difference between kernel compromising problem for managed and unmanaged we safely can assume this argument has nothing against managed OS in discussion about managed vs unmanaged.Ready4Dis wrote:The point was, that using a managed compiler doesn't really offer security to the operating system if every single process has access to every other processes (and kernels) memory. It just means someone can write a program in an unmanaged language and compromise you kernel, where if you separated things out into their own memory address spaces, they are more secure.
No, it's two different things... in the imaginary unmanaged OS, the kernel runs in kernel space, and the user app runs in user space. If I run a .exe file (or .com or elf, whatever) I assume it's out to get me and make sure that it can't access things that it shouldn't (like other processes memory).embryo2 wrote:The same is true for both worlds - managed and unmanaged. Because unmanaged OS has to have privileged code and this code can be compromised. But to compromise the code with safety checks injected, most probably you need to inject your code right into the privileged part of the managed OS (in it's compiler). And while there's no difference between kernel compromising problem for managed and unmanaged we safely can assume this argument has nothing against managed OS in discussion about managed vs unmanaged.Ready4Dis wrote:The point was, that using a managed compiler doesn't really offer security to the operating system if every single process has access to every other processes (and kernels) memory. It just means someone can write a program in an unmanaged language and compromise you kernel, where if you separated things out into their own memory address spaces, they are more secure.