News for hackers. Stuff that matters.
Re:Unikernels: No Longer an Academic Exercise? by rayiner on Tuesday October 23, 2018 @12:39PM (#18284941)
We are already seeing exokernel concepts. On a Linix machine, most 3D graphics is handled in the userspace GL library. The kernel driver handles modesetting, manages memory, and arranges for the userspace library to be able to directly submit command buffers to the GPU via memory mapped areas. DPDK works the same way. The NIC ring buffer is mapped directly into the userspace process, which can then perform packet I/O without calling into the kernel.
Re:Unikernels: No Longer an Academic Exercise? by pcwalton on Tuesday October 23, 2018 @05:19PM (#18287593)
Well, that's roughly how it's supposed to work in theory for graphics, but in practice the kernel ends up having to do fairly deep parsing of GPU command buffers for security.

See, for example: https://www.kernel.org/doc/html/v4.11/gpu/i915.html#batchbuf...

Re:Unikernels: No Longer an Academic Exercise? by atq2119 on Tuesday October 23, 2018 @07:16PM (#18288341)
Intel's GPUs aren't exactly known for stellar performance, but I'm pretty sure that's old info even for Intel. Certainly this kind of parsing hasn't been required on AMD and Nvidia GPUs' 3D engines for almost ten years now.
Re:Unikernels: No Longer an Academic Exercise? by pcwalton on Tuesday October 23, 2018 @08:02PM (#18288561)
There's still a good bit of it necessary even for new GPUs like Radeon R600.

See r600_packet0_check, r600_packet3_check: https://github.com/torvalds/linux/blob/master/drivers/gpu/dr...

Re:Unikernels: No Longer an Academic Exercise? by rayiner on Tuesday October 23, 2018 @10:01PM (#18289097)
Thanks for the very interesting references and discussion. GPUs are hard, huh? AFAIK, this sort of validation isn't necessary for NICs. (Question: why is parsing necessary to ensure security, instead of say relying on the IO-MMU?)
Re:Unikernels: No Longer an Academic Exercise? by atq2119 on Wednesday October 24, 2018 @03:00AM (#18290254)
The IO-MMU only provides device-level isolation for accesses to RAM, but you really need process isolation, and not just for accesses to RAM but also for VRAM where the IO-MMU is not in play at all.

NICs are an unfair comparison because the commands for NICs are all generated by the kernel, which is trusted. For GPUs, commands are generated by an untrusted user space driver that translates OpenGL or Vulkan commands into command packets for the GPU. Those command packets contain memory addresses, so in order to achieve isolation between different user space processes in the face of a potentially malicious user space driver, the kernel used to have to validate those addresses in the absence of GPU page tables.

Anyway, this kind of validation really hasn't been necessary for a long time now, despite pcwalton's outdated information, because GPU page tables were phased in around 2010. (The first AMD chip to have them was Cayman in 2010. Since we're citing kernel drivers here, take a look at https://github.com/torvalds/linux/blob/44786880df196a4200c17... and note how the function skips any parsing when virtual memory is used.)

Re:Unikernels: No Longer an Academic Exercise? by atq2119 on Wednesday October 24, 2018 @03:10AM (#18290292)
R600 is not a new GPU, don't know how you got that idea :) It was released in 2007.
Re:Unikernels: No Longer an Academic Exercise? by pjmlp on Wednesday October 24, 2018 @02:51AM (#18290222)
Except that on Windows the kernel part is quite tiny. Still waiting for X to survive driver crashes.