imer_setup() is not compatible with PaX's RAP

imer_setup() is not compatible with PaX's RAP

[Tom Li]

After upgraded to 0.0.20171101, I found my 4.9 PaX/grsecurity kernel
will panic soon if wireguard has been started, because of a RAP function
point type violation.

PAX: RAP hash violation for function pointer: peer_remove_all+0x450/0x930 [wireguard]
PAX: overwritten function pointer detected: 0000 [#1] PREEMPT SMP
RIP: 0010:[<ffffffff8115f670>]  [<ffffffff8115f670>] call_timer_fn+0x210/0x230

Basically it says call_timer_fn() was going to call a function pointer led to peer_remove_all(),
but the type of the function pointer doesn't match the function.

A quick look to the kernel source code showed it was a side-effect of Kees Cook's
new timer API in commit 686fef928bba6be13cabe639f154af7d72b63120 [1], which introduced
new timer_setup() function.

static inline void timer_setup(struct timer_list *timer,
                               void (*callback)(struct timer_list *),
                               unsigned int flags)

WireGuard has switched to this new API to setup timers since
7be989478f2fa659b0b6b55dbd72f222b932a5ee [2], and provided a macro to be compatible
with older kernels.

#define timer_setup(a, b, c) setup_timer(a, ((void (*)(unsigned long))b), ((unsigned long)a))

But it has an unfortunately consequence. a function type must match function pointer type used
in the indirect call, although conversion in-between is allowed, but it has to be matched
when the pointer is called, otherwise it's an undefined behavior.

Normally, it works on most compilers, but it triggers PaX's RAP as a breach of Control-Flow
Integrity. I don't think there were any RAP violations in the previous version, and as user
it would be the best to get it fixed in a way that doesn't involve incompatible function pointer
types to comfort RAP, but I don't know if WireGuard is still going to support 4.9 PaX kernel...

P.S: Now the kernel is doing essentially the same thing, but Cook said after the conversion is
finished, pointer cast will be removed. But on existing kernels it'll always be an issue...

Anyway, It's hard to say who break who... Probably it's going to work for me if I revert
7be989478f2fa659b0b6b55dbd72f222b932a5ee on my computer as for now...

At least it has been documented in the mailing list now...

Regards,
Tom Li

Re: imer_setup() is not compatible with PaX's RAP

[Tom Li]

Oops, s/imer/timer, and missing reference links.

[1] https://github.com/torvalds/linux/commit/686fef928bba6be13cabe639f154af7d72b63120
[2] https://git.zx2c4.com/WireGuard/commit/?id=7be989478f2fa659b0b6b55dbd72f222b932a5ee

In addition, RAP design presentation.

[3] https://pax.grsecurity.net/docs/PaXTeam-H2HC15-RAP-RIP-ROP.pdf

Regards,
Tom Li

Re: imer_setup() is not compatible with PaX's RAP

[Jason A. Donenfeld]

Hey Pipacs,

Looks like RAP is working correctly! That's heartening. If the below
didn't break, I suppose there'd be a problem. [See replied-to email
below.]

Upstream changed the argument of timer callbacks to `struct timer_list
*` instead of `unsigned long`. Since I'm trying to get my stuff
upstream, I generally code against the newest kernel, and then have
this disgusting file called compat.h [1] that abuses the preprocessor
to rewrite code based on which kernel I'm compiling against; I've got
it working for 3.10+.  If you woke up with good vision this morning,
I'm sorry, since your eyeballs are doubtlessly bleeding after glancing
at compat.h. In order to support old kernels, I just cast the
functions with argument `struct timer_list *` to functions with
argument `unsigned long`, and call it a day.

A grsecurity user has complained about this not working. I assume when
you guys move to 4.14, this will go away, but I also assume that the
person who emailed me below isn't actually a paying customer and
instead is using the old patches. So, I can't just say, "go to
grsecurity.net and get the latest." Yet, I'd like to continue
supporting PaX in my compat.h layer for as long as possible.

I'm wondering if you can think of any macro hackery I could surround
in `#ifdef CONFIG_PAX_RAP` inside compat.h, and have this issue go
away. Perhaps some kind of special rap_hash attributes? Or other
tricks?

Thanks,
Jason

[1] https://git.zx2c4.com/WireGuard/tree/src/compat/compat.h


On Sat, Nov 11, 2017 at 5:09 PM, Tom Li <tomli@tomli.me> wrote:
> After upgraded to 0.0.20171101, I found my 4.9 PaX/grsecurity kernel
> will panic soon if wireguard has been started, because of a RAP function
> point type violation.
>
> PAX: RAP hash violation for function pointer: peer_remove_all+0x450/0x930 [wireguard]
> PAX: overwritten function pointer detected: 0000 [#1] PREEMPT SMP
> RIP: 0010:[<ffffffff8115f670>]  [<ffffffff8115f670>] call_timer_fn+0x210/0x230
>
> Basically it says call_timer_fn() was going to call a function pointer led to peer_remove_all(),
> but the type of the function pointer doesn't match the function.
>
> A quick look to the kernel source code showed it was a side-effect of Kees Cook's
> new timer API in commit 686fef928bba6be13cabe639f154af7d72b63120 [1], which introduced
> new timer_setup() function.
>
> static inline void timer_setup(struct timer_list *timer,
>                                void (*callback)(struct timer_list *),
>                                unsigned int flags)
>
> WireGuard has switched to this new API to setup timers since
> 7be989478f2fa659b0b6b55dbd72f222b932a5ee [2], and provided a macro to be compatible
> with older kernels.
>
> #define timer_setup(a, b, c) setup_timer(a, ((void (*)(unsigned long))b), ((unsigned long)a))
>
> But it has an unfortunately consequence. a function type must match function pointer type used
> in the indirect call, although conversion in-between is allowed, but it has to be matched
> when the pointer is called, otherwise it's an undefined behavior.
>
> Normally, it works on most compilers, but it triggers PaX's RAP as a breach of Control-Flow
> Integrity. I don't think there were any RAP violations in the previous version, and as user
> it would be the best to get it fixed in a way that doesn't involve incompatible function pointer
> types to comfort RAP, but I don't know if WireGuard is still going to support 4.9 PaX kernel...
>
> P.S: Now the kernel is doing essentially the same thing, but Cook said after the conversion is
> finished, pointer cast will be removed. But on existing kernels it'll always be an issue...
>
> Anyway, It's hard to say who break who... Probably it's going to work for me if I revert
> 7be989478f2fa659b0b6b55dbd72f222b932a5ee on my computer as for now...
>
> At least it has been documented in the mailing list now...
>
> Regards,
> Tom Li
>
> [1] https://github.com/torvalds/linux/commit/686fef928bba6be13cabe639f154af7d72b63120
> [2] https://git.zx2c4.com/WireGuard/commit/?id=7be989478f2fa659b0b6b55dbd72f222b932a5ee

Re: imer_setup() is not compatible with PaX's RAP

[Jason A. Donenfeld]

In other words, can I do better than this?

https://git.zx2c4.com/WireGuard/commit/?id=01eebded60497528249962d03582a163a90d3b22

Re: imer_setup() is not compatible with PaX's RAP

[PaX Team]

On 12 Nov 2017 at 11:50, Jason A. Donenfeld wrote:

> Hey Pipacs,
> 
> Looks like RAP is working correctly! That's heartening. If the below
> didn't break, I suppose there'd be a problem. [See replied-to email
> below.]

indeed, this is one kind of problem that RAP's supposed to catch ;).

> A grsecurity user has complained about this not working. I assume when
> you guys move to 4.14, this will go away,

not really... while there're no in-tree users of timer_setup in 4.14
and thus in-tree timer functions can be called without triggering RAP,
your wireguard callbacks have the wrong prototype and will be caught.
you can only cheat the compiler at the assignment by that fptr cast,
at fptr dereference time RAP will still see the type hash mismatch.

> I'm wondering if you can think of any macro hackery I could surround
> in `#ifdef CONFIG_PAX_RAP` inside compat.h, and have this issue go
> away. Perhaps some kind of special rap_hash attributes? Or other
> tricks?

there's no way to satisfy RAP other than getting your types right.
the problem isn't in timer_setup per se, but at the actual indirect
calls to the timer functions and those will always trigger RAP unless
the timer functions have the correct prototype. now you could add
wrapper functions if you don't want to uglyfy the code headed upstream
but then you cannot generate them from the timer_setup macro since
that's invoked inside a function and C would at most let you declare
those wrapper functions there but not define them.

another approach could be to depend on TIMER_DATA_TYPE instead and use
it in your callback prototypes. as a sidenote, if you want to depend
on plugin related features, it's better to depend on RAP_PLUGIN and
similar (as you do with CONSTIFY_PLUGIN already) and not the actual
kernel config option since the latter can be true even if the given
compiler doesn't support plugins or the config could cover more than
the plugin and could work without it even (the STACKLEAK feature used
to be an example of that).

speaking of PaX support, you recently added some __ro_after_init wrapper
to wireguard which breaks under KERNEXEC when it's used on ops structs
(my __read_only has different semantics) so i have to revert it here but
it'd be nicer if you didn't define it when KERNEXEC is active.

cheers,
 PaX Team

Re: imer_setup() is not compatible with PaX's RAP

[Jason A. Donenfeld]

Hey Pipacs,

On Mon, Nov 13, 2017 at 2:39 AM, PaX Team <pageexec@freemail.hu> wrote:
> at fptr dereference time RAP will still see the type hash mismatch.
> another approach could be to depend on TIMER_DATA_TYPE instead and use
> it in your callback prototypes. as a sidenote, if you want to depend
> on plugin related features, it's better to depend on RAP_PLUGIN

I've fixed this all up here:
https://git.zx2c4.com/WireGuard/commit/?id=e4bf02b833f99f4dcc2ab685d92517ccf8cc4766

I think it _should_ work now. Thanks for the suggestions. I just
monkey patched the signatures of each of those functions. Ugly, but it
works.

>
> speaking of PaX support, you recently added some __ro_after_init wrapper
> to wireguard which breaks under KERNEXEC when it's used on ops structs
> (my __read_only has different semantics) so i have to revert it here but
> it'd be nicer if you didn't define it when KERNEXEC is active.

I've attempted to fix this in the same commit. Does that look like it will work?

By the way, if you ever find yourself having to revert things to run
WireGuard, don't hesitate to send a patch or just poke me, and I'll
fix things. I'd definitely like to support PaX for as long as I can
manage to do so.

Jason

Re: imer_setup() is not compatible with PaX's RAP

[PaX Team]

On 13 Nov 2017 at 20:34, Jason A. Donenfeld wrote:

> I've fixed this all up here:
> https://git.zx2c4.com/WireGuard/commit/?id=e4bf02b833f99f4dcc2ab685d92517ccf8cc4766
> 
> I think it _should_ work now. Thanks for the suggestions. I just
> monkey patched the signatures of each of those functions. Ugly, but it
> works.

oh boy, can't disagree with ugly ;). it needed a few tweaks:

--- WireGuard-0.0.20171111.orig/src/compat/compat.h       2017-11-11 04:35:06.000000000 +0100
+++ WireGuard-0.0.20171111/src/compat/compat.h    2017-11-13 23:21:17.967716768 +0100
@@ -562,4 +562,23 @@ static inline void new_icmpv6_send(struc
 #define __read_mostly
 #endif

+#ifdef RAP_PLUGIN
+#include <linux/timer.h>
+#ifndef TIMER_DATA_TYPE
+#define TIMER_DATA_TYPE unsigned long
+#endif
+
+#define expired_retransmit_handshake(a) expired_retransmit_handshake(TIMER_DATA_TYPE timer)
+#define expired_send_keepalive(a) expired_send_keepalive(TIMER_DATA_TYPE timer)
+#define expired_new_handshake(a) expired_new_handshake(TIMER_DATA_TYPE timer)
+#define expired_zero_key_material(a) expired_zero_key_material(TIMER_DATA_TYPE timer)
+#define expired_send_persistent_keepalive(a) expired_send_persistent_keepalive(TIMER_DATA_TYPE timer)
+
+#undef timer_setup
+#define timer_setup(a, b, c) setup_timer(a, ((void (*)(TIMER_DATA_TYPE))b), ((TIMER_DATA_TYPE)a))
+
+#undef from_timer
+#define from_timer(var, callback_timer, timer_fieldname) container_of((struct timer_list *)callback_timer, typeof(*var), timer_fieldname)
+#endif
+
 #endif /* _WG_COMPAT_H */

the KERNEXEC block isn't needed as it was removing KERNEXEC's own define and
pre 4.14 kernels don't define TIMER_DATA_TYPE so it has to be defined for them.
also this whole block should probably depend on 4.15 if it ends up converting
all old prototypes and removes TIMER_DATA_TYPE itself.

> By the way, if you ever find yourself having to revert things to run
> WireGuard, don't hesitate to send a patch or just poke me, and I'll
> fix things. I'd definitely like to support PaX for as long as I can
> manage to do so.

thanks, will keep you posted if i see anything.

Re: imer_setup() is not compatible with PaX's RAP

[Jason A. Donenfeld]

On Tue, Nov 14, 2017 at 1:15 AM, PaX Team <pageexec@freemail.hu> wrote:
> oh boy, can't disagree with ugly ;)

The goal is the highest possible density of filth.

>
> --- WireGuard-0.0.20171111.orig/src/compat/compat.h       2017-11-11 04:35:06.000000000 +0100
> +++ WireGuard-0.0.20171111/src/compat/compat.h    2017-11-13 23:21:17.967716768 +0100

I fixed things up here:
https://git.zx2c4.com/WireGuard/commit/?id=df318d1f0526663a2d92439376379e32ebcfef1a

> the KERNEXEC block isn't needed as it was removing KERNEXEC's own define

Wait, but earlier you wrote:

> speaking of PaX support, you recently added some __ro_after_init wrapper
> to wireguard which breaks under KERNEXEC when it's used on ops structs
> (my __read_only has different semantics) so i have to revert it here but
> it'd be nicer if you didn't define it when KERNEXEC is active.

So what exactly should I be fixing? I think in that last patch I
forgot to redefine it to be empty. Would this do what you have in
mind:

#ifdef CONFIG_PAX_KERNEXEC
#include <linux/cache.h>
#undef __ro_after_init
#define __ro_after_init
#endif

Or is there something else?

Jason

Re: imer_setup() is not compatible with PaX's RAP

[Jason A. Donenfeld]

On Tue, Nov 14, 2017 at 10:29 AM, Jason A. Donenfeld <Jason@zx2c4.com> wrote:
> Or is there something else?

With the latest git master (that commit in my last email), I just
tried compiling and running this with some sketchtastic 4.9 "forward
ports", and things seem to be working. If things are broken for you
with >4.9, happy to accept patches.

Re: imer_setup() is not compatible with PaX's RAP

[PaX Team]

On 14 Nov 2017 at 10:29, Jason A. Donenfeld wrote:

> I fixed things up here:
> https://git.zx2c4.com/WireGuard/commit/?id=df318d1f0526663a2d92439376379e32ebcfef1a

works fine, thanks.

> > speaking of PaX support, you recently added some __ro_after_init wrapper
> > to wireguard which breaks under KERNEXEC when it's used on ops structs
> > (my __read_only has different semantics) so i have to revert it here but
> > it'd be nicer if you didn't define it when KERNEXEC is active.
> 
> So what exactly should I be fixing? I think in that last patch I
> forgot to redefine it to be empty. Would this do what you have in
> mind:

i said 'don't define it', not 'redefine it' ;). the difference is that the
latter removes the definition provided under KERNEXEC.

Re: imer_setup() is not compatible with PaX's RAP

[Jason A. Donenfeld]

Hey Pipacs,

A user on IRC found another issue. This time it looks like it might be
a RAP bug, though. Below is the error output. So far as I can see, the
function pointer type and the function declaration match fine.
However, the function itself is implemented in assembly, which means
it can't itself be instrumented by RAP. What to do?

https://git.zx2c4.com/WireGuard/tree/src/crypto/chacha20poly1305.c#n567

Jason

[31312.560886] wireguard: loading out-of-tree module taints kernel.
[31312.561438] wireguard: WireGuard 0.0.20171127 loaded. See
www.wireguard.com for information.
[31312.561439] wireguard: Copyright (C) 2015-2017 Jason A. Donenfeld
<Jason@zx2c4.com>. All Rights Reserved.
[31322.008508] PAX: RAP hash violation for function pointer:
poly1305_blocks_x86_64+0x0/0x100 [wireguard]
[31322.018515] PAX: overwritten function pointer detected: 0000 [#1] SMP
[31322.028152] Modules linked in: wireguard(O) ip6_udp_tunnel
udp_tunnel tun 8021q mrp ipt_MASQUERADE nf_nat_masquerade_ipv4 xt_nat
iptable_nat nf_nat_ipv4 ipt_REJECT nf_reject_ipv4 nf_log_ipv4
nf_conntrack_ipv4 nf_defrag_ipv4 xt_multiport iptable_filter
iptable_mangle ip_tables xt_TCPMSS xt_comment xt_tcpudp
ip6table_mangle ip6t_REJECT nf_reject_ipv6 nf_log_ipv6 nf_log_common
xt_LOG xt_limit xt_conntrack ip6table_filter ip6t_MASQUERADE
nf_nat_masquerade_ipv6 ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6
nf_nat_ipv6 nf_nat nf_conntrack ip6t_rpfilter ip6table_raw ip6_tables
x_tables ext4 crc16 jbd2 mbcache xfs libcrc32c exportfs af_packet ipv6
virtio_console psmouse serio_raw pcspkr igb ptp pps_core hwmon dca
i2c_algo_bit shpchp input_leds evdev joydev mousedev qemu_fw_cfg
floppy parport_pc parport tpm_tis
[31322.099742]  tpm_tis_core tpm dm_mod hid_generic usbhid hid uas
fbcon bitblit fbcon_rotate fbcon_ccw fbcon_ud fbcon_cw softcursor font
tileblit virtio_balloon button xhci_pci xhci_hcd uhci_hcd bochs_drm
ttm drm_kms_helper drm fb_sys_fops syscopyarea sysfillrect sysimgblt
ata_generic pata_acpi ata_piix libata virtio_pci virtio_ring virtio
i2c_piix4 i2c_core intel_agp intel_gtt agpgart loop crc32c_generic
btrfs xor raid6_pq usb_storage sd_mod scsi_mod
[31322.157368] CPU: 0 PID: 3344 Comm: kworker/0:2 Tainted: G
O    4.9.65-1-hardened #2-Alpine
[31322.173073] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
BIOS rel-1.10.2-0-g5f4c7b1-prebuilt.qemu-project.org 04/01/2014
[31322.205545] Workqueue: wg-kex-lansecure
packet_handshake_receive_worker [wireguard]
[31322.222496] task: ffff8800b93f4bc0 task.stack: ffffc90003074000
[31322.239610] RIP: 0010:[<ffffffffa01ee17e>]  [<ffffffffa01ee17e>]
poly1305_update+0x18e/0x1b0 [wireguard]
[31322.257251] RSP: 0000:ffffc90003077998  EFLAGS: 00000216
[31322.274886] RAX: ffffffffa01f93c0 RBX: 0000000000000020 RCX: ffffffffa01ef7b3
[31322.292663] RDX: 0000000000000020 RSI: ffffc90003077ce7 RDI: ffffc90003077a70
[31322.310467] RBP: ffffc900030779d0 R08: ffffffffa01f93c0 R09: 0000000000000000
[31322.328276] R10: ffffc90003077b78 R11: 58e1b4d500000000 R12: ffffc90003077a70
[31322.346218] R13: 0000000000000000 R14: ffffc90003077ce7 R15: 0000000000000020
[31322.364271] FS:  0000000000000000(0000) GS:ffff8800bfa00000(0000)
knlGS:0000000000000000
[31322.382681] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[31322.401247] CR2: 0000000000000000 CR3: 00000000bae07000 CR4: 00000000000006b0
[31322.420111] Stack:
[31322.438912]  799bb7f3dc82ba87 5ecf70918324bcec ffffc90003077c87
ffffc90003077bb8
[31322.458357]  ffffc90003077a20 0000000000000001 0000000000000020
ffffc90003077c40
[31322.477912]  ffffffffa01ef7da b3326dec53956add 4bd3dddee06cadf2
0000000000000020
[31322.497565] Call Trace:
[31322.517082]  [<ffffffffa01ef7da>]
chacha20poly1305_decrypt+0x21a/0x8e0 [wireguard]
[31322.537124]  [<ffffffff8130ebc2>] ? memzero_explicit+0x1f/0x40
[31322.557308]  [<ffffffffa01f93c0>] ? poly1305_init_x86_64+0x40/0x40
[wireguard]
[31322.577686]  [<ffffffffa01f94c0>] ?
poly1305_blocks_x86_64+0x100/0x100 [wireguard]
[31322.598313]  [<ffffffffa01d73c6>]
noise_handshake_consume_initiation+0x286/0x6e0 [wireguard]
[31322.619328]  [<ffffffff8130ebc2>] ? memzero_explicit+0x1f/0x40
[31322.640488]  [<ffffffffa01e3259>] ? compute_mac1+0xc9/0x120 [wireguard]
[31322.661930]  [<ffffffffa01dcbdb>]
packet_handshake_receive_worker+0x2cb/0x430 [wireguard]
[31322.683748]  [<ffffffff8109b918>] process_one_work+0x260/0x40e
[31322.705478]  [<ffffffff8109ca87>] worker_thread+0x3f1/0x586
[31322.727402]  [<ffffffff8109c696>] ? rescuer_thread+0x443/0x443
[31322.749450]  [<ffffffff810a34e1>] kthread+0x15e/0x170
[31322.771493]  [<ffffffff810a3383>] ? kthread_park+0xa4/0xa4
[31322.793619]  [<ffffffff810a3383>] ? kthread_park+0xa4/0xa4
[31322.815512]  [<ffffffff8167051b>] ret_from_fork+0x5b/0x70
[31322.837338] Code: 8d bc 2f d0 00 00 00 4c 01 eb eb 0b b4 0c 76 cd
ff ff ff ff cc cc cc e8 41 62 12 e1 49 89 9c 24 e0 00 00 00 e9 4b ff
ff ff cd 82 <cd> 82 cd 83 0f 1f 40 00 66 2e 0f 1f 84 00 00 00 00 00 cc
cc cc
[31322.881717] RIP  [<ffffffffa01ee17e>] poly1305_update+0x18e/0x1b0 [wireguard]
[31322.903292]  RSP <ffffc90003077998>
[31322.961174] ---[ end trace f0299ab1621f48bd ]---

Re: imer_setup() is not compatible with PaX's RAP

[PaX Team]

On 28 Nov 2017 at 13:20, Jason A. Donenfeld wrote:

> Hey Pipacs,
> 
> A user on IRC found another issue. This time it looks like it might be
> a RAP bug, though. Below is the error output. So far as I can see, the
> function pointer type and the function declaration match fine.
> However, the function itself is implemented in assembly, which means
> it can't itself be instrumented by RAP. What to do?

targets of indirect calls must be marked by the RAP hash which the plugin
will do for code it sees but for asm you'll have to do it yourself, look at
the use of RAP_ENTRY to see how that works.

Re: imer_setup() is not compatible with PaX's RAP

[Jason A. Donenfeld]

On Tue, Nov 28, 2017 at 1:32 PM, PaX Team <pageexec@freemail.hu> wrote:
> targets of indirect calls must be marked by the RAP hash which the plugin
> will do for code it sees but for asm you'll have to do it yourself, look at
> the use of RAP_ENTRY to see how that works.

Oh, terrific. So I can just do something horrible like:

#ifdef RAP_PLUGIN
#undef ENTRY
#define ENTRY RAP_ENTRY
#endif

Re: imer_setup() is not compatible with PaX's RAP

[PaX Team]

On 28 Nov 2017 at 13:36, Jason A. Donenfeld wrote:

> On Tue, Nov 28, 2017 at 1:32 PM, PaX Team <pageexec@freemail.hu> wrote:
> > targets of indirect calls must be marked by the RAP hash which the plugin
> > will do for code it sees but for asm you'll have to do it yourself, look at
> > the use of RAP_ENTRY to see how that works.
> 
> Oh, terrific. So I can just do something horrible like:
> 
> #ifdef RAP_PLUGIN
> #undef ENTRY
> #define ENTRY RAP_ENTRY
> #endif

well, that would work but if not all asm entry points are meant to be called
indirectly then you're unnecessarily increasing the attack surface ;). better
would be something like:

1. use ENTRY/RAP_ENTRY in your asm as necessary. you can call it something
   more generic like CFI_ENTRY if you want to cover other CFI systems in the
   future, e.g., intel's CET will need its own entry point marker insn.

2. have this in your headers:

#ifdef RAP_PLUGIN
#define CFI_ENTRY RAP_ENTRY
#elif defined(...)
...
#else
#define CFI_ENTRY ENTRY
#endif