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:   Wed, 14 Mar 2018 14:32:17 -0500
From:   Josh Poimboeuf <jpoimboe@...hat.com>
To:     Petr Mladek <pmladek@...e.com>
Cc:     Jiri Kosina <jikos@...nel.org>, Miroslav Benes <mbenes@...e.cz>,
        Joe Lawrence <joe.lawrence@...hat.com>,
        Jessica Yu <jeyu@...nel.org>, Nicolai Stange <nstange@...e.de>,
        live-patching@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/2] livepatch: Allow to unregister or free shadow data
 using a custom function

On Tue, Mar 13, 2018 at 04:54:48PM +0100, Petr Mladek wrote:
> We might need to do some actions before the shadow variable is freed.
> For example, we might need to remove it from a list or free some data
> that it points to.
> 
> This is already possible now. The user can get the shadow variable
> by klp_shadow_get(), do the necessary actions, and then call
> klp_shadow_free().
> 
> This patch allow to do this a more elegant way. The user could implement
> the needed actions in a callback that is passed to klp_shadow_free()
> as a parameter. The callback usually does reverse operations to
> the init_func that can be called by klp_shadow_*alloc().
> 
> It is especially useful for klp_shadow_free_all(). There we need to do
> these extra actions for each found shadow variable with the given ID.
> 
> Note that the memory used by the shadow variable itself is still released
> later by rcu callback. It is needed to protect internal structures that
> keep all shadow variables. But free_func is called immediately. The shadow
> variable must not be access anyway after klp_shadow_free() is called.
> The user is responsible to protect this any suitable way.
> 
> Be aware that free_func callback is called under klp_shadow_lock. It is
> the same as for init_func in klp_shadow_alloc().
> 
> Signed-off-by: Petr Mladek <pmladek@...e.com>

Makes sense, though I'm not sure "free" is the right name:

  a) "free" isn't the opposite of "init"; and

  b) it may be used for things other than freeing.
  
Shall we call them constructor/destructor?

-- 
Josh

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