Get rid of 'remove_new' relic from platform driver structThe continual trickle of small conversion patches is grating on me, andis really not helping. Just get rid of the 'remove_new' memberfunc
Get rid of 'remove_new' relic from platform driver structThe continual trickle of small conversion patches is grating on me, andis really not helping. Just get rid of the 'remove_new' memberfunction, which is just an alias for the plain 'remove', and had acomment to that effect: /* * .remove_new() is a relic from a prototype conversion of .remove(). * New drivers are supposed to implement .remove(). Once all drivers are * converted to not use .remove_new any more, it will be dropped. */This was just a tree-wide 'sed' script that replaced '.remove_new' with'.remove', with some care taken to turn a subsequent tab into two tabsto make things line up.I did do some minimal manual whitespace adjustment for places that usedspaces to line things up.Then I just removed the old (sic) .remove_new member function, and thisis the end result. No more unnecessary conversion noise.Signed-off-by: Linus Torvalds <[email protected]>
show more ...
virt: efi_secret: Convert to platform remove callback returning voidThe .remove() callback for a platform driver returns an int which makesmany driver authors wrongly assume it's possible to do er
virt: efi_secret: Convert to platform remove callback returning voidThe .remove() callback for a platform driver returns an int which makesmany driver authors wrongly assume it's possible to do error handling byreturning an error code. However the value returned is ignored (apartfrom emitting a warning) and this typically results in resource leaks.To improve here there is a quest to make the remove callback returnvoid. In the first step of this quest all drivers are converted to.remove_new(), which already returns void. Eventually after all driversare converted, .remove_new() will be renamed to .remove().Trivially convert this driver from always returning zero in the removecallback to the void returning variant.Signed-off-by: Uwe Kleine-König <[email protected]>Signed-off-by: Ard Biesheuvel <[email protected]>
virt: Add efi_secret module to expose confidential computing secretsThe new efi_secret module exposes the confidential computing (coco)EFI secret area via securityfs interface.When the module is
virt: Add efi_secret module to expose confidential computing secretsThe new efi_secret module exposes the confidential computing (coco)EFI secret area via securityfs interface.When the module is loaded (and securityfs is mounted, typically under/sys/kernel/security), a "secrets/coco" directory is created insecurityfs. In it, a file is created for each secret entry. The nameof each such file is the GUID of the secret entry, and its content isthe secret data.This allows applications running in a confidential computing setting toread secrets provided by the guest owner via a secure secret injectionmechanism (such as AMD SEV's LAUNCH_SECRET command).Removing (unlinking) files in the "secrets/coco" directory will zero outthe secret in memory, and remove the filesystem entry. If the module isremoved and loaded again, that secret will not appear in the filesystem.Signed-off-by: Dov Murik <[email protected]>Reviewed-by: Gerd Hoffmann <[email protected]>Link: https://lore.kernel.org/r/[email protected]Signed-off-by: Ard Biesheuvel <[email protected]>