OSDev.org

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.

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.

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.

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).


Cheers,

Brendan

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.

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?

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