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]
Date:	Tue, 14 Apr 2015 08:48:11 +0800
From:	Minfei Huang <minfei.huang@...mail.com>
To:	Josh Poimboeuf <jpoimboe@...hat.com>
CC:	Petr Mladek <pmladek@...e.cz>, sjenning@...hat.com,
	jkosina@...e.cz, vojtech@...e.cz, live-patching@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH 1/2] livepatch: Add a new function to verify the address
 and name match for extra module

On 04/14/15 at 08:17P, Minfei Huang wrote:
> On 04/13/15 at 05:58P, Josh Poimboeuf wrote:
> > On Mon, Apr 13, 2015 at 06:37:10PM +0800, Minfei Huang wrote:
> > > For my patches, I think it is used by the persion which will compose the
> > > patch individually, not for the manufactor. 
> > > 
> > > Yes, Verifying extra function address is more useless in general, due to
> > > the changable address on different system.
> > > 
> > > IMO, we shall do our best to make livepatch more robust.
> > 
> > IIUC, to use this, you'd have to load the module first, manually look up
> > the module function's address, and _then_ build the patch for the
> > running system.  And the resulting patch wouldn't work on other systems.
> > 
> > Do you have concrete plans to use it this way?
> > 
> > Just trying to understand if this is needed for a real world usage
> > scenario.
> 
> For some companies(like cloud computing company), they will compose
> their own module to improve the performance.
> 
> Once there is some bug for the own module, they cannt restart to reload
> the fixed-module. So it seems that livepatch is the best way to fix this
> issue.
> 
> Before livepatch being integrated in kernel, we usually use ksplice to
> patch the patch.
> 
> What the above scenario I met is in my previous work. 
> 
> For now, livepatch cannt patch the patch for extra module, once the
> function name is larger than 127.
> 

Also, Maybe there is some day, we can use script to detect the function
name and address in userspace, then generate the patch to patch the
defective kernel or extra module.

So the people who want to use livepatch never concern how to compose the
patch to patch the kernel or extra module by using livepatch. All they
will do is to provide a common patch which is different with the
original code.

Thanks
Minfei

> 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