[Ksummit-discuss] [CORE TOPIC] [TECH TOPIC] live kernel patching

[Ksummit-discuss] [CORE TOPIC] [TECH TOPIC] live kernel patching

[Jiri Kosina]

Runtime/live kernel patching is becoming a topic these days. There are 
several parallel implementations currently evolving in parallel (kpatch, 
kgraft, criu-based solution, ksplice to some extent), all of them having 
their pros and cons. 

It's clear that what is going to get merged at the end of the day would 
have to be some super-position of the currently existing solutions. 

Finding a reasonable compromise might be challenging. Having discussion 
between the groups working on those solutions (tech topic) and with 
"general maintainer audience" to face the flame^W^W^Wobtain feedback 
(core topic) would be very valuable step in converging to unified 
solution.

Suggested participants: see the list of "competing" projects above

-- 
Jiri Kosina
SUSE Labs

Re: [Ksummit-discuss] [CORE TOPIC] [TECH TOPIC] live kernel patching

[James Bottomley]

On Fri, 2014-05-02 at 21:42 +0200, Jiri Kosina wrote:
> Runtime/live kernel patching is becoming a topic these days. There are 
> several parallel implementations currently evolving in parallel (kpatch, 
> kgraft, criu-based solution, ksplice to some extent), all of them having 
> their pros and cons. 
> 
> It's clear that what is going to get merged at the end of the day would 
> have to be some super-position of the currently existing solutions. 
> 
> Finding a reasonable compromise might be challenging. Having discussion 
> between the groups working on those solutions (tech topic) and with 
> "general maintainer audience" to face the flame^W^W^Wobtain feedback 
> (core topic) would be very valuable step in converging to unified 
> solution.
> 
> Suggested participants: see the list of "competing" projects above

I can certainly dig up people on our CRIU team to discuss this if
there's interest.  I'm obviously biased, but in the interest of full
disclosure, the CRIU solution (our commercial product is called
"rebootless updates") isn't really a "patch" solution per se.  The end
result is a new kernel not a patched old kernel and we can update major
kernel versions.

Our big pro is that you don't have to generate patch files (this is what
sold it to us in the first place, since we did scope producing our own
ksplice patches) and that we can upgrade from any version to any
version.  Our big Con is that while we call the technology "rebootless"
there's a small hiatus when we complete the CRIU checkpoint, kexec to
the new kernel and resume the system.

James

Re: [Ksummit-discuss] [CORE TOPIC] [TECH TOPIC] live kernel patching

[Li Zefan]

On 2014/5/3 3:42, Jiri Kosina wrote:
> Runtime/live kernel patching is becoming a topic these days. There are 
> several parallel implementations currently evolving in parallel (kpatch, 
> kgraft, criu-based solution, ksplice to some extent), all of them having 
> their pros and cons. 
> 
> It's clear that what is going to get merged at the end of the day would 
> have to be some super-position of the currently existing solutions. 
> 
> Finding a reasonable compromise might be challenging. Having discussion 
> between the groups working on those solutions (tech topic) and with 
> "general maintainer audience" to face the flame^W^W^Wobtain feedback 
> (core topic) would be very valuable step in converging to unified 
> solution.
> 
> Suggested participants: see the list of "competing" projects above
> 

Thanks for working on KGraft!

In Huawei we want to use live patching, but we're conservative, so we really
want to see a mainline solution.

Re: [Ksummit-discuss] [CORE TOPIC] [TECH TOPIC] live kernel patching

[Chris Mason]

On 05/02/2014 03:42 PM, Jiri Kosina wrote:
> Runtime/live kernel patching is becoming a topic these days. There are
> several parallel implementations currently evolving in parallel (kpatch,
> kgraft, criu-based solution, ksplice to some extent), all of them having
> their pros and cons.
>
> It's clear that what is going to get merged at the end of the day would
> have to be some super-position of the currently existing solutions.
>
> Finding a reasonable compromise might be challenging. Having discussion
> between the groups working on those solutions (tech topic) and with
> "general maintainer audience" to face the flame^W^W^Wobtain feedback
> (core topic) would be very valuable step in converging to unified
> solution.
>
> Suggested participants: see the list of "competing" projects above
>

