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: <8a4711b9-9536-3843-c737-50fab2536aa5@redhat.com>
Date:   Tue, 13 Jun 2017 13:29:31 -0400
From:   Joe Lawrence <joe.lawrence@...hat.com>
To:     Miroslav Benes <mbenes@...e.cz>
Cc:     Jiri Kosina <jikos@...nel.org>, live-patching@...r.kernel.org,
        linux-kernel@...r.kernel.org, Josh Poimboeuf <jpoimboe@...hat.com>,
        Jessica Yu <jeyu@...hat.com>, Petr Mladek <pmladek@...e.com>
Subject: Re: [PATCH 0/3] livepatch: add shadow variable API

On 06/13/2017 06:19 AM, Miroslav Benes wrote:
>> If you are referring to stacking livepatches ... to be honest I hadn't
>> thought of that scenario.  In that case, we might be able to get away
>> with pushing something like this into the hash:
>>
>>  klp #1:  klp_shadow_attach(ptr, "shadow_var", ...)
>>  klp #2:  klp_shadow_attach(ptr, "shadow_var_v2", ...)
> 
> I thought this was the reason to have a string there. Otherwise, a 
> pointer to original data would be enough, wouldn't it?

Well, one could attach multiple shadow variables to the same data
structure, ie, one for each new data element.  In the stacking case, you
might add a spinlock in patch 1, then a linked-list in patch 2.  Patched
codepaths would then use klp_shadow_get(obj, "spinlock") or
klp_shadow_get(obj, "list") as needed.

Versioning shadow variables would be a bit more involved.  You'd have to
figure out if you A) convert existing shadow variables to the new format
on livepatch module load, or B) convert on the fly, or C) handle none,
v1, and v2 instances of the shadow variables.  /head spins

To be honest, I don't think we've never needed anything beyond basic
shadow variables in kpatch, so I'm only speculating about their
potential (ab)uses :)  That said, since this patchset is introducing the
API, it would be good to be reasonably flexible.

-- Joe

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