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: <20190211140813.z7kap634gz3gp6a4@treble>
Date:   Mon, 11 Feb 2019 08:08:13 -0600
From:   Josh Poimboeuf <jpoimboe@...hat.com>
To:     Kamalesh Babulal <kamalesh@...ux.vnet.ibm.com>
Cc:     live-patching@...r.kernel.org, linux-kernel@...r.kernel.org,
        Miroslav Benes <mbenes@...e.cz>,
        Petr Mladek <pmladek@...e.com>, Jiri Kosina <jikos@...nel.org>
Subject: Re: [PATCH] livepatch: Enforce reliable stack trace as config
 dependency

On Sat, Feb 09, 2019 at 02:47:28PM +0530, Kamalesh Babulal wrote:
> While the consistency model was introduced, architectures without the
> reliable stack trace implementation could use the immediate flag for
> livepatching but with its own limitations.
> 
> After removal of the immediate flag by commit d0807da78e11
> ("livepatch: Remove immediate feature"), reliable stack trace became
> enforcing dependency for livepatch support on any architecture. In
> the current code, we ensure that the dependency is met when
> enabling the patch during the module load.
> 
> This dependency check can be improved by moving it to the Kconfig,
> which disables the support for livepatching in the kernel for unmet
> dependencies. This patch moves both HAVE_RELIABLE_STACKTRACE and
> STACKTRACE under config LIVEPATCH, it also removes the
> klp_have_reliable_stack() function.
> 
> Loading a livepatching module on an architecture where reliable
> stack trace is yet to be implemented, the user should see:
> 
> insmod: ERROR: could not insert module ./livepatch-sample.ko: Invalid module format
> 
> ...
> [  286.453463] livepatch_sample: module is marked as livepatch module, but livepatch support is disabled

Wouldn't the module fail to build in the first place, since
CONFIG_LIVEPATCH is disabled?

Anyway, I'm not sure about this approach.  This patch makes the s390
livepatch code no longer compilable, turning it into completely dead
code.  So if something changes in the s390 code which causes it to stop
compiling, nobody will notice.

I think I'd rather go in the opposite direction: allow the patches to be
loaded.  Then they can be forced, if needed.  That enables both compile
and runtime testing.  That way we don't make any backward progress,
until such arches get reliable stacktraces.

-- 
Josh

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