Tons of interest in this topic here, mostly for the in-memory database 
workloads.

-chris

Re: [Ksummit-discuss] [CORE TOPIC] [TECH TOPIC] live kernel patching

[Andy Lutomirski]

On Mon, May 5, 2014 at 7:00 AM, Chris Mason <clm@fb.com> wrote:
> On 05/02/2014 03:42 PM, Jiri Kosina wrote:
>>
>> Runtime/live kernel patching is becoming a topic these days. There are
>> several parallel implementations currently evolving in parallel (kpatch,
>> kgraft, criu-based solution, ksplice to some extent), all of them having
>> their pros and cons.
>>
>> It's clear that what is going to get merged at the end of the day would
>> have to be some super-position of the currently existing solutions.
>>
>> Finding a reasonable compromise might be challenging. Having discussion
>> between the groups working on those solutions (tech topic) and with
>> "general maintainer audience" to face the flame^W^W^Wobtain feedback
>> (core topic) would be very valuable step in converging to unified
>> solution.
>>
>> Suggested participants: see the list of "competing" projects above
>>
>
> Tons of interest in this topic here, mostly for the in-memory database
> workloads.

Would in-memory databases be happier if there were a way to kexec
without losing your data?

--Andy

Re: [Ksummit-discuss] [CORE TOPIC] [TECH TOPIC] live kernel patching

[Jiri Kosina]

On Mon, 5 May 2014, Andy Lutomirski wrote:

> > Tons of interest in this topic here, mostly for the in-memory database
> > workloads.
> 
> Would in-memory databases be happier if there were a way to kexec
> without losing your data?

Well, that's basicaly what criu-based aproach is doing. With the drawback 
that dumping during checkpointing can take a while for large tasks (such 
as in-memory databases) I guess.

-- 
Jiri Kosina
SUSE Labs

Re: [Ksummit-discuss] [CORE TOPIC] [TECH TOPIC] live kernel patching

[Kees Cook]

On Fri, May 2, 2014 at 12:42 PM, Jiri Kosina <jkosina@suse.cz> wrote:
> Runtime/live kernel patching is becoming a topic these days. There are
> several parallel implementations currently evolving in parallel (kpatch,
> kgraft, criu-based solution, ksplice to some extent), all of them having
> their pros and cons.
>
> It's clear that what is going to get merged at the end of the day would
> have to be some super-position of the currently existing solutions.
>
> Finding a reasonable compromise might be challenging. Having discussion
> between the groups working on those solutions (tech topic) and with
> "general maintainer audience" to face the flame^W^W^Wobtain feedback
> (core topic) would be very valuable step in converging to unified
> solution.
>
> Suggested participants: see the list of "competing" projects above

I'm very interested in this, especially as it may relate to security
exploit mitigation work, both in the sense of being able to
arbitrarily patch the kernel against flaws, and to defend against
attackers being able to ... er ... arbitrarily patch the kernel... :)

-Kees

-- 
Kees Cook
Chrome OS Security

Re: [Ksummit-discuss] [CORE TOPIC] [TECH TOPIC] live kernel patching

[Jiri Kosina]

On Mon, 5 May 2014, Kees Cook wrote:

> I'm very interested in this, especially as it may relate to security 
> exploit mitigation work, both in the sense of being able to arbitrarily 
> patch the kernel against flaws, and to defend against attackers being 
> able to ... er ... arbitrarily patch the kernel... :)

:) Well, for performing the patching, the attacker would either have to be 
able to modprobe module (kpatch, kgraft, ksplice) or kexec to a new kernel 
(criu-based solution). In either case, the system would be owned anyway 
already, independently on any live patching mechanism.

-- 
Jiri Kosina
SUSE Labs

Re: [Ksummit-discuss] [CORE TOPIC] [TECH TOPIC] live kernel patching

[Masami Hiramatsu]

