lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150723040206.GA18136@dhcp-128-25.nay.redhat.com>
Date:	Thu, 23 Jul 2015 12:02:06 +0800
From:	Minfei Huang <mhuang@...hat.com>
To:	Josh Poimboeuf <jpoimboe@...hat.com>
Cc:	sjenning@...hat.com, jkosina@...e.cz, vojtech@...e.cz,
	live-patching@...r.kernel.org, linux-kernel@...r.kernel.org,
	Minfei Huang <mnfhuang@...il.com>
Subject: Re: [PATCH] livepatch: Fix the issue to make livepatch
 enable/disable patch correctly

On 07/22/15 at 09:40am, Josh Poimboeuf wrote:
> On Wed, Jul 15, 2015 at 04:55:06PM +0800, Minfei Huang wrote:
> > From: Minfei Huang <mnfhuang@...il.com>
> > 
> > Livepatch will obey the stacking rule to enable/disable the patch. It
> > only allows to enable the patch, when it is the fist disabled patch,
> > disable the patch, when it is the last enabled patch.
> > 
> > In the livepatch code, it uses list to gather the all of the patches.
> > And we do not know whether the previous/next patch is patched to the
> > same modules or vmlinux in that way.
> > 
> > According to above rule, livepatch will make incorrect decision to
> > enable/disable the patch. Following is an example to show how livepatch
> > does.
> > 
> > - install the livepatch example module which is in samples/livepatch.
> > - install the third part kernel module
> > - install the livepatch module which is patched to the third part module
> > - disable the livepatch example module
> > 
> > We can find that we can not disable livepatch example module, although
> > it is the last enabled patch.
> > 
> > To fix this issue, we will find the corresponding patch which is patched
> > to the same modules or vmlinux, when we enable/disable the patch.
> 
> Is it really safe to assume that there are no dependencies between
> patches which patch different objects?
> 

I think so.

It is weird that there are denpendencies which are different objects in
different patches. To apply this patch, we can make livepatch more
flexible to manage the patch.

Thanks
Minfei

> -- 
> Josh
--
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