public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: joeyli <jlee@suse.com>
To: Jiri Kosina <jkosina@suse.cz>
Cc: Matthew Garrett <matthew.garrett@nebula.com>,
	"gnomes@lxorguk.ukuu.org.uk" <gnomes@lxorguk.ukuu.org.uk>,
	"keescook@chromium.org" <keescook@chromium.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"james.l.morris@oracle.com" <james.l.morris@oracle.com>,
	"serge@hallyn.com" <serge@hallyn.com>,
	"linux-security-module@vger.kernel.org" 
	<linux-security-module@vger.kernel.org>,
	"hpa@zytor.com" <hpa@zytor.com>
Subject: Re: Trusted kernel patchset
Date: Wed, 18 Mar 2015 21:24:50 +0800	[thread overview]
Message-ID: <20150318132450.GA2370@linux-rxt1.site> (raw)
In-Reply-To: <alpine.LRH.2.00.1503162251400.13021@twin.jikos.cz>

On Mon, Mar 16, 2015 at 10:54:54PM +0100, Jiri Kosina wrote:
> On Mon, 16 Mar 2015, Matthew Garrett wrote:
> 
> > > - All suspend/resumes allow modifying the kernel. I can boot Linux
> > >   suspend, boot windows, modify the Linux restore image, boot Linux and
> > >   own the box. You would need to sign the resume image somehow I think or
> > >   just disable all suspend/resume
> > 
> > I'm kind of torn on this - yes, there are deployment scenarios where
> > hibernation can be used to circumvent the restrictions, but there are
> > also scenarios where that can be avoided (eg, the bootloader verifies
> > some state with respect to the hibernation image).
> 
> [ adding Joey to CC ]
> 
> Just for completness -- there is a way around this:
> 
> 	https://lkml.org/lkml/2013/9/14/183
> 
> The series is not really the optimal one, as Alan Stern later figured out 
> that symmetric cryptography is strong enough to achieve the same goal, but 
> I am not sure whether Joey implemented that idea already.
> 
> -- 
> Jiri Kosina
> SUSE Labs

About the symmetric key edition, I developed a prototype the codes on github
are ugly and still need clear up. But it works for using HMAC to generate
signature and verify hibernate image.

There still has a situation need to solve:
 
There doesn't have enough random entropy for the FIRST TIME boot to generate
HMAC key in EFI stub.

And, I need implement a hash function in EFI stub, at least SHA1, to mess
entropies from difference sources (rdtsc, RdRand... not too many) for generating
new HMAC key. An other idea is sending a random seed from runtime random pool to
boot time to be one of the seed of next HMAC key.


Joey Lee

      reply	other threads:[~2015-03-18 13:25 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-13 21:38 Trusted kernel patchset Matthew Garrett
2015-03-13 21:38 ` [PATCH 01/12] Add support for indicating that the booted kernel is externally trusted Matthew Garrett
2015-03-13 21:38 ` [PATCH 02/12] Enforce module signatures when trusted kernel is enabled Matthew Garrett
2015-03-13 21:38 ` [PATCH 03/12] PCI: Lock down register access when trusted_kernel is true Matthew Garrett
2015-03-13 21:38 ` [PATCH 04/12] x86: Lock down IO port " Matthew Garrett
2015-03-13 21:38 ` [PATCH 05/12] Restrict /dev/mem and /dev/kmem " Matthew Garrett
2015-03-13 21:38 ` [PATCH 06/12] acpi: Limit access to custom_method if " Matthew Garrett
2015-03-13 21:38 ` [PATCH 07/12] acpi: Ignore acpi_rsdp kernel parameter when " Matthew Garrett
2015-03-13 21:38 ` [PATCH 08/12] kexec: Disable loading of unverified images Matthew Garrett
2015-03-13 21:38 ` [PATCH 09/12] uswsusp: Disable when trusted_kernel is true Matthew Garrett
2015-03-16 21:36   ` Kees Cook
2015-03-16 21:40     ` Matthew Garrett
2015-03-13 21:38 ` [PATCH 10/12] x86: Restrict MSR access " Matthew Garrett
2015-03-13 21:38 ` [PATCH 11/12] asus-wmi: Restrict debugfs interface " Matthew Garrett
2015-03-13 21:38 ` [PATCH 12/12] Add option to automatically set trusted_kernel when in Secure Boot mode Matthew Garrett
2015-04-22 11:36   ` Dan Carpenter
2015-03-15  1:53 ` Trusted kernel patchset Matthew Garrett
2015-03-16 14:45 ` One Thousand Gnomes
2015-03-16 18:15   ` Matthew Garrett
2015-03-16 20:07     ` One Thousand Gnomes
2015-03-16 20:35     ` David Lang
2015-03-16 20:57       ` One Thousand Gnomes
2015-03-16 21:11       ` Matthew Garrett
2015-03-16 21:29     ` Kees Cook
2015-03-17 17:48       ` One Thousand Gnomes
2015-03-17 20:22       ` Simon McVittie
2015-03-17 20:42         ` Matthew Garrett
2015-03-18 11:34           ` Simon McVittie
2015-03-16 21:54     ` Jiri Kosina
2015-03-18 13:24       ` joeyli [this message]

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=20150318132450.GA2370@linux-rxt1.site \
    --to=jlee@suse.com \
    --cc=gnomes@lxorguk.ukuu.org.uk \
    --cc=hpa@zytor.com \
    --cc=james.l.morris@oracle.com \
    --cc=jkosina@suse.cz \
    --cc=keescook@chromium.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=matthew.garrett@nebula.com \
    --cc=serge@hallyn.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