OSDev.org

Sorry, I don't check this on an every day basis if I was slightly late to the party. My point was, why throw random (false) information about there just for fun? Yes, you need to be careful in many things for both a micro and mono, that i'm not disputing, but just putting random statements about, be careful if you are writing an [insert anything that has nothing to do with topic here], which confuses people and makes them think that whatever the statement was must be something important and maybe they should just avoid using it. It's like if someone is asking about putting pixels to screen (common topic lately), and stating to be careful about writing an exo kernel if you're doing this. It has nothing to do with anything. Yes, there are things to look out for in an exo kernel, but a statement like that makes no sense, and is confusing.

This is an entirely reasonable statement. I don't understand your objection. In a monolithic kernel no precautions are necessary because all drivers are part of the kernel and userspace has no chance to exploit anything. In a microkernel drivers look like user processes and extra precautions need to be taken because some access is given to user processes. It's pretty simple.

Ok, I digress, I probably took this further than it needed to go, it's just that you need to take precautions for userspace software irregardless of whether it's for dma, video, networking, or anything else. It is good advice, but nowhere did anyone say anything about a microkernel and the statement seemed to come from nowhere.

3. In my opinion this point didn't need to be made. The OP's question had already answered by mariuszp when he said "...if you want those to run in the kernel, then yes". Your additional comment that the DMA area doesn't need to be mapped at all just confuses the issue. Just to be clear, to perform the action commonly known as DMA, it is necessary to map the physical memory used for the DMA access into a virtual address or else your software will not be able to access said area and the DMA will be a waste of time.

Yes, and I said that if you didn't map it anywhere it wouldn't be very useful. I also stated that you can map it to one or multiple places, which is also true. This is relevant, the point is that DMA uses physical memory which can then be mapped virtually to be used by anything that needs it. These are all true statements and are on point to the post.

Sorry, but no. How you handle DMA safely in a microkernel is very different from in a monolithic kernel, and it's very relevant when asking about DMA buffers, as it affects how the driver allocates and refers to them. Just stop embarrassing yourself.

Ready4Dis wrote:Ok, I digress, I probably took this further than it needed to go, it's just that you need to take precautions for userspace software irregardless of whether it's for dma, video, networking, or anything else. It is good advice, but nowhere did anyone say anything about a microkernel and the statement seemed to come from nowhere.

It didn't come from nowhere. The question was whether the DMA buffer would be in kernel memory, and the answer is that it depends on the kernel type.

And yes, if you allow userspace to access hardware that can do DMA, you essentially enable userspace to access kernel memory and in consequence to run code in ring 0. That's a problem very specific to DMA with userspace drivers and certainly can't hurt to mention in this context. You can accept that your drivers can get kernel privileges even though supposed to run in userspace (but you might want to prevent normal userspace applications from doing this), or you can try using an IOMMU, but insisting that people don't even mention the problem won't solve it.

Rusky wrote:Sorry, but no. How you handle DMA safely in a microkernel is very different from in a monolithic kernel, and it's very relevant when asking about DMA buffers, as it affects how the driver allocates and refers to them. Just stop embarrassing yourself.

Seeing as i'm writing a micro kernel and monolithic kernel side by side and keeping my drivers source compatible, I'm going to say how DMA is handled in both is rather similar... and thanks for the concern, but I don't embarrass easily .

Sorry, but no. How you handle DMA safely in a microkernel is very different from in a monolithic kernel, and it's very relevant when asking about DMA buffers, as it affects how the driver allocates and refers to them. Just stop embarrassing yourself.

I understand that you can load things into physical memory with DMA, and yes, you don't want to give normal old apps access to map stuff anywhere. This is true in a mono kernel as well, you trust your DMA driver to function properly, and then you restrict access to anything that shouldn't be calling DMA directly. If you have no security policy in your micro, then you are doing something wrong, not just for DMA but for any service/driver that has access.

I do agree that it is especially important due to the fact that it can overwrite memory inside the kernel and be able to run a rogue program in kernel space, and if that was the actual point, then it makes sense to include here, but I did not get that from his message and thank you for clarifying the actual reason for the message. In this context it makes sense to me now.

Ready4Dis wrote:I understand that you can load things into physical memory with DMA, and yes, you don't want to give normal old apps access to map stuff anywhere. This is true in a mono kernel as well, you trust your DMA driver to function properly, and then you restrict access to anything that shouldn't be calling DMA directly. If you have no security policy in your micro, then you are doing something wrong, not just for DMA but for any service/driver that has access.