(2014/05/03 4:42), Jiri Kosina wrote:
> Runtime/live kernel patching is becoming a topic these days. There are 
> several parallel implementations currently evolving in parallel (kpatch, 
> kgraft, criu-based solution, ksplice to some extent), all of them having 
> their pros and cons. 
> 
> It's clear that what is going to get merged at the end of the day would 
> have to be some super-position of the currently existing solutions. 
> 
> Finding a reasonable compromise might be challenging. Having discussion 
> between the groups working on those solutions (tech topic) and with 
> "general maintainer audience" to face the flame^W^W^Wobtain feedback 
> (core topic) would be very valuable step in converging to unified 
> solution.
> 
> Suggested participants: see the list of "competing" projects above

I'd like to participate this discussion since I'm helping kpatch :)
Live patching is a desired feature for some mission-critical non-stop
systems.

Thank you,

-- 
Masami HIRAMATSU
Software Platform Research Dept. Linux Technology Research Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu.pt@hitachi.com

Re: [Ksummit-discuss] [CORE TOPIC] [TECH TOPIC] live kernel patching

[Dave Jones]

On Tue, May 06, 2014 at 09:05:53AM +0200, Jiri Kosina wrote:
 > On Mon, 5 May 2014, Kees Cook wrote:
 > 
 > > I'm very interested in this, especially as it may relate to security 
 > > exploit mitigation work, both in the sense of being able to arbitrarily 
 > > patch the kernel against flaws, and to defend against attackers being 
 > > able to ... er ... arbitrarily patch the kernel... :)
 > 
 > :) Well, for performing the patching, the attacker would either have to be 
 > able to modprobe module (kpatch, kgraft, ksplice) or kexec to a new kernel 
 > (criu-based solution). In either case, the system would be owned anyway 
 > already, independently on any live patching mechanism.

being root doesn't mean "can patch the kernel" if in secure boot mode.
(Or at least is going to need special considerations regarding signing).

	Dave

Re: [Ksummit-discuss] [CORE TOPIC] [TECH TOPIC] live kernel patching

[James Bottomley]

On Tue, 2014-05-06 at 00:08 +0200, Jiri Kosina wrote:
> On Mon, 5 May 2014, Andy Lutomirski wrote:
> 
> > > Tons of interest in this topic here, mostly for the in-memory database
> > > workloads.
> > 
> > Would in-memory databases be happier if there were a way to kexec
> > without losing your data?
> 
> Well, that's basicaly what criu-based aproach is doing. With the drawback 
> that dumping during checkpointing can take a while for large tasks (such 
> as in-memory databases) I guess.

Well, no that's not correct.  You've seen the patches for the pramfs
capsule which is not upstream (and probably won't be now we're looking
at doing something similar with splice).  The idea is basically we do a
zero copy checkpoint by passing pages into some type of capsule which
survives the kexec.  The restore then does a zero copy pull pages out of
the capsule and reattach them, so most of the time is really just the
kexec of the new kernel.

James

Re: [Ksummit-discuss] [CORE TOPIC] [TECH TOPIC] live kernel patching

[Kees Cook]

On Tue, May 6, 2014 at 12:05 AM, Jiri Kosina <jkosina@suse.cz> wrote:
> On Mon, 5 May 2014, Kees Cook wrote:
>
>> I'm very interested in this, especially as it may relate to security
>> exploit mitigation work, both in the sense of being able to arbitrarily
>> patch the kernel against flaws, and to defend against attackers being
>> able to ... er ... arbitrarily patch the kernel... :)
>
> :) Well, for performing the patching, the attacker would either have to be
> able to modprobe module (kpatch, kgraft, ksplice) or kexec to a new kernel
> (criu-based solution). In either case, the system would be owned anyway
> already, independently on any live patching mechanism.

Right -- this is the current limitation with this kind of thing. I'd
like to have both arbitrarily module loading blocked and the ability
to load generated modules at a later time. I'm hoping there can be
some discussion around providing a verification process for the newly
created modules (e.g. signing the module on a separate machine that
has private key material, etc).

-Kees

-- 
Kees Cook
Chrome OS Security

Re: [Ksummit-discuss] [CORE TOPIC] [TECH TOPIC] live kernel patching

[Pavel Emelyanov]

