OSDev.org

Posted: **Fri Feb 07, 2014 12:24 pm**

Hey guys, I have decided to begin writing programs for my OS. This isn't a super complicated problem but it is however due to some design decisions.
As some of you know I write my code in C# using my own compiler, now if every program lets say were to run in protected mode and not user mode, I could just use a map file in my compiler and direct all calls and memory access to the Kernel and OS from a program to that map file, however this is highly dangerous considering programs could do "cli" or pretty much anything they want. So user mode is the only real way to prevent some of this, however to use usermode you would have to implement system calls.

Ok lets look at an example of a program using a rectangle class from my OS:

"Rectangle rect = new Rectangle(100, 200);"

Now that program would need to be able to create a new instance of rectangle, and pass 100 and 200 to the function. In protected mode this is easy, the compiler would just output something like this:

"push 100"
"push 200"
"call [PearOs.Core.SGL.Rectangle.ctor_U32U32]"

But in user mode you do not have direct access to that, so you would have to create a system call for that right?
However is it possible to make system calls that use the stack? Because if you did "INT 80" the CPU would push the flags, cs, and eip onto the stack
which makes it hard to be able to access the parameters on the stack without having to stop multitasking until the call is done.

Is there ways around this? Or would it be best to just go the route BareMetalOs uses which is programs in raw protected mode? Do a lot of Os's do this?

Thanks, Matt

Posted: **Fri Feb 07, 2014 1:18 pm**

PearOs wrote: Is there ways around this? Or would it be best to just go the route BareMetalOs uses which is programs in raw protected mode?

If you can't answer that question yourself, then you're probably not designing, you're more than likely just making it up as you go along. Now that isn't a terrible thing for a hobbyist but things would be easier if you had a specification. With a spec. questions like this get answered easily as your design space is constrained. A spec. would get you get to your objective faster.

If you choose to not have a spec. then just do what you think would be most fun/most educational/most whatever. You're in charge, it's your OS. Don't get the analysis paralysis, just do something that works and tell yourself you'll improve it later.

Posted: **Fri Feb 07, 2014 1:24 pm**

bwat wrote:
PearOs wrote: Is there ways around this? Or would it be best to just go the route BareMetalOs uses which is programs in raw protected mode?
If you can't answer that question yourself, then you're probably not designing, you're more than likely just making it up as you go along. Now that isn't a terrible thing for a hobbyist but things would be easier if you had a specification. With a spec. questions like this get answered easily as your design space is constrained. A spec. would get you get to your objective faster.

If you choose to not have a spec. then just do what you think would be most fun/most educational/most whatever. You're in charge, it's your OS. Don't get the analysis paralysis, just do something that works and tell yourself you'll improve it later.

Ok thank you for your input bwat. I pretty much make things up as I go, which works well for me I just am concerned about security if I go the ring 0 route, which is why I am wondering how I would get around my problem so that I can use ring 3.

Edit: However, I did consider using ring 3 and making a monitor like you would for v8086 mode so that when you would do a "sti" or "cli" my Os would check the privilege level of the program and grant access to those instructions if needed, this way I could prevent some malicious programs, and still allow direct access to my OS and Kernel functions.

Thanks, Matt

Posted: **Fri Feb 07, 2014 1:29 pm**

You could always take the obvious route, that many operating systems do, and pass parameters to your system call in registers. If you're working in 64-bit mode this is the usual convention for passing parameters to any function (with some obvious exceptions).

Posted: **Fri Feb 07, 2014 1:52 pm**

iansjack wrote:You could always take the obvious route, that many operating systems do, and pass parameters to your system call in registers. If you're working in 64-bit mode this is the usual convention for passing parameters to any function (with some obvious exceptions).

Well see I would do that except I have some functions with more than six parameters and I would rather refrain from using registers. However one reason why is because I would like to not have to write code for every function, however worst case I could I guess.

However the monitor idea might work well. Anyone ever done this before?

- Matt

Posted: **Fri Feb 07, 2014 2:01 pm**

I do not recommend doing multitasking by operating directly on user mode trap frames. It probably only makes sense for a microkernel. In most operating systems, the concept of a thread applies to kernel mode as well, and there is a separate stack per thread. For system calls, a natural thing to do would be to have a table with the number of parameter bytes for each function, and copy the parameters to the kernel stack before calling the function.

You should avoid creating unnecessary system calls. For example, constructing a Rectangle sounds like a trivial operation that is best done in user mode (unless your idea of a rectangle is very different from mine). In my OS, there is actually a lot of code that is visible from user mode and may be called in either mode.

Posted: **Fri Feb 07, 2014 2:10 pm**

I'd say that six parameters seems a little excessive for a well designed system call. But there's nothing to stop you passing a pointer to a structure.

Posted: **Fri Feb 07, 2014 2:16 pm**

Why do you need a system call to create a ordinary "standard library" object like a rectangle?

Gigasoft wrote:...You should avoid creating unnecessary system calls. For example, constructing a Rectangle sounds like a trivial operation that is best done in user mode (unless your idea of a rectangle is very different from mine)...

I agree. Something like C standard library: it's fully accessible in user mode and internally use syscalls to perform system level operations.

Posted: **Fri Feb 07, 2014 2:36 pm**

brunexgeek wrote:Why do you need a system call to create a ordinary "standard library" object like a rectangle?

Gigasoft wrote:...You should avoid creating unnecessary system calls. For example, constructing a Rectangle sounds like a trivial operation that is best done in user mode (unless your idea of a rectangle is very different from mine)...
I agree. Something like C standard library: it's fully accessible in user mode and internally use syscalls to perform system level operations.

