linux-kernel - Re: [PATCH v2 bpf-next 1/3] perf: enable branch record for software events

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: <YS+zwVNMVBKWxGc3@hirez.programming.kicks-ass.net>
Date:   Wed, 1 Sep 2021 19:09:21 +0200
From:   Peter Zijlstra <peterz@...radead.org>
To:     Song Liu <songliubraving@...com>
Cc:     "open list:BPF (Safe dynamic programs and tools)" 
        <bpf@...r.kernel.org>, LKML <linux-kernel@...r.kernel.org>,
        Arnaldo Carvalho de Melo <acme@...nel.org>,
        Ingo Molnar <mingo@...hat.com>,
        kajoljain <kjain@...ux.ibm.com>, Kernel Team <Kernel-team@...com>
Subject: Re: [PATCH v2 bpf-next 1/3] perf: enable branch record for software
 events

On Mon, Aug 30, 2021 at 04:36:44PM +0000, Song Liu wrote:

> > /*
> > * Static call support
> > *
> > * Static calls use code patching to hard-code function pointers into direct
> > * branch instructions. They give the flexibility of function pointers, but
> > * with improved performance. This is especially important for cases where
> > * retpolines would otherwise be used, as retpolines can significantly impact
> > * performance.
> > *
> 
> [...]
> 
> > *
> > * Notes on NULL function pointers:
> > *
> > *   Static_call()s support NULL functions, with many of the caveats that
> > *   regular function pointers have.
> > *
> > *   Clearly calling a NULL function pointer is 'BAD', so too for
> > *   static_call()s (although when HAVE_STATIC_CALL it might not be immediately
> > *   fatal). A NULL static_call can be the result of:
> > *
> 
> Probably add:
> 
>  *     /* for function that returns NULL */
> > *     DECLARE_STATIC_CALL_NULL(my_static_call, void (*)(int));
> 
> 
>  *   or 
>  *     /* for function that returns int */
>  *     DECLARE_STATIC_CALL_RET0(my_static_call, int (*)(int));
>  * 

No, anything that uses static_call_cond() must have void return. Note
that static_call_cond() replaces:

	if (func_ptr)
		func_ptr(args);

which is a statement, not an expression, and as such can't function as
an rvalue.

> So it is clear that we need two different macros. IIUC, the number and 
> type of arguments doesn't matter? 

Right, arguments are irrelevant, provided CDECL ABI, which mandates that
arguments that are pushed on the stack are cleaned up by the caller, not
the callee.

> Also, the default return int function has to return 0, right? Can we let 
> it return -EOPNOSUPP? 

Difficult, in principle we can patch any value that fits in a single
instruction, but the more variants we have, the harder it gets.