RISC-V port for cryptographic libraries

[Kristin B.]

Hello,

I was hoping to compile OpenSSL for RISC-V.

However, it seems that OpenSSL does not currently support RISC-V as a platform.

Are there any cryptographic libraries known to have been successfully ported to RISC-V?  I saw some press about wolfSSL supporting RISC-V, but could not find additional information as to the current status of this.

Thanks,

Kristin

[Tommy Murphy]

> However, it seems that OpenSSL does not currently support RISC-V as a platform.

Are you sure about that?

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=891797

[Andreas Schwab]

On Mär 09 2020, Kristin B. wrote:

> However, it seems that OpenSSL does not currently support RISC-V as a
> platform.

OpenSSL doesn't need any specific platform support.

https://build.opensuse.org/package/show/openSUSE:Factory:RISCV/openssl-1_1

Andreas.

--
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

[Kristin B.]

Thanks for the replies, they were helpful.

Indeed, it does seem based on the links provided that OS-specific ports of OpenSSL have Configuration files with entries for riscv.  The git master branch for OpenSSL currently makes no mention of riscv, though--and I assumed that there was no support.

However, I realized that my use case is more nuanced than I originally thought.

I'm attempting to compile for an embedded environment, where in fact there will not be OS support at all, but a lightweight "kernel" with some system and virtual memory setup, similar to the riscv-tests environments.  I'm using the RISC-V newlib toolchain as a result, and based on some examples I've seen for the proxy-kernel and riscv-tests, I'm compiling with -nostdlib.

The compile seems to be successful, but of course, there are linker errors for references to syscalls that have not been implemented. The riscv-tests directory has implementations of a few critical syscalls, but not all that OpenSSL makes use of.

So this brings me to my main point: when compiling for constrained environments, what's considered best practice for compiling relatively complex software like OpenSSL? To maybe make things easier, I don't actually need *all* of OpenSSL, just the crypto, even more specifically, RSA encrypt/decrypt.  

Is it typical to grab open-source implementations from a distro of all the needed syscalls to make things easy? This seems like it could be non-trivial, depending on how complicated the application is.

If you have any insights, or if it makes more sense for me to open a new thread for this, it would be much appreciated.

--Kristin

[Tommy Murphy]

Can't you just provide those system calls that you need and/or stubs for those that you don't the same way that libgloss often does this for newlib in a bare metal environment?

https://www.embecosm.com/appnotes/ean9/html/ch03s01.html

[John Downey]

If I was in your position I'd be looking at a cryptography library more suited to embedded systems like BearSSL[1]. I have not personally compiled BearSSL for any RISC-V core but it does have an impressive reputation when it comes to working in constrained environments.

[1] https://www.bearssl.org

--
You received this message because you are subscribed to the Google Groups "RISC-V SW Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sw-dev+un...@groups.riscv.org.
To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/sw-dev/8fd0ac99-792c-4216-b3ed-9cc9dacd9b00%40groups.riscv.org.

--

John Downey

[Jim Wilson]

On Tue, Mar 10, 2020 at 2:06 PM Tommy Murphy <tommy_...@hotmail.com> wrote:
> Can't you just provide those system calls that you need and/or stubs for those that you don't the same way that libgloss often does this for newlib in a bare metal environment?
> https://www.embecosm.com/appnotes/ean9/html/ch03s01.html

libgloss already provides libnosys.a which provides a number of
syscall stubs that return error, and a trivial sbrk implementation
that increments heap_end. You would need sbrk for malloc to work, but
the rest of the syscalls you may not need, so stubs that return error
may work fine. This only stubs out the syscalls that newlib has
support for though. A linux application might be using additional
syscalls that newlib doesn't support.

Jim

[Tommy Murphy]

> A linux application might be using additional syscalls that newlib doesn't support.

Isn't that moot since the context here has been stated to be bare metal embedded?

> I'm attempting to compile for an embedded environment, where in fact there will 

> not be OS support at all, but a lightweight "kernel" with some system and virtual 

> memory setup, similar to the riscv-tests environments.  

---

From: Jim Wilson <ji...@sifive.com>
Sent: Tuesday 10 March 2020 23:01
To: Tommy Murphy <tommy_...@hotmail.com>
Cc: Kristin B. <barber.m...@gmail.com>; RISC-V SW Dev <sw-...@groups.riscv.org>; sch...@suse.de <sch...@suse.de>
Subject: Re: [sw-dev] RISC-V port for cryptographic libraries

 

[Liviu Ionescu]

> On 11 Mar 2020, at 01:04, Tommy Murphy <tommy_...@hotmail.com> wrote:
>
> ... Isn't that moot since the context here has been stated to be bare metal embedded?

