linux-kernel - Re: [PATCH v2 0/4] Static calls

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: <20181211180521.ljdvnnztjnvoijge@treble>
Date:   Tue, 11 Dec 2018 12:05:21 -0600
From:   Josh Poimboeuf <jpoimboe@...hat.com>
To:     Edward Cree <ecree@...arflare.com>
Cc:     linux-kernel@...r.kernel.org, x86@...nel.org,
        Paolo Abeni <pabeni@...hat.com>, Nadav Amit <namit@...are.com>
Subject: Re: [PATCH v2 0/4] Static calls

On Fri, Dec 07, 2018 at 04:06:32PM +0000, Edward Cree wrote:
> Sorry if this has been pointed out before (it's a very long thread), but
>  in the out-of-line implementation, it appears that static_call_update()
>  never alters key->func.  Am I right in thinking that this should be
>  fixed by adding 'WRITE_ONCE(key->func, func);' just after the call to
>  arch_static_call_transform() on line 159 of include/linux/static_call.h?

Yes, you're right about both bugs in the out-of-line case: key->func
needs to be written, and __static_call_update() needs to be called by
static_call_update.  I was so focused on getting the inline case working
that I overlooked those.

> Some background (why does key->func matter for the
>  CONFIG_HAVE_STATIC_CALL_OUTLINE case?): I am experimenting with
>  combining these static calls with the 'indirect call wrappers' notion
>  that Paolo Abeni has been working on [1], using runtime instrumentation
>  to determine a list of potential callees.  (This allows us to cope with
>  cases where the callees are in modules, or where different workloads may
>  use different sets of callees for a given call site, neither of which is
>  handled by Paolo's approach).
> The core of my design looks something like:
> 
> static int dynamic_call_xyz(int (*func)(some_args), some_args)
> {
> 	if (func == dynamic_call_xyz_1.func)
> 		return static_call(dynamic_call_xyz_1, some_args);
> 	if (func == dynamic_call_xyz_2.func)
> 		return static_call(dynamic_call_xyz_2, some_args);
> 	return (*func)(some_args);
> }
> 
> albeit with a bunch of extra (and currently rather ugly) stuff to collect
>  the statistics needed to decide what to put in the static call keys, and
>  mechanisms (RCU in my current case) to ensure that the static call isn't
>  changed between checking its .func and actually calling it.
> 
> -Ed
> 
> PS: not on list, please keep me in CC.
> 
> [1] https://lwn.net/Articles/773985/

Thanks, this sounds very interesting.  Adding Nadav to CC, as he has
been looking at a different approach to solving the same problem:

  https://lkml.kernel.org/r/20181018005420.82993-1-namit@vmware.com

-- 
Josh