3 ms·

In the 60s, operating systems were designed in a world where the person running the program was the same as the person who wrote the program. Today many of the

In the 60s, operating systems were designed in a world where the person running the program was the same as the person who wrote the program. Today many of the security or privacy schemes start by making a distinction between the programmer and the user. Besides sharing or "abstracting" the pieces of hardware that the app wants to control -- as VMWare or a hypervisor might do -- the operating system has one additional important role, which is to function as an agent for the user. The apps, written by various persons, are running on a computer that belongs to the user. The operating system keeps control of the computer -- the user's computer -- in the user's hands, and keeps it from being "taken over" by the apps. This role or function of the operating system can certainly be subsumed by a programming language / environment like Smalltalk or Java, but the idea of an operating system has a purpose that directly reflects the different interests, goals, or priorities of distinct entities interacting inside the machine. Usually the master control program is seen as being against the users, but I'm casting it as a good guy. I think that the promise of the operating system is that it can be a good guy (for the user), even if real examples tend to fail at that job.

Dewie 12y ago
> The apps, written by various persons, are running on a computer that belongs to the user. The operating system keeps control of the computer -- the user's computer -- in the user's hands, and keeps it from being "taken over" by the apps. I wonder if this can be mitigated - at least in some cases - with more disciplined and limited tools/apps. To my knowledge, there are few programming languages that have purposefully restricted their expressiveness in order to increase how much can be proved about them. Given that "all" of them are as expressive as a programming language can be in the physical world (at least according to researchers' current knowledge), there are no non-trivial properties that can be proven about them, in the general case. In that sense, it inspires a wild-west approach - the OS can not know anything with certainty about an arbitrary app it has not run yet. So its only option - for an arbitrary program - is to try to run it and try to shield itself from whatever mischief it might do at runtime. Given this inherent and general uncertainty, creating heuristics for programming language/machine code analysis might not be high up on the priority list (if at all). But if expressiveness is limited, there are more properties that can be definitely decided before running the program. Maybe it is possible to prove that a program will never try to access memory outside of whatever is assigned to it? This might be too difficult (in practice) to prove for a low-level language. But there certainly are languages that won't let you access memory outside of its process - java, for example, will throw an exception when the index is out of bounds. For example, languages like java could provide a proof to the OS that it will never try to access memory that it does not own? Then maybe the OS could eliminate whatever checks for illegal access of memory, since it has a proof that that kind of thing will not happen.
- louthy 12y ago
  .NET has code access security, which is even finer grained than just memory access restrictions: http://msdn.microsoft.com/en-us/library/33tceax8(v=vs.110).aspx http://msdn.microsoft.com/en-us/library/33tceax8(v=vs.110).a... http://msdn.microsoft.com/en-GB/library/930b76w0(v=vs.90).aspx http://msdn.microsoft.com/en-GB/library/930b76w0(v=vs.90).as...

Dewie 12y ago

> The apps, written by various persons, are running on a computer that belongs to the user. The operating system keeps control of the computer -- the user's computer -- in the user's hands, and keeps it from being "taken over" by the apps. I wonder if this can be mitigated - at least in some cases - with more disciplined and limited tools/apps. To my knowledge, there are few programming languages that have purposefully restricted their expressiveness in order to increase how much can be proved about them. Given that "all" of them are as expressive as a programming language can be in the physical world (at least according to researchers' current knowledge), there are no non-trivial properties that can be proven about them, in the general case. In that sense, it inspires a wild-west approach - the OS can not know anything with certainty about an arbitrary app it has not run yet. So its only option - for an arbitrary program - is to try to run it and try to shield itself from whatever mischief it might do at runtime. Given this inherent and general uncertainty, creating heuristics for programming language/machine code analysis might not be high up on the priority list (if at all). But if expressiveness is limited, there are more properties that can be definitely decided before running the program. Maybe it is possible to prove that a program will never try to access memory outside of whatever is assigned to it? This might be too difficult (in practice) to prove for a low-level language. But there certainly are languages that won't let you access memory outside of its process - java, for example, will throw an exception when the index is out of bounds. For example, languages like java could provide a proof to the OS that it will never try to access memory that it does not own? Then maybe the OS could eliminate whatever checks for illegal access of memory, since it has a proof that that kind of thing will not happen.

louthy 12y ago
.NET has code access security, which is even finer grained than just memory access restrictions: http://msdn.microsoft.com/en-us/library/33tceax8(v=vs.110).aspx http://msdn.microsoft.com/en-us/library/33tceax8(v=vs.110).a... http://msdn.microsoft.com/en-GB/library/930b76w0(v=vs.90).aspx http://msdn.microsoft.com/en-GB/library/930b76w0(v=vs.90).as...