DMA allocation. Once paging is enabled?

[JulienDarc]

Hello,

Been a while.
Once paging is enabled on a x86_64 system, is it still possible to allocate a 8k dma buffer of contiguous memory, when page size is 4096?

I should do that before enabling paging, using the physical allocator, in the kernel memory area.

But for the sake, I ask.

Thanks,

Bye

[iansjack]

As you have to allocate physical memory for purposes such as DMA, you just choose an 8k contiguous block of physical memory. It's not that difficult to program an allocator that will allow this to happen.

[JulienDarc]

That area will have to be in the kernel space, right?

[mariuszp]

That area will have to be in the kernel space, right?

DMA is only useful to device drivers and if you want those to run in the kernel, then yes. If you're programming a microkernel you'd have to take precautions to not allow userspace software to somehow exploit this.

What you should be doing is allocating 2 frames (8K) of physical memory that are right next to each other (physically contiguous). You then have to map that into 2 contiguous pages of virtual memory so that you can access it, but you pass the physical address of the first frame to devices to allow them to read it.

[JulienDarc]

Got it,

Thanks!

[Ready4Dis]

What you should be doing is allocating 2 frames (8K) of physical memory that are right next to each other (physically contiguous). You then have to map that into 2 contiguous pages of virtual memory so that you can access it, but you pass the physical address of the first frame to devices to allow them to read it.

Why should he allocate 2 8k buffers if he is using a single 8k dma transfer? Simply write your physical memory manager to handle requesting 8k of contiguous memory... if you only want an app to have read only privileges for this, then memory map the page for them and mark as read only. I'm not really sure what the two buffers are about, maybe I'm missing something?

If you're programming a microkernel you'd have to take precautions to not allow userspace software to somehow exploit this.

Not exactly sure what this has to do with a micro kernel. If you a user space application asks the DMA Driver to do something, and the DMA driver deems it valid, what part of being careful is there? How is this in any way specific to microkernels? Of course if you program sloppy code it will turn out like crap, whether it's micro or mono or any other fadish name like nano, pico, and exo. If the DMA driver has the rights to the IO ports for DMA and nobdy else does, why do you need to 'be careful' in any type of kernel? If you map regions of memory for userspace that shouldn't be mapped then shame on you, but don't blame the kernel (unless it's your kernel and you're saying you did a crappy job at any sort of protection).

That area will have to be in the kernel space, right?

The area does not have to be in ANY space if you don't want it to be, it's just a physical location. You can choose to map it to the kernel space, a user space, or simply dump data into a physical memory location that's never used. It makes no difference besides who you need to access it. You can map it in multiple spaces if you want.

[hgoel]

What you should be doing is allocating 2 frames (8K) of physical memory that are right next to each other (physically contiguous). You then have to map that into 2 contiguous pages of virtual memory so that you can access it, but you pass the physical address of the first frame to devices to allow them to read it.

Why should he allocate 2 8k buffers if he is using a single 8k dma transfer? Simply write your physical memory manager to handle requesting 8k of contiguous memory... if you only want an app to have read only privileges for this, then memory map the page for them and mark as read only. I'm not really sure what the two buffers are about, maybe I'm missing something?

I believe he meant 2x4k page frames or 8k in total rather than 2 8k buffers.

If you're programming a microkernel you'd have to take precautions to not allow userspace software to somehow exploit this.

Not exactly sure what this has to do with a micro kernel. If you a user space application asks the DMA Driver to do something, and the DMA driver deems it valid, what part of being careful is there? How is this in any way specific to microkernels? Of course if you program sloppy code it will turn out like crap, whether it's micro or mono or any other fadish name like nano, pico, and exo. If the DMA driver has the rights to the IO ports for DMA and nobdy else does, why do you need to 'be careful' in any type of kernel? If you map regions of memory for userspace that shouldn't be mapped then shame on you, but don't blame the kernel (unless it's your kernel and you're saying you did a crappy job at any sort of protection).

I think the reason he mentions specifically microkernels, is because

Traditional operating system functions, such as device drivers, protocol stacks and file systems, are typically removed from the microkernel itself and are instead run in user space

If the drivers run in user space, it makes sense that you would want to be careful to not make it possible for normal software to somehow use DMA because that would bypass the process isolation provided by virtual memory.

[iansjack]

if you only want an app to have read only privileges for this, then memory map the page for them and mark as read only

You need to memory map them whether you want them to be read only or not and you map them to two pages, not "the" page. You can't have a single 8K page on an x86 system. You could have a single 2MB or 4MB page (depending upon your processor), but this would waste RAM.

[Ready4Dis]

I believe he meant 2x4k page frames or 8k in total rather than 2 8k buffers.

Yes reading it again, I see that I was mistaken, good catch.

I think the reason he mentions specifically microkernels, is because

Traditional operating system functions, such as device drivers, protocol stacks and file systems, are typically removed from the microkernel itself and are instead run in user space

If the drivers run in user space, it makes sense that you would want to be careful to not make it possible for normal software to somehow use DMA because that would bypass the process isolation provided by virtual memory.

That's still not microkernel specific. If you allow a user application to modify DMA in a mono kernel it would be the same issue... I still don't see what this has to do with microkernels. Either you setup protection correctly or you didn't, irregardless of the kernel type. I would say you would have to be more careful in a mono kernel if anything, as no driver has any protection from the next, making it very easy for multiple drivers to try to do their own DMA. In a mono, only one process gets access to the i/o ports (or memory mapped i/o), so there is a lot less chance that anything else could possibly do that. So I still don't see the argument about 'being especially careful in a microkernel'. This is the entire point of them is to separate everything so this can't happen.