We'll my Kernel is in a way a C# library. When you create an object it allocates space so I could plug the allocate function but I may try the monitor route.

Posted: **Sat Feb 08, 2014 10:54 am**

PearOs wrote:However is it possible to make system calls that use the stack? Because if you did "INT 80" the CPU would push the flags, cs, and eip onto the stack

Upon stack switch from user mode into kernel using interrupt, the user-mode stack is stored on TSS. It's possible to access it but due to extra indirection most people prefer to pass arguments on register unless there are too many of them (which by the way sometime indicate a poorly designed API).

For syscall/sysenter, the user mode stack pointer is unchanged upon entering kernel.

PearOs wrote:which makes it hard to be able to access the parameters on the stack without having to stop multitasking until the call is done.

I do not see a direct relation with multi-tasking, perhaps you have misunderstood something?

Posted: **Sat Feb 08, 2014 3:32 pm**

PearOs wrote: We'll my Kernel is in a way a C# library. When you create an object it allocates space so I could plug the allocate function but I may try the monitor route.

Pear, are you trying to use a system call for object allocation? While it can work, there is a different way of organizing allocation that most people use. Typically, each process gets its own object allocator that runs in user space. I'll assume for the sake of simplicity that the object allocation manager is a simple heap for now, it doesn't change the outside details even if it is more complicated. This per process Heap manages a chunk of memory that it has allocated from the OS. As your process heap's needs grow and shrink, it interacts with the OS to change the amount of memory allocated to the process. This is done via a system call as needed in much bigger chunks of memory (probably at the page size).

In your example of new Rect(), I would see a pseudocode userspace alloc something like this.

Code: Select all

Pears.Runtime.Heap.Alloc(RuntimeType type)
{
     if(!EnoughSpaceInHeap(type.Size))
            PearOs.SysCall.AllocPage()
     
     object* ptr = AllocObject(type.Size);
     return ptr;
}

This is assuming that it is supposed to be a heap allocated object. Most implementations of a Rect that i've seen make it a value type and you should already have memory allocated for it in stack space. Actually, now that I'm re-reading what you wrote, I'd have quite a few questions about your implementation details of your compiler. Hopefully the above is somewhat helpful for the way you did things.

Edit: this concept is not unique to CLI based languages. Almost every language with the concept of object allocation implements a user space memory manager of some sort and interacts with the OS on a more abstract level.

Posted: **Sat Feb 08, 2014 3:38 pm**

If your OS is C#, and your applications are C# or some other managed language - I have to ask - why are you not employing the sandboxing capabilities of the CLI?

It seems silly to build a worst-of-all-worlds OS featuring a C# kernel (with attendant costs) and a mandatory CLI userspace (with attendant costs) and not extract the main benefit from it (no need for system calls, context switches, or other expensive privilege switches, because the bytecode is verified safe)

Posted: **Sat Feb 08, 2014 6:58 pm**

Owen wrote:If your OS is C#, and your applications are C# or some other managed language - I have to ask - why are you not employing the sandboxing capabilities of the CLI?

It seems silly to build a worst-of-all-worlds OS featuring a C# kernel (with attendant costs) and a mandatory CLI userspace (with attendant costs) and not extract the main benefit from it (no need for system calls, context switches, or other expensive privilege switches, because the bytecode is verified safe)

Well first off, the world of a C# kernel is actually very good. Its fast, simple and works how I want it to. Not only that with a few modifications to my compiler I can run .Net Programs

However, I did go the route to not use system calls and a few other things, but running a CIL virtual machine would be silly, I would rather go my route and compile the CIL to Assembly forming a binary.

- Matt

Posted: **Mon Feb 10, 2014 11:32 am**

Owen wrote:If your OS is C#, and your applications are C# or some other managed language - I have to ask - why are you not employing the sandboxing capabilities of the CLI?

It seems silly to build a worst-of-all-worlds OS featuring a C# kernel (with attendant costs) and a mandatory CLI userspace (with attendant costs) and not extract the main benefit from it (no need for system calls, context switches, or other expensive privilege switches, because the bytecode is verified safe)

Owen, you are brilliant. If I understood your suggestion correctly, any 100% verifiable assembly could be JIT'd with direct calls into known safe kernel functions and run in ring 0. A memory protected userspace would still need to exist for non-verifiable assemblies. Actually, with appropriate kernel features in place, it would be possible to build quite a few verifiable drivers that could run in ring 0 as well. I have been working on my own CLI kernel and compiler, but hadn't considered this possibility for JITed stuff, thank you!

On another note, I wonder why microsoft hasn't done this... it would give .NET a massive performance boost in windows for quite a few applications.

Posted: **Mon Feb 10, 2014 12:37 pm**

You know Prolog is fast too.

When i'm not comparing it to any other languages, or explaining just why i think it's fast.

OSDev.org

Syscalls benefits and issues?

Syscalls benefits and issues?

Re: Syscalls benefits and issues?

Re: Syscalls benefits and issues?

Re: Syscalls benefits and issues?

Re: Syscalls benefits and issues?

Re: Syscalls benefits and issues?

Re: Syscalls benefits and issues?

Re: Syscalls benefits and issues?

Re: Syscalls benefits and issues?

Re: Syscalls benefits and issues?

Re: Syscalls benefits and issues?

Re: Syscalls benefits and issues?

Re: Syscalls benefits and issues?

Re: Syscalls benefits and issues?

Re: Syscalls benefits and issues?