+static int tdg_attest_open(struct inode *inode, struct file *file)Why is this ioctl not part of the driver that registered the interrupt
+ * Currently tdg_event_notify_handler is only used in attestation
+ * driver. But, WRITE_ONCE is used as benign data race notice.
+ WRITE_ONCE(tdg_event_notify_handler, attestation_callback_handler);
handler for this callback in the first instance? I've never seen this
style of cross-driver communication before.
+Why does this driver abandon all semblance of type-safety and use
+ file->private_data = (void *)__get_free_pages(GFP_KERNEL | __GFP_ZERO,
->private_data directly? This also seems an easy way to consume
memory, just keep opening this device over and over again.
AFAICS this buffer is only used ephemerally. I see no reason it needs
to be allocated once per open file. Unless you need several threads to
be running the attestation process in parallel just allocate a single
buffer at module init (statically defined or on the heap) and use a
lock to enforce only one user of this buffer at a time. That would
also solve your direct-map fracturing problem.
All that said, this new user ABI for passing blobs in and out of the
kernel is something that the keyutils API already does. Did you
consider add_key() / request_key() for this case? That would also be
the natural path for the end step of requesting the drive decrypt key.
I.e. a chain of key payloads starting with establishing the