On 05/06/2014 02:08 AM, Jiri Kosina wrote:
> On Mon, 5 May 2014, Andy Lutomirski wrote:
> 
>>> Tons of interest in this topic here, mostly for the in-memory database
>>> workloads.
>>
>> Would in-memory databases be happier if there were a way to kexec
>> without losing your data?
> 
> Well, that's basicaly what criu-based aproach is doing. With the drawback 
> that dumping during checkpointing can take a while for large tasks (such 
> as in-memory databases) I guess.

It does takes a while, but not when there's a lot of memory mapped by tasks.
This is what "preserving memory in place over kexec" is needed for -- we keep
all tasks' memory in memory, thus avoiding long delays due to writing it on
disk into images. Such thing performs poorly when there's a lot of _dirty_
memory hanging around.

Thanks,
Pavel

Re: [Ksummit-discuss] [CORE TOPIC] [TECH TOPIC] live kernel patching

[Jiri Kosina]

On Tue, 6 May 2014, Dave Jones wrote:

>  > > I'm very interested in this, especially as it may relate to security 
>  > > exploit mitigation work, both in the sense of being able to arbitrarily 
>  > > patch the kernel against flaws, and to defend against attackers being 
>  > > able to ... er ... arbitrarily patch the kernel... :)
>  > 
>  > :) Well, for performing the patching, the attacker would either have to be 
>  > able to modprobe module (kpatch, kgraft, ksplice) or kexec to a new kernel 
>  > (criu-based solution). In either case, the system would be owned anyway 
>  > already, independently on any live patching mechanism.
> 
> being root doesn't mean "can patch the kernel" if in secure boot mode.
> (Or at least is going to need special considerations regarding signing).

This is not about root, this is about "being able to load modules" 
implying "being able to patch the kernel", both in and outside secure boot 
model, so this is a non-issue.

-- 
Jiri Kosina
SUSE Labs

Re: [Ksummit-discuss] [CORE TOPIC] [TECH TOPIC] live kernel patching

[James Bottomley]

On Tue, 2014-05-06 at 06:18 -0700, Kees Cook wrote:
> On Tue, May 6, 2014 at 12:05 AM, Jiri Kosina <jkosina@suse.cz> wrote:
> > On Mon, 5 May 2014, Kees Cook wrote:
> >
> >> I'm very interested in this, especially as it may relate to security
> >> exploit mitigation work, both in the sense of being able to arbitrarily
> >> patch the kernel against flaws, and to defend against attackers being
> >> able to ... er ... arbitrarily patch the kernel... :)
> >
> > :) Well, for performing the patching, the attacker would either have to be
> > able to modprobe module (kpatch, kgraft, ksplice) or kexec to a new kernel
> > (criu-based solution). In either case, the system would be owned anyway
> > already, independently on any live patching mechanism.
> 
> Right -- this is the current limitation with this kind of thing. I'd
> like to have both arbitrarily module loading blocked and the ability
> to load generated modules at a later time. I'm hoping there can be
> some discussion around providing a verification process for the newly
> created modules (e.g. signing the module on a separate machine that
> has private key material, etc).

This really belongs to the Secure Boot discussion not the live kernel
patching one ...

As you know, the problem has always been third party modules (what you
call "generated modules at a later time").  It's not really technical,
it's political: how do you arrive at the trusted key public key?  The
distros didn't want to be in the business of signing modules (or keys).
The Red Hat kernel generation process even destroys the in-kernel key,
so it can't be used to sign them (although a validated RH key with trust
rooted somewhere in the secure boot system could).  We've seen a lot of
"interesting" suggestions in this regard, like packaging the module up
into a windows like binary and getting Microsoft to sign it.  At the end
of the day, I think we need a gpg like trust model: the distros all
assign public trust to vendor keys and the administrator has to decide
whether they want to install that vendor key based on the computed trust
from all the distros (so no signing, just assignment of trust).

James

Re: [Ksummit-discuss] [CORE TOPIC] [TECH TOPIC] live kernel patching

[Kees Cook]

