On Fri, 2020-11-13 at 13:23 +0000, Dr. David Alan Gilbert wrote:
> * James Bottomley (j...@linux.ibm.com) wrote:
[...]
> > @@ -1117,11 +1151,28 @@ grub_cmd_cryptomount (grub_extcmd_context_t
> > ctxt, int argc, char **args)
> > else if (state[1].set || (argc == 0 && state[2].set))
> > {
> > search_uuid = NULL;
> > + os_passwd = NULL;
> > check_boot = state[2].set;
> > grub_device_iterate (&grub_cryptodisk_scan_device, NULL);
> > search_uuid = NULL;
> > return GRUB_ERR_NONE;
> > }
> > + else if (state[3].set)
> > + {
> > + /* do we have a secret? */
> > + if (os_secret_area == NULL)
> > + return grub_error (GRUB_ERR_INVALID_COMMAND, "No OS secret is
> > provisioned");
> > +
> > + os_passwd = os_secret_area;
> > + search_uuid = NULL;
> > + grub_device_iterate (&grub_cryptodisk_scan_device, NULL);
> > + os_passwd = NULL;
> > +
> > + if (!have_it)
> > + return grub_error (GRUB_ERR_ACCESS_DENIED, "SEV password failed
> > to unlock any volumes");
>
> That's the only place you break the generality and admit to it being
> a SEV password I think.
Yes, I think it reflects the fact that there's likely a missing
callback into the secret setting module so the message can be very
specific and also that module can handle the secret destruction policy.
James
_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