You'll eventually get used to this, there are people which, whatever bare metal related question you ask, will answer with something unix/linux related. :-(


Liviu

[Jim Wilson]

On Tue, Mar 10, 2020 at 4:04 PM Tommy Murphy <tommy_...@hotmail.com> wrote:
> > A linux application might be using additional syscalls that newlib doesn't support.
>
> Isn't that moot since the context here has been stated to be bare metal embedded?

No it isn't moot, because the sources being compiled are linux
sources. That is why they are calling syscalls in the first place.
Obviously, it would be better to use bare metal embedded openssl
libraries, but if you are going to try linux sources, then libnosys
might be useful to get it to link. That is what it is for. A bare
metal library to provide syscall stubs for linux code.

Jim

[Kristin B.]

Thanks again, useful comments.

I'm still struggling to do a successful build, maybe there is something fundamental here that I'm missing.

Here's an example of a couple of references the linker is complaining about:

  1) mprotect

  2) __isoc99_sscanf

  3) tcsetattr

  4) mlock

  5) There are at least a couple dozen others

It seems to be a mix of C std library calls and system calls.  I'm a bit surprised here because, based on my own understanding and comments here, the Newlib RISC-V cross-compiler contains its own implementation of the standard C/++ library, and the libnosys library from libgloss has at least stubs for prominent system calls (I would assume mprotect and mlock fall into this category).  I've added to LFLAGS the path to .a files for libnosys and the Newlib C libraries, along with -lc and -lnosys; as well as adding the include path for the C library to CFLAGS.

Any ideas why the linker still doesn't recognize these?

[Jim Wilson]

On Fri, Mar 13, 2020 at 3:59 PM Kristin B. <barber.m...@gmail.com> wrote:
> Here's an example of a couple of references the linker is complaining about:
> 1) mprotect
> 2) __isoc99_sscanf
> 3) tcsetattr
> 4) mlock
> 5) There are at least a couple dozen others
>
> It seems to be a mix of C std library calls and system calls. I'm a bit surprised here because, based on my own understanding and comments here, the Newlib RISC-V cross-compiler contains its own implementation of the standard C/++ library, and the libnosys library from libgloss has at least stubs for prominent system calls (I would assume mprotect and mlock fall into this category). I've added to LFLAGS the path to .a files for libnosys and the Newlib C libraries, along with -lc and -lnosys; as well as adding the include path for the C library to CFLAGS.
>
> Any ideas why the linker still doesn't recognize these?

Newlib and liblgoss only implement a minimal set of syscalls that make
sense for embedded development. mprotect and mlock and not relevant
to embedded work and not implemented. tcsetattr is for terminal
control and not relevant to embedded work. isoc99_sscanf is an
internal glibc function that users should not directly call, but you
could get a call to this if you are using glibc header files. This
suggest a build problem, where you are perhaps using the system header
files in /usr/include instead of the newlib header files. I assume
you are using an embedded elf compiler and not a linux compiler. If
you are using a linux compiler, then that isn't going to work on an
embedded system.

Did you try looking at bearssl? A linux source tree like openssl is
probably going to be hard to compile for an embedded system. Too many
linux assumptions in the sources. You will have better luck with a
package intended for use on embedded systems.

Jim

[Kristin B.]

Thanks Jim, I appreciate the reply.

I saw where you had suggested looking at SSL libraries specifically meant for embedded systems in your last post, and I've started to take a look at BearSSL.  

I was still curious if it was fundamentally difficult to get OpenSSL compiled in this case but, as you pointed out, that does seem to be true.  I am indeed using an elf compiler.

This is somewhat tangential but, I'm curious, is it possible then to compile OpenSSL for use with the RISC-V proxy kernel? My understanding was that only ELF binaries could be run with it.  Would it be just as fundamentally difficult to compile a codebase like OpenSSL for use with that environment?

On Friday, March 13, 2020 at 7:14:07 PM UTC-4, Jim Wilson wrote:

[Jim Wilson]

On Fri, Mar 13, 2020 at 4:27 PM Kristin B. <barber.m...@gmail.com> wrote:
> This is somewhat tangential but, I'm curious, is it possible then to compile OpenSSL for use with the RISC-V proxy kernel? My understanding was that only ELF binaries could be run with it. Would it be just as fundamentally difficult to compile a codebase like OpenSSL for use with that environment?

Proxy kernel supports more syscalls than newlib/libgloss, but it is
still a limited list. It does have mprotect but not mlock for
instance. It might be feasible to extend proxy kernel to support the
missing syscalls, but that would be a bit of work.

Jim