On Tue, May 6, 2014 at 6:28 AM, James Bottomley
<James.Bottomley@hansenpartnership.com> wrote:
> On Tue, 2014-05-06 at 06:18 -0700, Kees Cook wrote:
>> On Tue, May 6, 2014 at 12:05 AM, Jiri Kosina <jkosina@suse.cz> wrote:
>> > On Mon, 5 May 2014, Kees Cook wrote:
>> >
>> >> I'm very interested in this, especially as it may relate to security
>> >> exploit mitigation work, both in the sense of being able to arbitrarily
>> >> patch the kernel against flaws, and to defend against attackers being
>> >> able to ... er ... arbitrarily patch the kernel... :)
>> >
>> > :) Well, for performing the patching, the attacker would either have to be
>> > able to modprobe module (kpatch, kgraft, ksplice) or kexec to a new kernel
>> > (criu-based solution). In either case, the system would be owned anyway
>> > already, independently on any live patching mechanism.
>>
>> Right -- this is the current limitation with this kind of thing. I'd
>> like to have both arbitrarily module loading blocked and the ability
>> to load generated modules at a later time. I'm hoping there can be
>> some discussion around providing a verification process for the newly
>> created modules (e.g. signing the module on a separate machine that
>> has private key material, etc).
>
> This really belongs to the Secure Boot discussion not the live kernel
> patching one ...
>
> As you know, the problem has always been third party modules (what you
> call "generated modules at a later time").  It's not really technical,
> it's political: how do you arrive at the trusted key public key?  The
> distros didn't want to be in the business of signing modules (or keys).
> The Red Hat kernel generation process even destroys the in-kernel key,
> so it can't be used to sign them (although a validated RH key with trust
> rooted somewhere in the secure boot system could).  We've seen a lot of
> "interesting" suggestions in this regard, like packaging the module up
> into a windows like binary and getting Microsoft to sign it.  At the end
> of the day, I think we need a gpg like trust model: the distros all
> assign public trust to vendor keys and the administrator has to decide
> whether they want to install that vendor key based on the computed trust
> from all the distros (so no signing, just assignment of trust).

I'd like to be careful to avoid UEFI-specific thinking when dealing
with this. Module verification can also be done without signatures
(e.g. using the LSM to make sure they load from a read-only device).
Extending this so that a device with a known-good kernel environment
(be it UEFI Secure Boot, Chrome OS verified mode, or booting from a
CD-ROM) can extend itself with generated modules that the system owner
trusts in some additional way. (This is likely just adding a key for
module signing, but there's more to discuss: I don't want to have to
have ALL modules signed, for example, if I can already trust the
location where kernel-build-time modules are being loaded from, etc.)

-Kees

-- 
Kees Cook
Chrome OS Security

Re: [Ksummit-discuss] [CORE TOPIC] [TECH TOPIC] live kernel patching

[Chris Mason]

On 05/05/2014 05:58 PM, Andy Lutomirski wrote:
> On Mon, May 5, 2014 at 7:00 AM, Chris Mason <clm@fb.com> wrote:
>> On 05/02/2014 03:42 PM, Jiri Kosina wrote:
>>>
>>> Runtime/live kernel patching is becoming a topic these days. There are
>>> several parallel implementations currently evolving in parallel (kpatch,
>>> kgraft, criu-based solution, ksplice to some extent), all of them having
>>> their pros and cons.
>>>
>>> It's clear that what is going to get merged at the end of the day would
>>> have to be some super-position of the currently existing solutions.
>>>
>>> Finding a reasonable compromise might be challenging. Having discussion
>>> between the groups working on those solutions (tech topic) and with
>>> "general maintainer audience" to face the flame^W^W^Wobtain feedback
>>> (core topic) would be very valuable step in converging to unified
>>> solution.
>>>
>>> Suggested participants: see the list of "competing" projects above
>>>
>>
>> Tons of interest in this topic here, mostly for the in-memory database
>> workloads.
>
> Would in-memory databases be happier if there were a way to kexec
> without losing your data?

Yes, for these apps we could just define a chunk of ram that was 
supposed to stay the same after kexec and they would be happy.

-chris

Re: [Ksummit-discuss] [CORE TOPIC] [TECH TOPIC] live kernel patching

[Pavel Emelyanov]

On 05/06/2014 06:07 PM, Chris Mason wrote:

>>> Tons of interest in this topic here, mostly for the in-memory database
>>> workloads.
>>
>> Would in-memory databases be happier if there were a way to kexec
>> without losing your data?
> 
> Yes, for these apps we could just define a chunk of ram that was 
> supposed to stay the same after kexec and they would be happy.

