[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20130911135137.GC15364@redhat.com>
Date: Wed, 11 Sep 2013 09:51:37 -0400
From: Vivek Goyal <vgoyal@...hat.com>
To: Josh Boyer <jwboyer@...oraproject.org>
Cc: "Linux-Kernel@...r. Kernel. Org" <linux-kernel@...r.kernel.org>,
linux-security-module <linux-security-module@...r.kernel.org>,
kexec <kexec@...ts.infradead.org>,
Andrew Morton <akpm@...ux-foundation.org>,
Mimi Zohar <zohar@...ux.vnet.ibm.com>, d.kasatkin@...sung.com,
"Eric W. Biederman" <ebiederm@...ssion.com>,
"H. Peter Anvin" <hpa@...or.com>,
Matthew Garrett <matthew.garrett@...ula.com>
Subject: Re: [PATCH 14/16] kexec: Export sysfs attributes for secureboot and
secure modules to user space
On Tue, Sep 10, 2013 at 06:57:55PM -0400, Josh Boyer wrote:
[..]
> > +static ssize_t secureboot_enabled_show(struct kobject *kobj,
> > + struct kobj_attribute *attr, char *buf)
> > +{
> > + /* TODO: Change it once secureboot patches are in */
> > + return sprintf(buf, "%d\n", 1);
> > +}
> > +KERNEL_ATTR_RO(secureboot_enabled);
>
> You're defaulting this to enabled, even on machines where SB isn't
> possible. I realize there are TODOs there, but you might want to
> default it to off if you really intend this on going upstream before
> any of the other secure_* infrastructure does.
I defaulted it to 1 because I wanted to artificially simulate that
secureboot is enabled and make sure kexec-tools verifies signature
of bzImage.
This is just an RFC series to show what's cooking and get early feedback
about design. I am not expecting any of this to get in before secureboot/
secure_modules/securelevel patches get in.
First some set of patches need to block kexec loading, only then these
patches make sense.
So don't read too much into current default values. Idea is to show
that kernel will export 1-2 knobs to user space which will signal
kexec-tools to verify signature of bzImage and also set "secureboot"
in bootparams for next kernel as needed.
Thanks
Vivek
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists