macOS Developer ID certificates for kext singing

[startergo]

Has anyone had any success obtaining Developer ID Certificates for kext signing? The standard response I receive from Apple to all my emails is:

KEXT signing is only available to corporate developer accounts, not individual accounts.

Regards,
KEXT Signing Review Team
Apple Worldwide Developer Relations

 

[casperes1996]

Do you have a corporate developer account?

In general Apple wants to get as much away from kexts as possible, and you also need to file out an application in which you argue for why you cannot achieve what you want to achieve in any other way than with a kext. - What are you trying to achieve? Maybe it can be done with DriverKit or other non-kext approaches

 

[startergo]

Do you have a corporate developer account?

Do I have 100 people working for me? No. I can't do a kernel kext with driver kit. The driver kit is for the user space. It is a shame they imposed this restriction as I know there were people with regular individual paid developer accounts signing kexts in the past.

 

[Basic75]

I can't do a kernel kext with driver kit

I don't think that's what @casperes1996 was suggesting, he's probably asking what you are trying to achieve to see whether the same goal can be reached without using a kext.

 

[startergo]

I don't think that's what @casperes1996 was suggesting, he's probably asking what you are trying to achieve to see whether the same goal can be reached without using a kext.

I am upgrading an existing project which is in the form of a Kext. The project original goal is:
An IOFramebuffer driver for the QEMU Virtual Video Controller (QEMU default vga) and VirtualBox Graphics Adapter. It allows to set different screen resolutions in QEMU and VirtualBox from System Preferences.
The upgrading goal is to provide hardware acceleration through Virtio video drivers through virglrenderer:

┌─────────────────────────────────────────────────┐
│         macOS OpenGL/CGL Framework              │
│    (queries IOAccelerator for renderers)        │
└────────────────┬────────────────────────────────┘
                 │
                 ▼
┌─────────────────────────────────────────────────┐
│      VMQemuVGAAccelerator (IOAccelerator)       │
│  - createRenderContext()                        │
│  - destroyRenderContext()                       │
│  - submitCommand()                              │
│  - flushContext()                               │
│  etc. (IOAccelerator protocol methods)          │
└────────────┬─────────────────┬──────────────────┘
             │                 │
             ▼                 ▼
    ┌────────────────┐  ┌──────────────────┐
    │  VMQemuVGA     │  │  VMVirtIOGPU     │
    │  (QXL/SVGA)    │  │  (VirtIO GPU)    │
    │  Snow Leopard  │  │  Catalina+       │
    └────────────────┘  └──────────────────┘

kernel interfaces required for the kext:
IOKit Framework Interfaces:
- IOPCIDevice: Direct access to emulated PCI graphics hardware registers
- IOMemoryDescriptor: Memory mapping for framebuffer and VRAM management
- IOService: Core service registration and device matching
- IOUserClient: User-space to kernel communication for graphics operations

Graphics-Specific Kernel Interfaces:
- IOAccelerator: Graphics acceleration framework integration
- IOSurface: Shared surface management between kernel and user space
- IOGraphicsFamily: Display management and mode setting
- IOFramebuffer: Framebuffer management and display output

Memory Management:
- IOBufferMemoryDescriptor: DMA buffer allocation for graphics operations
- IOPhysicalAddress: Physical memory access for hardware registers
- vm_map_kernel: Kernel virtual memory mapping for device registers

Hardware Abstraction:
- PCI Configuration Space: Reading/writing PCI device configuration
- Memory-Mapped I/O: Direct hardware register access
- Interrupt Handling: Graphics hardware interrupt processing

These interfaces are essential for:
- Direct hardware emulation bypass for performance
- Memory-mapped graphics register access
- Efficient buffer sharing between kernel and user space graphics layers

DriverKit Limitations:

1. HARDWARE ABSTRACTION BYPASS:
- DriverKit's sandboxed environment cannot access raw PCI configuration space
- Kernel-level access required for memory-mapped I/O to emulated graphics registers

2. LEGACY SYSTEM COMPATIBILITY:
- Target systems (Snow Leopard) predate DriverKit by over a decade
- IOKit compatibility essential for historical macOS graphics stack integration
- DriverKit frameworks unavailable on legacy target systems

3. PERFORMANCE REQUIREMENTS:
- Graphics operations require direct memory access without user-space overhead
- Kernel-level buffer management essential for real-time graphics rendering
- User-mode memory copying would create unacceptable latency for graphics

4. VIRTUALIZATION-SPECIFIC NEEDS:
- Must integrate with hypervisor memory management (QEMU/UTM)
- Requires direct access to virtualized hardware abstractions
- DriverKit's security model incompatible with virtualization requirements

5. EXISTING GRAPHICS STACK INTEGRATION:
- Must interface with legacy IOGraphicsFamily frameworks
- WindowServer expects kernel-level graphics driver interface
- User-mode solutions cannot provide required system-level graphics services