+1, I'd be happy to have this as well.

One question about the chunk of memory you want to preserve -- is it anonymous
memory or part of a page cache?

Thanks,
Pavel

Re: [Ksummit-discuss] [CORE TOPIC] [TECH TOPIC] live kernel patching

[Chris Mason]

On 05/06/2014 11:44 AM, Pavel Emelyanov wrote:
> On 05/06/2014 06:07 PM, Chris Mason wrote:
>
>>>> Tons of interest in this topic here, mostly for the in-memory database
>>>> workloads.
>>>
>>> Would in-memory databases be happier if there were a way to kexec
>>> without losing your data?
>>
>> Yes, for these apps we could just define a chunk of ram that was
>> supposed to stay the same after kexec and they would be happy.
>
> +1, I'd be happy to have this as well.
>
> One question about the chunk of memory you want to preserve -- is it anonymous
> memory or part of a page cache?

We have plain old memcached, and other fancier stuff is that is page 
cache based.  I think for memcached they've set it up to use shm so app 
restarts don't toss the ram.

-chris

Re: [Ksummit-discuss] [CORE TOPIC] [TECH TOPIC] live kernel patching

[Mimi Zohar]

On Tue, 2014-05-06 at 06:41 -0700, Kees Cook wrote: 
> On Tue, May 6, 2014 at 6:28 AM, James Bottomley
> <James.Bottomley@hansenpartnership.com> wrote:
> > On Tue, 2014-05-06 at 06:18 -0700, Kees Cook wrote:
> >> On Tue, May 6, 2014 at 12:05 AM, Jiri Kosina <jkosina@suse.cz> wrote:
> >> > On Mon, 5 May 2014, Kees Cook wrote:
> >> >
> >> >> I'm very interested in this, especially as it may relate to security
> >> >> exploit mitigation work, both in the sense of being able to arbitrarily
> >> >> patch the kernel against flaws, and to defend against attackers being
> >> >> able to ... er ... arbitrarily patch the kernel... :)
> >> >
> >> > :) Well, for performing the patching, the attacker would either have to be
> >> > able to modprobe module (kpatch, kgraft, ksplice) or kexec to a new kernel
> >> > (criu-based solution). In either case, the system would be owned anyway
> >> > already, independently on any live patching mechanism.
> >>
> >> Right -- this is the current limitation with this kind of thing. I'd
> >> like to have both arbitrarily module loading blocked and the ability
> >> to load generated modules at a later time. I'm hoping there can be
> >> some discussion around providing a verification process for the newly
> >> created modules (e.g. signing the module on a separate machine that
> >> has private key material, etc).
> >
> > This really belongs to the Secure Boot discussion not the live kernel
> > patching one ...

Anything that is added to the linux kernel needs to be measured and
appraised, before being applied.  Making sure there is a hook that does
this for live kernel patching is important. 

> > As you know, the problem has always been third party modules (what you
> > call "generated modules at a later time").  It's not really technical,
> > it's political: how do you arrive at the trusted key public key?  The
> > distros didn't want to be in the business of signing modules (or keys).
> > The Red Hat kernel generation process even destroys the in-kernel key,
> > so it can't be used to sign them (although a validated RH key with trust
> > rooted somewhere in the secure boot system could).  We've seen a lot of
> > "interesting" suggestions in this regard, like packaging the module up
> > into a windows like binary and getting Microsoft to sign it.  At the end
> > of the day, I think we need a gpg like trust model: the distros all
> > assign public trust to vendor keys and the administrator has to decide
> > whether they want to install that vendor key based on the computed trust
> > from all the distros (so no signing, just assignment of trust).

We're currently working on adding file signatures to packages (eg. rpm,
deb).  Assuming packages come signed, we would only need to load the
associated public key on a trusted _ima keyring (trusted _ima keyring
needs to be upstreamed).  The system owner would decide which 3rd public
keys they want to trust.  IMA-appraisal would enforce file integrity.

