>They are less powerful in user-space he states this about 25 minutes into the talk "moving bugs to user-space will do less damage"...roughly.This is true instead of getting full ring0 access to anything I can only do what the driver is allowed to do if I exploit a bug in the driver.
I did listen to the talk and that justification. That's why I said it was pretty limited. That may be true for security bugs in drivers. For a network driver that may even be very important. In practice what I see is that the actual bugs I care about in Linux drivers are code bugs that disable the device, or in a filesystem cause disk corruption. None of those are solved by a microkernel. Microkernels give you a bunch of provable advantages in areas that monolithic kernels don't seem to do too badly at.
>Why would there be added complexity? Linux has an api just as well but less defined than simple ipc - even more complex.
This is anything but simple IPC. You're sending async messages around and wanting to handle restart of whole pieces and reissuing of commands. It is much more complex and with many more edge cases that the equivalent Linux call stack.
>Hard to debug? you do understand that having parts of the kernel in userspace makes it easier to debug
Because now you're trying to restart a driver for a device that is in an unknown state and then restarting the operation of the filesystem accessing the driver that now has to make sure its operations are idempotent otherwise it will screw up. The number of new edge cases is immense. It could get hairy really fast. That is even touched upon in the presentation with the async messaging and deadlock avoidance. That's why it's harder to debug. Because you're adding a bunch of complex code in error handling paths that get executed once in a blue moon.
>Read LWN theres roughly a root exploit every 2 weeks
I read LWN every week, there are some local root exploits once in a while. The memory protection stuff could be good for that and you could implement it in Linux if you wanted. I specifically stated that part is interesting for this. My point is that the non-security bugs I care about wouldn't be prevented by this technique.
I did listen to the talk and that justification. That's why I said it was pretty limited. That may be true for security bugs in drivers. For a network driver that may even be very important. In practice what I see is that the actual bugs I care about in Linux drivers are code bugs that disable the device, or in a filesystem cause disk corruption. None of those are solved by a microkernel. Microkernels give you a bunch of provable advantages in areas that monolithic kernels don't seem to do too badly at.
>Why would there be added complexity? Linux has an api just as well but less defined than simple ipc - even more complex.
This is anything but simple IPC. You're sending async messages around and wanting to handle restart of whole pieces and reissuing of commands. It is much more complex and with many more edge cases that the equivalent Linux call stack.
>Hard to debug? you do understand that having parts of the kernel in userspace makes it easier to debug
Because now you're trying to restart a driver for a device that is in an unknown state and then restarting the operation of the filesystem accessing the driver that now has to make sure its operations are idempotent otherwise it will screw up. The number of new edge cases is immense. It could get hairy really fast. That is even touched upon in the presentation with the async messaging and deadlock avoidance. That's why it's harder to debug. Because you're adding a bunch of complex code in error handling paths that get executed once in a blue moon.
>Read LWN theres roughly a root exploit every 2 weeks
I read LWN every week, there are some local root exploits once in a while. The memory protection stuff could be good for that and you could implement it in Linux if you wanted. I specifically stated that part is interesting for this. My point is that the non-security bugs I care about wouldn't be prevented by this technique.