flat assembler
Message board for the users of flat assembler.

Index > OS Construction > Modularity?

Author
Thread Post new topic Reply to topic
Tyler



Joined: 19 Nov 2009
Posts: 1216
Location: NC, USA
Tyler
I've been thinking about some methods of modularity that would allow for pieces of kernel to be loaded(I literally mean kernel, not driver, for example, an isr module could be loaded) and used seamlessly by the kernel. Has this been done? If so, how?

In my theoretical implementation, I have standard places for pointers to standardized functions(args and effects must be the same, implementation can vary). Those places can be patched(by ring 0 only), seamlessly switching from one function to another.

If some of my fellow forumers have ideas/theories on this topic, please share.
Post 07 Jun 2010, 23:27
View user's profile Send private message Reply with quote
edfed



Joined: 20 Feb 2006
Posts: 4237
Location: 2018
edfed
two functoins needed for that
1/ load file in ram and return a far pointer + size
2/ launch that code from kernel main loop
Post 08 Jun 2010, 00:11
View user's profile Send private message Visit poster's website Reply with quote
cod3b453



Joined: 25 Aug 2004
Posts: 619
cod3b453
I'm not sure if this is what you mean but I have all ISRs pointing to one master handler, which by default captures all exceptions but delegates other vectors to a lookup table of handlers if they have a non-null entry; these pointers are set up by externally loaded modules. I plan to do the same with syscalls.
Post 08 Jun 2010, 18:33
View user's profile Send private message Reply with quote
Tyler



Joined: 19 Nov 2009
Posts: 1216
Location: NC, USA
Tyler
edfed wrote:

two functoins needed for that
1/ load file in ram and return a far pointer + size
2/ launch that code from kernel main loop

I mean the types of things that are at the very core of a kernel, like hardware access and memory management. Things that are called by that main loop. For things that have residual data between runnings of the code, for example, the memory allocator always has data on the allocated memory, there would be a protocol for the old function to "tell" the new function what memory was allocated.
cod3b453 wrote:

I'm not sure if this is what you mean but I have all ISRs pointing to one master handler, which by default captures all exceptions but delegates other vectors to a lookup table of handlers if they have a non-null entry; these pointers are set up by externally loaded modules. I plan to do the same with syscalls.

This is different, but you've caught my interest. How do you know what int # triggered your master isr? My idea is different because the loaded piece can replace a function used by the kernel itself.

The pieces would be in a special object format(using an ld script) that would list the function names to be replaced, and the names of functions that would be invalid after patching(to prevent loading of mem allocator and not of mem freeer, etc.).
Post 08 Jun 2010, 22:47
View user's profile Send private message Reply with quote
cod3b453



Joined: 25 Aug 2004
Posts: 619
cod3b453
I create stub entries that align the stack by pushing dummy error values and then the isr number before jumping to the master handler:
Code:
rept 256 i
 {
    idt_#i#:

        cli

 if (i-1) = 8 | (i-1) = 10 | (i-1) = 11 | (i-1) = 12 | (i-1) = 13 | (i-1) = 14 | (i-1) = 17
        ; No dummy error code
 else
        push 0 ; Dummy error code
 end if

        push (i-1) ; Push the ISR number

        jmp core_isr_handler

        align_int3 16
 }
    
Since these are all 16 byte aligned, I can build the IDT with a simple loop at run time to save space. The master handler also knows that the parameters are always isr#,err# and can then tidy up with add ?sp,8/16 then iret.
Post 09 Jun 2010, 08:18
View user's profile Send private message Reply with quote
baldr



Joined: 19 Mar 2008
Posts: 1651
baldr
cod3b453,

With call core_isr_handler (instead of jmp) and simple math you don't need push (i-1).

The whole point of single handler still eludes me. Particular exception/interrupt handler already knows about error code presence, and unhandled exceptions/interrupts can be uniformly dismissed by #NP handler.
Post 09 Jun 2010, 12:49
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17271
Location: In your JS exploiting you and your system
revolution
Tyler wrote:
I've been thinking about some methods of modularity that would allow for pieces of kernel to be loaded(I literally mean kernel, not driver, for example, an isr module could be loaded) and used seamlessly by the kernel. Has this been done? If so, how?
Perhaps not precisely on topic here but I do this in my ARM code. When a particular driver wants to use an interrupt it simply registers itself with the handler. Later when the interrupt is triggered the handler passes control to to requester. However that is using a driver which you mentioned that you don't want that, so I am a bit confused as to what you mean when you say replacing the kernel ISR? Generally the kernel is the most basic level of things and wouldn't handle any interrupts by itself. And replacing the entire ISR routine would suggest that you are perhaps upgrading to a new version? Or what?

