OSDev.org

The Place to Start for Operating System Developers
It is currently Thu Mar 28, 2024 6:52 am

All times are UTC - 6 hours




Post new topic Reply to topic  [ 51 posts ]  Go to page Previous  1, 2, 3, 4
Author Message
 Post subject: Re: Monolithic vs. Microkernel hardware boot drivers
PostPosted: Mon Jul 11, 2016 4:09 am 
Offline
Member
Member

Joined: Sat Mar 01, 2014 2:59 pm
Posts: 1146
gerryg400 wrote:
Rusky wrote:
gerryg400 wrote:
When the blob says "I'm a keyboard driver, give me access to the IO ports related to the keyboard" how do you know to trust the blob?
That's missing the point. You have to trust some code to be your keyboard driver, no matter what kernel architecture you use. The benefit of a microkernel is that you don't have to trust the blob with anything else.
Rusky, just to be clear, my only concern in this thread is that the OP has chosen to use a kernel API to read and write IO ports. I'm just saying that it achieves nothing. My example about the blob is just to point out that using a kernel API to do port IO does not protect against a malicious blob any better than any other method (and has all the disadvantages that have been mentioned).
Except that if you use a kernel API for port I/O you're presumably validating each request in the kernel and disallowing direct port I/O through privilege levels, therefore your malicious blob can't do much damage.

_________________
When you start writing an OS you do the minimum possible to get the x86 processor in a usable state, then you try to get as far away from it as possible.

Syntax checkup:
Wrong: OS's, IRQ's, zero'ing
Right: OSes, IRQs, zeroing


Top
 Profile  
 
 Post subject: Re: Monolithic vs. Microkernel hardware boot drivers
PostPosted: Mon Jul 11, 2016 4:18 am 
Offline
Member
Member
User avatar

