All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mimi Zohar <zohar@linux.ibm.com>
To: Lakshmi Ramasubramanian <nramas@linux.microsoft.com>,
	James Bottomley <James.Bottomley@HansenPartnership.com>,
	linux-integrity@vger.kernel.org
Cc: sashal@kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] IMA: Turn IMA_MEASURE_ASYMMETRIC_KEYS off by default
Date: Wed, 22 Jan 2020 15:02:59 -0500	[thread overview]
Message-ID: <1579723379.5182.130.camel@linux.ibm.com> (raw)
In-Reply-To: <ac6c559e-2d68-afcb-d316-6ac49a570831@linux.microsoft.com>

On Tue, 2020-01-21 at 12:38 -0800, Lakshmi Ramasubramanian wrote:
> On 1/21/2020 11:52 AM, James Bottomley wrote:
> 
> >> - really small devices/sensors being able to queue certificates
> > 
> > seems like the answer to this one would be don't queue.  I realise it's
> > after the submit design, but what about measuring when the key is added
> > if there's a policy otherwise measure the keyring when the policy is
> > added ... that way no queueing.
> 
> Without the "deferred key processing" changes, only keys added at 
> runtime were measured (if policy permitted).
> 
> "deferred key processing" enabled queuing keys added early in the boot 
> process and measured them when the policy is loaded.
> 
> We can make this (the queuing) optional through a config, but leave the 
> runtime key measurement auto-enabled (as is the config 
> IMA_MEASURE_ASYMMETRIC_KEYS now).

Thanks, Lakshmi.  This requires moving the code around.  Instead of
doing this on the current code base, I suggest posting a v9 version of
the entire "IMA: Deferred measurement of keys".

I suggest making the switch from spinlock to mutex, as you had it
originally, before posting v9.  The commit history will then be a lot
cleaner.

thanks,

Mimi


  reply	other threads:[~2020-01-22 20:03 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-01-21 17:13 [PATCH] IMA: Turn IMA_MEASURE_ASYMMETRIC_KEYS off by default Lakshmi Ramasubramanian
2020-01-21 17:34 ` James Bottomley
2020-01-21 18:00   ` Lakshmi Ramasubramanian
2020-01-21 19:13   ` Mimi Zohar
2020-01-21 19:52     ` James Bottomley
2020-01-21 20:38       ` Lakshmi Ramasubramanian
2020-01-22 20:02         ` Mimi Zohar [this message]
2020-01-22 20:05           ` Lakshmi Ramasubramanian
2020-01-22 20:54             ` Mimi Zohar
2020-01-22 12:23       ` Mimi Zohar

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=1579723379.5182.130.camel@linux.ibm.com \
    --to=zohar@linux.ibm.com \
    --cc=James.Bottomley@HansenPartnership.com \
    --cc=linux-integrity@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=nramas@linux.microsoft.com \
    --cc=sashal@kernel.org \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.