You need to memory map them whether you want them to be read only or not and you map them to two pages, not "the" page. You can't have a single 8K page on an x86 system. You could have a single 2MB or 4MB page (depending upon your processor), but this would waste RAM.

Of course you have to memory map the page for any type of access, or you can choose not to use it for anything and not map it to anything (not that this would be very useful). I understand you can't have an 8k page, I was referring to the fact that he said to map 2x8k areas, instead of 2x4k, which I completely misunderstood, because re-reading it now, he was saying 2 4k frames for a total of 8k, my apologies on that one.

[Rusky]

Microkernel is just an example of a design where you'd be likely to expose DMA to user space, and the "extra-careful" refers to the fact that you can't accept arbitrary physical addresses from user space (which would bypass the protection of paging) the way you can in kernel space (where there's nothing to bypass anyway).

[Ready4Dis]

Microkernel is just an example of a design where you'd be likely to expose DMA to user space, and the "extra-careful" refers to the fact that you can't accept arbitrary physical addresses from user space (which would bypass the protection of paging) the way you can in kernel space (where there's nothing to bypass anyway).

So you load a driver that's specifically written to do DMA.. you either A.) trust it's coded correctly or B.) don't trust it and never use DMA.

Either option is valid under any kind of kernel. If you put your DMA driver in kernel space can just as easily overwrite those same physical pages it would have in a microkernel, so I still don't understand how this has anything to do with the kernel type. Trusting a driver is something that you must do at some point in any operating system. You have MORE trust of that driver if it's in kernel space, not less, so I don't really know why people bring up kernel type into the discussion.

the "extra-careful" refers to the fact that you can't accept arbitrary physical addresses from user space

That is not a fact, that is your opinion. There is nothing stopping anyone from accepting arbitrary physical addresses from user space. Like I said, in a microkernel, you still have to trust your drivers to act properly. Anytime you give a driver access to the hardware you are putting your trust into it irregardless of kernel design.

[gerryg400]

So you load a driver that's specifically written to do DMA.. you either A.) trust it's coded correctly or B.) don't trust it and never use DMA.

Either option is valid under any kind of kernel. If you put your DMA driver in kernel space can just as easily overwrite those same physical pages it would have in a microkernel, so I still don't understand how this has anything to do with the kernel type. Trusting a driver is something that you must do at some point in any operating system. You have MORE trust of that driver if it's in kernel space, not less, so I don't really know why people bring up kernel type into the discussion.

In a microkernel (in mine anyway) drivers run as normal user processes. To do this, the kernel must provide a means to allow user processes access to parts of the hardware. That means having extra or modified API calls that a monolithic kernel does not have to provide that access. It follows from this that there also needs to be a way to identify drivers from other user processes to ensure that not everyone can use the extra APIs.

Trust is not enough, extra or perhaps different care must be taken.

[Ready4Dis]

So you load a driver that's specifically written to do DMA.. you either A.) trust it's coded correctly or B.) don't trust it and never use DMA.

Either option is valid under any kind of kernel. If you put your DMA driver in kernel space can just as easily overwrite those same physical pages it would have in a microkernel, so I still don't understand how this has anything to do with the kernel type. Trusting a driver is something that you must do at some point in any operating system. You have MORE trust of that driver if it's in kernel space, not less, so I don't really know why people bring up kernel type into the discussion.

In a microkernel (in mine anyway) drivers run as normal user processes. To do this, the kernel must provide a means to allow user processes access to parts of the hardware. That means having extra or modified API calls that a monolithic kernel does not have to provide that access. It follows from this that there also needs to be a way to identify drivers from other user processes to ensure that not everyone can use the extra APIs.

Trust is not enough, extra or perhaps different care must be taken.

So... this is advice for designing a microkernel, and is in no way DMA specific? Yes, you must trust that driver to use proper addresses since it can easily overwrite memory of a physical location, bypassing the virtual memory. Trust is enough, because if you didn't trust it, you wouldn't give it access to the i/o ports it requires to function. How you define 'trust' in your kernel might be different than someone else. Of course you must identify a driver being different, you can't just trust every single process to run without screwing things up. This sounds more like a microkernel design theme than a DMA specific issue though, as if you allow all of your user processes to just do whatever they want, I think the DMA driver is the least of your concerns. 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. Why do I need to pay more attention to anything in my micro that I don't have to worry about in my mono? The answer is.... I don't, it's the same.

For completeness, yes, I do have a micro and mono kernel that I am developing side by side. And no, I haven't had to pay any extra particular attention in the micro kernel for drivers (although admittedly, it's not as far along as the mono yet).

[Rusky]

So you load a driver that's specifically written to do DMA.. you either A.) trust it's coded correctly or B.) don't trust it and never use DMA.

Or how about option C.) only trust it to use DMA correctly with memory you've specifically allocated to it with the devices you've specifically allowed it access to.

In a monolithic kernel you pretty much do just have "full trust" or "no trust." The entire point of a microkernel, though, is to isolate different parts of the system from each other, which ideally means trusting drivers only with what they need. You could, for example, let drivers allocate contiguous physical memory, and then only let them DMA using handles to those buffers rather than arbitrary physical addresses.

[gerryg400]

So... this is advice for designing a microkernel, and is in no way DMA specific?

Why do you keep asking this? Why is it so vitally important to you that we only talk about things are DMA specific and can not be applied in other areas AS WELL AS DMA? Stop trying to make an argument where there is none.

Please look back through this thread and you will see that the OP asked a question and that that question was answered within about 30 minutes. 8 days later you questioned the validity of the answer and made 3 points.

Let's have a look...

1. You have since admitted that you were mistaken in the first point, so let's ignore it.

2.

If you're programming a microkernel you'd have to take precautions to not allow userspace software to somehow exploit this.

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.

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.