OSDev.org

I am frankly getting quite frustrated at everyone's continual refusal to spell out exactly what they mean. Clearly everyone has something in mind when they post, but instead of actually saying what they mean they think it's a funny game to drop little "hints" at what they're thinking of.

Could you tell us what you mean by that comment, citing the posts that you are referring to, rather than playing games and dropping little hints about people refusing to spell out what they mean.

onlyonemac wrote:I am frankly getting quite frustrated at everyone's continual refusal to spell out exactly what they mean.

Does everyone include you?

There can be simplified algorithms that are able to verify something. If it's about the x86 code then there are such tricky areas as pointer arithmetic and hardware interaction. If we consider a code without pointer arithmetic and hardware interaction then it is obvious that now we have to spend less efforts on checking it. What kind of code to accept is a design time decision, but as pointed above it can greatly influence the complexity of the security related checks. That's why there are OS projects with a specific kind of code usually called bytecode. Besides of the pointers and hardware the bytecode enforces the conversion step after an OS has given a code. Such step is convenient because it reminds the developer about the input verification and allows to optimize the conversion result for it to match the actually present hardware. But from the other side such approach requires more time to be spent on development.

embryo2 wrote:

onlyonemac wrote:I am frankly getting quite frustrated at everyone's continual refusal to spell out exactly what they mean.

Does everyone include you?

My original statement was that there is no way for an OS enforce the use of a memory-safe programming language. The first response I received was "sure there is", claiming that this is "easily possible" without naming a single way of doing this. I suggested bytecode (guessing at what the previous response was meaning), to which I was told "running everything under wise management" and "bytecode is just a small bit of the picture", again without actually telling me what wise management and what bigger picture the poster had in mind.

If this isn't "dropping hints" then I don't know what is.

The original poster went on to describe what they had in mind; all the confusion came from other posters bringing in their own, different, ideas.

Rusky wrote:The original poster went on to describe what they had in mind; all the confusion came from other posters bringing in their own, different, ideas.

You didn't describe what you meant by "verify", what formats you considered this to be possible with, and how you consider it to be possible with those formats.

I didn't figure it was necessary- there are plenty of systems that already solve the problem in various ways, and many more that solve parts of the problem. But so you don't think I'm being mysterious again, I'll elaborate.

To verify a program is memory safe you need to ensure that it never access memory it does not own. This is an extremely well-solved problem- most languages in use today accomplish it, and you even brought one up as an example. VM languages like Java or C#, scripting languages like Javascript or Python, statically verified languages like the safe subset of Rust, etc.

Then, in order for the OS to verify it, it needs to accept applications only in some form that still retains the necessary information for that analysis, of which I already listed several examples- source, AST, CFG, bytecode, etc.) This has also been done to death- browsers do it, Android does it, research OSes based on Java and C# do it, etc.

Like I said from the start, it's a tradeoff: you give up the flexibility of distributing apps in any format you like, and gain the ability for the OS to control exactly what code is allowed to run. You can run that code however you like- whether you interpret it or JIT-compile it or generate machine code on installation, the OS is still in control.

Rusky wrote:I didn't figure it was necessary- there are plenty of systems that already solve the problem in various ways, and many more that solve parts of the problem. But so you don't think I'm being mysterious again, I'll elaborate.

To verify a program is memory safe you need to ensure that it never access memory it does not own. This is an extremely well-solved problem- most languages in use today accomplish it, and you even brought one up as an example. VM languages like Java or C#, scripting languages like Javascript or Python, statically verified languages like the safe subset of Rust, etc.

Then, in order for the OS to verify it, it needs to accept applications only in some form that still retains the necessary information for that analysis, of which I already listed several examples- source, AST, CFG, bytecode, etc.) This has also been done to death- browsers do it, Android does it, research OSes based on Java and C# do it, etc.

Like I said from the start, it's a tradeoff: you give up the flexibility of distributing apps in any format you like, and gain the ability for the OS to control exactly what code is allowed to run. You can run that code however you like- whether you interpret it or JIT-compile it or generate machine code on installation, the OS is still in control.

Thanks, that makes a lot more sense.