Joined: Wed Oct 18, 2006 3:45 am
Posts: 9301
Location: On the balcony, where I can actually keep 1½m distance
tjmonk15 wrote:
How would you log a specific driver accessing a specific port only using an IO Bitmap? (Hint: you can't)

- Monk
An IOPB comes with system calls to enable individual ports, and it's by any means the fastest safe implementation. If all you want to log is which driver uses which ports, then you already have the system call for the diagnostic. In fact if you assign IO privileges from the device manager based on what it should be using, then the choice for IOPB is irrelevant altogether because you know the answer well before the driver is even started.

If you want to do the full-blown equivalent of mmiotrace, you will have to trap every IO access. You can simply not set the IOPB bits upon request and instead emulate them from the GPF handler. You can even go at it the same way as MMIOtrace does by enable-singlestep-disable, but the IO instructions are easily enumerable so you can do it from there.




But that's all overdiscussed regardless. Everyone even capable of having this discussion should just add a print statement to the driver itself and recompile. :mrgreen:

_________________
"Certainly avoid yourself. He is a newbie and might not realize it. You'll hate his code deeply a few years down the road." - Sortie
[ My OS ] [ VDisk/SFS ]


Top
 Profile  
 
 Post subject: Re: Monolithic vs. Microkernel hardware boot drivers
PostPosted: Mon Jul 11, 2016 5:17 am 
Offline
Member
Member
User avatar

Joined: Sat Jan 15, 2005 12:00 am
Posts: 8561
Location: At his keyboard!
Hi,

Combuster wrote:
tjmonk15 wrote:
How would you log a specific driver accessing a specific port only using an IO Bitmap? (Hint: you can't)
An IOPB comes with system calls to enable individual ports, and it's by any means the fastest implementation.


"IOPL=3" is fastest for each IO port access. IO Permission Bitmap is probably a close second (due to the extra memory fetch).

For the overhead of task switching (which is typically a frequent operation for micro-kernels), IO Permission Bitmap can be the worst/slowest option (e.g. if you copy up to 8 KiB of extra data) or can complex (e.g. if you use tricks to avoid the copy).

Mostly you can give each of the options ratings in several categories:
  • Granularity: GPF and syscall tie as winners, "IOPL=3" is worst
  • Per IO port access overhead: "IOPL=3" is winner, GPF is worst
  • Per task switch overhead: GPF and syscall tie as winners, IOPB is worst
  • Flexibility (e.g. IO port remapping): GPF and syscall tie as winners, "IOPL=3" is worst
  • Complexity: "IOPL=3" is winner, not sure which is worst (GPF or IOPB)

Combuster wrote:
If all you want to log is which driver uses which ports, then you already have the system call for the diagnostic.


The idea is to log which value is read/written to which IO port (in which order). Did you write the correct value to the device's command port? What did the driver read from the "status" port?

Combuster wrote:
But that's all overdiscussed regardless. Everyone even capable of having this discussion should just add a print statement to the driver itself and recompile. :mrgreen:


Can you give me instructions on how to do this? I have a closed source/proprietary NVidia video card driver (on Windows) that I'd like to reverse engineer, and I'm not even sure where millions of lines of text per second would end up (it's not like device drivers have "stdout" or anything). :roll:


Cheers,

Brendan

_________________
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.


Top
 Profile  
 
 Post subject: Re: Monolithic vs. Microkernel hardware boot drivers
PostPosted: Mon Jul 11, 2016 5:46 am 
Offline
Member
Member
User avatar

Joined: Wed Oct 18, 2006 3:45 am
Posts: 9301
Location: On the balcony, where I can actually keep 1½m distance
I excluded IOPL=3 as an option because IMO it disqualifies all system integrity rules. For pendantics, I should have added the word "safe". I have IOPB/IRB implemented with zero context-switch overhead using paging, and I consider that the most obvious approach as well, so that introduces unnecessary bias from your end.

Your statement about windows drivers however is however exactly the fallacy the cursive text was meant to preclude: You can't pretend there is a choice of interface when that choice has been premade. You can't drag in windows drivers and pretend they magically match your OS design.

_________________
"Certainly avoid yourself. He is a newbie and might not realize it. You'll hate his code deeply a few years down the road." - Sortie
[ My OS ] [ VDisk/SFS ]


Top
 Profile  
 
 Post subject: Re: Monolithic vs. Microkernel hardware boot drivers
PostPosted: Mon Jul 11, 2016 10:42 am 
Offline
Member
Member

Joined: Sun Feb 28, 2016 5:33 pm
Posts: 45
Location: Merced, California
Brendan wrote:
The kernel is relatively insignificant - a tiny 64 KiB piece dwarfed by tens of MiB of "everything else that's needed to get from start of boot loader all the way to user login".


This considering, I've been beginning to wonder regarding the place in the microkernel for ACPI, particularly the configuration routines. Seeing as ACPI table scan routines can basically preclude access to wanton or arbitrary amounts/ranges of memory, I'm uneasy with it as of now as it violates the concept of security compartmentalization that I've been attempting to develop here. I suppose the runtime environment module might be able to be constrained to a particular memory region once AML is parsed.

Would the configuration components (port resolution, memory range discovery, etc.) be better put into a bootstrap routine (that is, the bootstrap negotiates the ACPI scanning and parsing) such that the main OS simply accepts port ranges and other relevant information as a structure?


Top
 Profile  
 
 Post subject: Re: Monolithic vs. Microkernel hardware boot drivers
PostPosted: Mon Jul 11, 2016 2:08 pm 
Offline
Member
Member
User avatar

Joined: Sat Jan 15, 2005 12:00 am
Posts: 8561
Location: At his keyboard!
Hi,

physecfed wrote:
Brendan wrote:
The kernel is relatively insignificant - a tiny 64 KiB piece dwarfed by tens of MiB of "everything else that's needed to get from start of boot loader all the way to user login".


This considering, I've been beginning to wonder regarding the place in the microkernel for ACPI, particularly the configuration routines. Seeing as ACPI table scan routines can basically preclude access to wanton or arbitrary amounts/ranges of memory, I'm uneasy with it as of now as it violates the concept of security compartmentalization that I've been attempting to develop here. I suppose the runtime environment module might be able to be constrained to a particular memory region once AML is parsed.

Would the configuration components (port resolution, memory range discovery, etc.) be better put into a bootstrap routine (that is, the bootstrap negotiates the ACPI scanning and parsing) such that the main OS simply accepts port ranges and other relevant information as a structure?


How you do it is up to you; but none of it needs to be in the kernel. Some ACPI tables (APIC/MADT, SRAT, SLIT, etc) could be parsed by boot code (e.g. before kernel started), some (those containing ACPI's AML) might get passed to a "generic motherboard driver" that's started after the kernel has (but before device enumeration begins and other drivers are started).


Cheers,

Brendan

_________________
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 51 posts ]  Go to page Previous  1, 2, 3, 4

All times are UTC - 6 hours


Who is online

Users browsing this forum: No registered users and 32 guests


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 post attachments in this forum

Search for:
Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group