> I'd like to be careful to avoid UEFI-specific thinking when dealing
> with this. Module verification can also be done without signatures
> (e.g. using the LSM to make sure they load from a read-only device).
> Extending this so that a device with a known-good kernel environment
> (be it UEFI Secure Boot, Chrome OS verified mode, or booting from a
> CD-ROM) can extend itself with generated modules that the system owner
> trusts in some additional way. (This is likely just adding a key for
> module signing, but there's more to discuss: I don't want to have to
> have ALL modules signed, for example, if I can already trust the
> location where kernel-build-time modules are being loaded from, etc.)

IMA-apppraisal verifies file integrity based on policy.  You could
prevent files being appraised based on fsuuid.

dont_appraise func=BPRM_CHECK fsuuid=38b7a203-6763-4563-b1f8-4c1f557dc54f
appraise func=BPRM_CHECK fowner=0 appraise_type=imasig

thanks,

Mimi

Re: [Ksummit-discuss] [CORE TOPIC] [TECH TOPIC] live kernel patching

[James Bottomley]

On Tue, 2014-05-06 at 06:41 -0700, Kees Cook wrote:
> On Tue, May 6, 2014 at 6:28 AM, James Bottomley
> <James.Bottomley@hansenpartnership.com> wrote:
> > On Tue, 2014-05-06 at 06:18 -0700, Kees Cook wrote:
> >> On Tue, May 6, 2014 at 12:05 AM, Jiri Kosina <jkosina@suse.cz> wrote:
> >> > On Mon, 5 May 2014, Kees Cook wrote:
> >> >
> >> >> I'm very interested in this, especially as it may relate to security
> >> >> exploit mitigation work, both in the sense of being able to arbitrarily
> >> >> patch the kernel against flaws, and to defend against attackers being
> >> >> able to ... er ... arbitrarily patch the kernel... :)
> >> >
> >> > :) Well, for performing the patching, the attacker would either have to be
> >> > able to modprobe module (kpatch, kgraft, ksplice) or kexec to a new kernel
> >> > (criu-based solution). In either case, the system would be owned anyway
> >> > already, independently on any live patching mechanism.
> >>
> >> Right -- this is the current limitation with this kind of thing. I'd
> >> like to have both arbitrarily module loading blocked and the ability
> >> to load generated modules at a later time. I'm hoping there can be
> >> some discussion around providing a verification process for the newly
> >> created modules (e.g. signing the module on a separate machine that
> >> has private key material, etc).
> >
> > This really belongs to the Secure Boot discussion not the live kernel
> > patching one ...
> >
> > As you know, the problem has always been third party modules (what you
> > call "generated modules at a later time").  It's not really technical,
> > it's political: how do you arrive at the trusted key public key?  The
> > distros didn't want to be in the business of signing modules (or keys).
> > The Red Hat kernel generation process even destroys the in-kernel key,
> > so it can't be used to sign them (although a validated RH key with trust
> > rooted somewhere in the secure boot system could).  We've seen a lot of
> > "interesting" suggestions in this regard, like packaging the module up
> > into a windows like binary and getting Microsoft to sign it.  At the end
> > of the day, I think we need a gpg like trust model: the distros all
> > assign public trust to vendor keys and the administrator has to decide
> > whether they want to install that vendor key based on the computed trust
> > from all the distros (so no signing, just assignment of trust).
> 
> I'd like to be careful to avoid UEFI-specific thinking when dealing
> with this. Module verification can also be done without signatures
> (e.g. using the LSM to make sure they load from a read-only device).
> Extending this so that a device with a known-good kernel environment
> (be it UEFI Secure Boot, Chrome OS verified mode, or booting from a
> CD-ROM) can extend itself with generated modules that the system owner
> trusts in some additional way. (This is likely just adding a key for
> module signing, but there's more to discuss: I don't want to have to
> have ALL modules signed, for example, if I can already trust the
> location where kernel-build-time modules are being loaded from, etc.)

I don't believe any of the projects prescribe the security method. For
the patch methods (kgraft, ksplice and kpatch) you just have to be able
to load a module with the patches; for CRIU you have to be able to kexec
the new kernel.  In a secure environment, obviously, either of these
(module load or kexec) is subject to checking.  In the patch projects,
we won't define what that is, we'll just say that's what we need to do.

James