grub-devel.gnu.org archive mirror
 help / color / mirror / Atom feed
From: Ross Philipson <ross.philipson@oracle.com>
To: Daniel Kiper <daniel.kiper@oracle.com>, grub-devel@gnu.org
Cc: dpsmith.dev@gmail.com, eric.snowberg@oracle.com,
	javierm@redhat.com, jonmccune@google.com,
	kanth.ghatraju@oracle.com, keng-yu.lin@hpe.com,
	konrad.wilk@oracle.com, leif.lindholm@linaro.org,
	mjg59@srcf.ucam.org,  phcoder@gmail.com,
	philip.b.tricca@intel.com
Subject: Re: [PATCH v3 4/8] verifiers: Add possibility to defer verification to other verifiers
Date: Fri, 5 Oct 2018 12:09:43 -0400	[thread overview]
Message-ID: <d3d2f8e2-7660-c3fa-45a5-48e1266e52a5@oracle.com> (raw)
In-Reply-To: <1538559415-6233-5-git-send-email-daniel.kiper@oracle.com>

On 10/03/2018 05:36 AM, Daniel Kiper wrote:
> This way if a verifier requires verification of a given file it can
> defer task to other verifier if it is not able to do it itself. E.g.
> shim_lock verifier, posted as a subsequent patch, is able to verify
> only PE files. This means that it is not able to verify any of GRUB2
> modules which have to be trusted on UEFI systems with secure boot
> enabled. So, it can defer verification to other verifier, e.g. PGP one.
> 
> I silently assume that other verifiers are trusted and will do good
> job for us. Or at least they will not do any harm.
> 
> Signed-off-by: Daniel Kiper <daniel.kiper@oracle.com>
> ---
>  grub-core/commands/verify_helper.c |   23 ++++++++++++++++++++---
>  include/grub/verify.h              |    3 ++-
>  2 files changed, 22 insertions(+), 4 deletions(-)
> 
> diff --git a/grub-core/commands/verify_helper.c b/grub-core/commands/verify_helper.c
> index 7effc5f..ba8b03d 100644
> --- a/grub-core/commands/verify_helper.c
> +++ b/grub-core/commands/verify_helper.c
> @@ -83,6 +83,7 @@ grub_verify_helper_open (grub_file_t io, enum grub_file_type type)
>    void *context;
>    grub_file_t ret = 0;
>    grub_err_t err;
> +  int defer = 0;
>  
>    grub_dprintf ("verify", "file: %s type: %d\n", io->name, type);
>  
> @@ -102,13 +103,27 @@ grub_verify_helper_open (grub_file_t io, enum grub_file_type type)
>        err = ver->init (io, type, &context, &flags);
>        if (err)
>  	goto fail_noclose;
> +      if (flags & GRUB_VERIFY_FLAGS_DEFER)
> +	{
> +	  defer = 1;
> +	  continue;
> +	}
>        if (!(flags & GRUB_VERIFY_FLAGS_SKIP_VERIFICATION))
>  	break;
>      }
>  
>    if (!ver)
> -    /* No verifiers wanted to verify. Just return underlying file.  */
> -    return io;
> +    {
> +      if (defer)
> +	{
> +	  grub_error (GRUB_ERR_ACCESS_DENIED,
> +		      N_("verification requested but nobody cares: %s"), io->name);
> +	  goto fail_noclose;
> +	}

I don't really understand the logic here. Is the idea that if it was
deferred and no one in the chain verified it, it ends up being an error?
Why is that?

Also defer has different meanings. I think in this context it means
defer verification to another authority as opposed to defer until later.

> +
> +      /* No verifiers wanted to verify. Just return underlying file. */
> +      return io;
> +    }
>  
>    ret = grub_malloc (sizeof (*ret));
>    if (!ret)
> @@ -160,7 +175,9 @@ grub_verify_helper_open (grub_file_t io, enum grub_file_type type)
>        err = ver->init (io, type, &context, &flags);
>        if (err)
>  	goto fail_noclose;
> -      if (flags & GRUB_VERIFY_FLAGS_SKIP_VERIFICATION)
> +      if (flags & GRUB_VERIFY_FLAGS_SKIP_VERIFICATION ||
> +	  /* Verification done earlier. So, we are happy here. */
> +	  flags & GRUB_VERIFY_FLAGS_DEFER)
>  	continue;
>        err = ver->write (context, verified->buf, ret->size);
>        if (err)
> diff --git a/include/grub/verify.h b/include/grub/verify.h
> index 9f892d8..c385e3d 100644
> --- a/include/grub/verify.h
> +++ b/include/grub/verify.h
> @@ -22,7 +22,8 @@
>  enum grub_verify_flags
>    {
>      GRUB_VERIFY_FLAGS_SKIP_VERIFICATION	= 1,
> -    GRUB_VERIFY_FLAGS_SINGLE_CHUNK	= 2
> +    GRUB_VERIFY_FLAGS_SINGLE_CHUNK	= 2,
> +    GRUB_VERIFY_FLAGS_DEFER		= 4

What is the difference between skip verification and defer?

>    };
>  
>  enum grub_verify_string_type
> 



  reply	other threads:[~2018-10-05 16:10 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-10-03  9:36 [PATCH v3 0/8] verifiers: Framework and EFI shim lock verifier Daniel Kiper
2018-10-03  9:36 ` [PATCH v3 1/8] verifiers: File type for fine-grained signature-verification controlling Daniel Kiper
2018-10-03 17:33   ` Ross Philipson
2018-10-09 13:43     ` Daniel Kiper
2018-10-03  9:36 ` [PATCH v3 2/8] verifiers: Framework core Daniel Kiper
2018-10-03 17:55   ` Ross Philipson
2018-10-09 13:48     ` Daniel Kiper
2018-10-03  9:36 ` [PATCH v3 3/8] verifiers: Add possibility to verify kernel and modules command lines Daniel Kiper
2018-10-03  9:36 ` [PATCH v3 4/8] verifiers: Add possibility to defer verification to other verifiers Daniel Kiper
2018-10-05 16:09   ` Ross Philipson [this message]
2018-10-09 13:57     ` Daniel Kiper
2018-10-03  9:36 ` [PATCH v3 5/8] verifiers: Rename verify module to pgp module Daniel Kiper
2018-10-05 16:24   ` Ross Philipson
2018-10-09 14:11     ` Daniel Kiper
2018-10-09 14:17       ` Michel Hermier
2018-10-09 14:20         ` Michel Hermier
2018-10-09 14:44           ` Ross Philipson
2018-10-09 15:06       ` Konrad Rzeszutek Wilk
2018-10-03  9:36 ` [PATCH v3 6/8] verifiers: Add the documentation Daniel Kiper
2018-10-05 16:43   ` Ross Philipson
2018-10-09 14:26     ` Daniel Kiper
2018-10-09 14:46       ` Ross Philipson
2018-10-09 14:59   ` Ross Philipson
2018-10-03  9:36 ` [PATCH v3 7/8] dl: Add support for persistent modules Daniel Kiper
2018-10-03  9:36 ` [PATCH v3 8/8] efi: Add EFI shim lock verifier Daniel Kiper

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=d3d2f8e2-7660-c3fa-45a5-48e1266e52a5@oracle.com \
    --to=ross.philipson@oracle.com \
    --cc=daniel.kiper@oracle.com \
    --cc=dpsmith.dev@gmail.com \
    --cc=eric.snowberg@oracle.com \
    --cc=grub-devel@gnu.org \
    --cc=javierm@redhat.com \
    --cc=jonmccune@google.com \
    --cc=kanth.ghatraju@oracle.com \
    --cc=keng-yu.lin@hpe.com \
    --cc=konrad.wilk@oracle.com \
    --cc=leif.lindholm@linaro.org \
    --cc=mjg59@srcf.ucam.org \
    --cc=phcoder@gmail.com \
    --cc=philip.b.tricca@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).