Is there a plan to support of other architectures?

[vt-alt]

Is it planned to support other architectures besides x86_64 and arm? Especially i586 and ppc64le.

[baentsch]

Those were surely not at the top of our priority list so far. Do you know how many i586 machines there still are around? How do you validate demand for these architectures? Regarding ppc64le @bhess may want to comment, too.

[bircoph]

Those were surely not at the top of our priority list so far. Do you know how many i586 machines there still are around?

Still fair number. I'm using one right now to write this comment. Why? It has no branch predictor, so it is invulnerable to meltdown and all spectre class attacks.

Anyway I see no real need to limit list of supported architectures in the first place: it should be always possible to fallback to generic C code.

[vt-alt]

I don't know about quantities of i585, but it's still supported by some distros like Debian.

[jschanck]

I would be in favour of changing "FATAL_ERROR" to "WARNING" here:

liboqs/CMakeLists.txt

Line 50 in 00d6c7d

message(FATAL_ERROR "Unknown or unsupported processor: " ${CMAKE_SYSTEM_PROCESSOR})

This would let users attempt to build on other architectures.

I'd also be OK with adding explicit i686 support (i586 is questionable, Debian dropped support for it in stretch), but this is really up to whether or not we have the resources for testing.

[baentsch]

I would be in favour of changing "FATAL_ERROR" to "WARNING" here:

+1.

[vt-alt]

If you have good tests it would be easy to continuously integrate them with Github actions.

You seem to have circle-ci already, so 32-bit x86 build^tests could be added there.

[bhess]

With less candidates remaining after the next NIST round, it could become more feasible to focus on more platforms. It would be definitely useful. Github Actions CI looks quite flexible for this with hosted and self-hosted runners.
My personal priorities would be s390x and then ppc64le.

[vt-alt]

Btw, I'm told that Travis-CI still free for non-x86 architectures: https://docs.travis-ci.com/user/billing-overview/#partner-queue-solution

Partner Queue Solution is a solution for infrastructure sponsored by our Partners with OSS
in mind which can be used completely for free. Currently, it includes:
• IBM CPU builds in IBM Cloud (sponsored by IBM)
• ARM64 CPU builds in Equinix Metal (former Packet) infrastructure (sponsored by ARM)
This is available only to Open Source Software repositories.

So, you can even run tests on ppc64le/s390x natively.

[dstebila]

With less candidates remaining after the next NIST round, it could become more feasible to focus on more platforms. It would be definitely useful. Github Actions CI looks quite flexible for this with hosted and self-hosted runners.
My personal priorities would be s390x and then ppc64le.

@bhess Use of self-hosted runners for Github Actions were looked at by @thomwiggers and he found it hard to use and without sufficient safety for public repositories (which we are).

[dstebila]

I'm not opposed to adding support for building on other architectures, or at the very least modifying makefiles to not block this. Before advertising support for a particular platform I'd want to have a good CI workflow that is testing it. At UW we're limited in our ability to maintain that, so would need others to take the lead on this. I don't object to using other CI systems (Github, Circle, Travis, Appveyor, ...) but prefer to only expand beyond our current CI systems (Circle and Appveyor) if the alternates give us access to something we don't currently have access to. (Just to avoid having to develop expertise with too many systems.)

[thomwiggers]

Github Actions runners are annoying for many reasons: you need to set them up for each project individually, you need to set up a virtual machine/environment per individual runner (so no running multiple runners out of the box), and I had massive issues where a lot of very basic actions just don't work because of assumptions that are present in the hosted runners but not in self-hosted runners (such as the runner always running as root: true on the hosted runners, not allowed by the self-hosted runners).

The best I know that supports "bring your own runner" for public repositories is Gitlab Runners, which means hooking up to a gitlab enterprise server (but Gitlab.com counts). gitlab-ci-multi-runner allows you to very easily run the equivalent of a shell script in a container, while it can even take care of automatically orchestrating/provisioning/tearing down boxes in the cloud as necessary.

[vt-alt]

FYI: I attempted simplistic port to x86 and ppc64le:
http://git.altlinux.org/people/vt/packages/?p=liboqs.git;a=commitdiff;h=c5023ce0eef244f324864c51bf9d68751cc84ddf
http://git.altlinux.org/people/vt/packages/?p=liboqs.git;a=commitdiff;h=387fdab3492c0e22cde571e3df6c636adae25706
All tests are passing except skipped ones (distbuild and constant_time).

ps. I'm aware that secure_cmp32 for BIKE does not handle ppc64le properly, but I did not notice (at the first glance) branching in asm (objdump -S) there.

[dstebila]

Nice work @vt-alt. Can you create pull requests for each of those -- separate ones for x86 and ppc64le? We need a testing plan for those before merging, however. For x86, would it suffice to build a 32-bit Docker image and run that on CircleCI? Or do we have to do something more complicated? As for ppc64le, it sounds like we'd have to set up a Travis configuration again and use IBM's free ppc64le environment on Travis. Are you of @bhess able to look into that?

[vt-alt]

@dstebila Yes, I will create PR later today. i386 docker images should work, AFAIK.