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, 30 Aug 2016 07:52:02 -0500
From:   Christopher Arges <chris.j.arges@...onical.com>
To:     Jiri Kosina <jikos@...nel.org>
Cc:     Petr Mladek <pmladek@...e.com>, live-patching@...r.kernel.org,
        Josh Poimboeuf <jpoimboe@...hat.com>,
        Jessica Yu <jeyu@...hat.com>, Miroslav Benes <mbenes@...e.cz>,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH] livepatch: add load/unload hooks to objects

On Tue, Aug 30, 2016 at 11:41:28AM +0200, Jiri Kosina wrote:
> On Mon, 29 Aug 2016, Christopher Arges wrote:
> 
> > Another example is CVE-2016-2117. Here we need to unset NETIF_F_SG on a 
> > particular device. If the device is already loaded we need a way to 
> > fixup hw_features on an already allocated network device. Again this 
> > could be done in the init code of the patch, but a nicer solution would 
> > be to do this on a load/unload hook appropriately.
> 
> I am afraid this is more complicated than what you describe. You can't 
> just unset NETIF_F_SG and be done with it; look for example what might 
> happen if you clear the flag while skb_segment() is running and gcc is 
> refetching netdev_features_t (there is no READ_ONCE() for that). The same 
> holds for __ip6_append_data().
> I am not saying this can't be worked around, but it's way much more 
> complicated than just clearing a bit in a callback.
> 
> -- 
> Jiri Kosina
> SUSE Labs
>

Jiri,

Yes this example was meant more for showing how something like a load/unload
hook could make patching certain situations easier for a patch author.
Essentially it would be nice to have a place to run code right before patching,
without having to write an additional notifier for module load events.

In this specific example, for safety of setting hw_features perhaps one could
check if a set of functions are on the stacks of any tasks before executing
these hooks. Or ignore any skbs that are already in flight.

--chris

Powered by blists - more mailing lists