I do agree that it is especially important due to the fact that it can overwrite memory inside the kernel and be able to run a rogue program in kernel space, and if that was the actual point, then it makes sense to include here, but I did not get that from his message and thank you for clarifying the actual reason for the message. In this context it makes sense to me now.

I understood that this was mariuszp's point indeed, but I can't read his mind, obviously.

There's one important point why I do think that there's a difference between monolithic and microkernel in this context: Monolithic kernels already run drivers in ring 0 and don't need to let userspace access hardware at all, so for userspace the problem doesn't exist and for drivers it's not a privilege escalation. This is pretty much as everyone would expect. However, that letting userspace code access hardware (like you do with a microkernel) breaks the privilege separation between kernel and userspace because of DMA is something that could be surprising if you have never thought about it. After all, you only gave permission to the specific port/MMIO region that the driver needs.

I understand, but you still have to limit access to drivers/servers. If you have a memory management server, you aren't going to give regular user apps access... same goes for task management, or block device (maybe this one? Not typically without going through a VFS of sorts first though). Giving access to what needs it is a pretty integral part of the design. Just like you wouldn't give a user app access to a memory manager in a micro kernel, I wouldn't let a user app register itself as a driver and end up in kernel space in a mono.

I do agree that the design of a mono and micro are different, and they must solve the same problems in different ways, but they are still the same problems. I guess it just depends on how far away you're looking at said problems, you might see them as different if you're looking at an exact implementation, I only see them as the same because I'm looking at how to protect my kernel. Like I mentioned earlier, if you let your user apps just talk to any device/driver/service it wants, then it's not that you need to be careful writing the driver, you need to re-think your design because you missed basic security. This can be true in any system. So, in end, yes if you look closely there are differences (if they where identical, we wouldn't call them two different types of kernels).

Either way, like I said, my micro and mono drivers are completely source compatible (and hopefully soon binary compatible), I don't see why my DMA code needs to concern itself with things like safety. All of my drivers are as dumb as possible on purpose, so they are generic and easy to implement. The security is at the kernel/os level. My graphics driver is just a really low level interface, it doesn't care who is telling it to do what, but the kernel or OS permissions will only allow certain things to send it requests. If I left my security up to the service/driver then I would never let anyone write a driver for my OS .

It's not that the drivers need to be different, it's that the code underneath the drivers needs to be different. In a monolithic kernel you can use DMA directly with arbitrary memory addresses, because you already have access to all of RAM. In a microkernel you would ideally check or limit which addresses and devices the driver can touch.

Ready4Dis wrote: In my micro kernel, trusted drivers are loaded with more access than users (in the cases that require it)... in my monolithic kernel, drivers are dynamically linked against my kernel in kernel space if they are trusted... I still fail to see any difference. In both of my kernels I need to trust a driver to do what it should and give it access that it needs. My DMA code for my micro and mono are (going to be) 100% identical besides the calling convention which is abstracted away in a library.

I think I have identified the Layne's Law[1] issue at the root of this disagreement. Strictly speaking, both of these would be considered hybrid kernels by the definitions used by most of the people here. As classically defined, a monolithic kernel has all drivers and other system components linked into a single executable prior to operating, while a microkernel (again, following the strict definition) has all non-kernel system components (including drivers) running as unprivileged user processes (they also usually do not allow for sharing memory except in the IPC system, and only allow processes to communicate through message passing regardless of privilege[2], so sharing the DMA space would violate the system model). Dynamically loading drivers into kernel space and giving partial system privileges to user processes are defining characteristics of two different approaches to writing hybrid kernels.

To be fair, hardly anyone writes strictly monolithic or strictly microkernel systems any more, but defining our terms in a way that everyone can agree on them is both difficult and important.

1) Layne's Law: Most forum debates boil down to disagreements over how you define your terms.

2) Indeed, a classic microkernel doesn't even have system calls in the strict sense, but passes system service requests as messages as well. Historically, microkernels were associated mainly with systems lacking hardware memory management (e.g., AmigaOS on the 68000 models), and often with CPUs that had no separation of privileges, such as the 8088[3] (Minix v.1 and v.2, early versions of Qnx) and the 6809 (OS-9). Limiting the interface between processes was a key objective under such systems.

3. Before any one asks: no, MS-DOS was not a microkernel. Monotasking operating systems, particularly those which don't have a kernel per se, are (under strict terminology) described as 'executive monitors', specifically resident executives in the case of MS-DOS (since it normally would stay in memory while the user program was running).