Of course with the ARM all external interrupts come in through one point so we have to distribute from there, whereas in the x86 the interrupts can come into separate locations and be handled directly. The approach taken by cod3b453 can be useful if you want to isolate drivers from the kernel (perhaps by using ring 1/ring 3 drivers?) and this gives the kernel a chance to do any special set-up/exit that might be required around the driver code. It all depends upon how you want to structure your OS.
Post 09 Jun 2010, 13:06
View user's profile Send private message Visit poster's website Reply with quote
cod3b453



Joined: 25 Aug 2004
Posts: 619
cod3b453
revolution: I think Tyler means physically overwriting kernel subroutine code with an alternative, using a common data representation to glue it all together; this keeps the function pointers static but the code is dynamic.

Tyler: This (above^) should work as long as nothing is executing that function; it's not very different from 'hotfix' code patching which is fairly common.

----

baldr: That's not a bad trick, I might just 'borrow' it Cool I chose the single handler for easier code maintenance, there's no other real benefit.
Post 09 Jun 2010, 19:17
View user's profile Send private message Reply with quote
Tyler



Joined: 19 Nov 2009
Posts: 1216
Location: NC, USA
Tyler
revo1ution wrote:

Perhaps not precisely on topic here but I do this in my ARM code. When a particular driver wants to use an interrupt it simply registers itself with the handler. Later when the interrupt is triggered the handler passes control to to requester. However that is using a driver which you mentioned that you don't want that, so I am a bit confused as to what you mean when you say replacing the kernel ISR? Generally the kernel is the most basic level of things and wouldn't handle any interrupts by itself. And replacing the entire ISR routine would suggest that you are perhaps upgrading to a new version? Or what?

It's similar in how a function is dynamically registered to handle a specific task, but it's the limitation that your kernel is still there as an extra layer of abstraction. In my model, the registered function would not be registered in the sense that the kernel gets the interrupt, then calls all functions registered, the function registered would simply become the handler. But not only in the way of handling interrupts, but in commonly used functions even within the kernel. For example, I'll use the physical page allocator(does arm have paging?), instead of:
Code:
call alloc_page
;... more code
alloc_page:
;... code that will return free page
    

mine would use:
Code:
call [alloc_page]
;... more code
; BEGIN writable mem
dd alloc_page ; pointer to code that will return free page
    

The difference is that the kernel memory management model could be adapted for the needs of the currently running system. If you're willing to sacrifice small data structures for fast alloc/free because speed is more important, use the fast allocator, if size is more important, use a size conscious allocator.

The same concepts would be used on every function, the file open/close/read/write, console io, everything. It would allow for dynamic adaptation of the kernel to it's environment. There would be a protocol for each type of function, like for file handling patches, the current would produce a universally understood map of all open files upon being given a kill signal, the new one would then have an init function that would parse that map, format it as it likes for it's own use, and reproduce a map upon being killed. cod3b453 says it pretty well.

It's still all theory, but if done right, this could make for a really cool kernel.
Post 09 Jun 2010, 22:16
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17271
Location: In your JS exploiting you and your system
revolution
Tyler wrote:
(does arm have paging?)
Yes, of course.
Tyler wrote:
Code:
call [alloc_page]
;... more code
; BEGIN writable mem
dd alloc_page ; pointer to code that will return free page
    
That is not an ISR, that is a hook. Kernel hooks are nothing new and are already used in many OSes.
Post 10 Jun 2010, 00:31
View user's profile Send private message Visit poster's website Reply with quote
Tyler



Joined: 19 Nov 2009
Posts: 1216
Location: NC, USA
Tyler
revolution wrote:

That is not an ISR, that is a hook. Kernel hooks are nothing new and are already used in many OSes.

Thanks, that answers my question. Does Linux use kernel hooks? ISRs were an earlier example of what could be loaded, that wasn't intended to look like/be an ISR.
I wrote:

For example, I'll use the physical page allocator[...]
Post 10 Jun 2010, 02:58
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 17271
Location: In your JS exploiting you and your system
revolution
Tyler wrote:
Does Linux use kernel hooks?
Maybe you can ask in the Linux sub-forum, since no one here seems to know.
Post 14 Jun 2010, 03:46
View user's profile Send private message Visit poster's website Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  


< Last Thread | Next Thread >
Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Copyright © 1999-2020, Tomasz Grysztar.

Powered by rwasa.