[PATCH v4] crypto: riscv/poly1305 - import OpenSSL/CRYPTOGAMS implementation

[Sami Tolvanen]

On Fri, Jun 27, 2025 at 2:07 AM Andy Polyakov <appro at cryptogams.org> wrote:
>
> > we would need
> > to use SYM_TYPED_FUNC_START to emit CFI type information for them.
>
> I'm confused. My understanding is that SYM_TYPED_FUNC_START is about
> clang -fsanitize=kcfi, which is a different mechanism. Well, you might
> be referring to future developments...

CONFIG_CFI_CLANG is supported in the kernel right now, which is why we
need to make sure indirect call targets in assembly code are properly
annotated.

Like I said, if RISC-V gains kernel-mode Zicfilp support later, I
would expect the SYM_TYPED_FUNC_START macro to be overridden to
include the lpad instruction as well, similarly to other architectures
that already support landing pad instructions. In either case, instead
of including raw lpad instructions in the code, it should be up to the
kernel to decide if landing pads (or other CFI annotations) are needed
for the function.

> > Also, if the kernel decides to use type-based landing pad labels for
> > finer-grained CFI, "lpad 0" isn't going to work anyway.
>
> It would, it simply won't be fine-graned.

Sorry for not being clear. If the kernel implements a fine-grained
Zicfilp scheme, we wouldn't want universal indirect call targets (i.e.
lpad 0) anywhere in the code. And even if we implement coarse-grained
Zicfilp, we would only want landing pads in functions where they're
needed to minimize the number of call targets.

> > Perhaps it
> > would make sense to just drop the lpad instruction in kernel builds
> > for now to avoid confusion?
>
> Let's say I go for
>
> #ifdef __KERNEL__
> SYM_TYPED_FUNC_START(poly1305_init, ...)
> #else
> .globl  poly1305_init
> .type   poly1305_init,\@function
> poly1305_init:
> # ifdef __riscv_zicfilp
>         lpad    0
> # endif
> #endif
>
> Would it be sufficient to #include <linux/cfi_types.h>?

Yes, but this requires the function to be indirectly called, because
with CFI_CLANG the compiler only emits CFI type information for
functions that are address-taken in C. If, like Eric suggested, these
functions are not currently indirectly called, I would simply leave
out the lpad instructions for kernel builds and worry about
kernel-mode CFI annotations when they're actually needed:

# if defined(__riscv_zicfilp) && !defined(__KERNEL__)
        lpad    0
# endif

Sami