Detect cpu features on ARM with getauxval() #408

marshallpierce · 2017-01-08T16:28:19Z

This is 1 and 2 of your suggested PR disassembly in #392. I elected to do them together because otherwise this would have failed to build on arm because there wouldn't be a replacement for GFp_cpuid_setup.

marshallpierce · 2017-01-08T16:31:17Z

mk/ring.mk

@@ -32,6 +32,7 @@ RING_SRCS = $(addprefix $(RING_PREFIX), \
  crypto/bn/random.c \
  crypto/bn/shift.c \
  crypto/cipher/e_aes.c \
+  crypto/cpu-arm-linux.c \


This isn't ideal, and goes against the spirit of the filename...

Upon making this mini-PR I remembered why I put the C where I did: if the C bits are ARM-only with no provision for running tests, then so is all the Rust that uses it. So, to make the Rust (and Rust/C interaction) testable on average joe hardware (i.e. x86 Linux), I made cpu-arm-linux.c, uh, not ARM-specific. What's the right way to do this (where "this" is "make it testable on x86 linux, but in a production build only have this stuff present on ARM")?

briansmith · 2017-01-13T21:38:32Z

crypto/cpu-arm-linux.c

- * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION
- * OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF OR IN
- * CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE. */
-


The license must stay the same. If you think the Google copyright statement is not appropriate then suggest a different copyright statement.

Done. I don't really have an opinion; I just removed it because none of the code in this file was written by Google anymore.

briansmith · 2017-01-13T22:34:27Z

crypto/cpu-arm-linux.c

+ * - If getauxval() is available and the requested type is found, this returns
+ *   1 and also writes to the result pointer param.
+ */
+int32_t getauxval_wrapper(unsigned long type, unsigned long *result);


Our goal is to do as much in Rust as reasonable. That means doing as little in C as we can get away with. With that in mind, why not do this:

/* getauxval_wrapper returns 0 if |getauxval| is available and 1 otherwise. * If |getauxval| is available then |*result| is set to the result of * |getauxval(type)| before |getauxval_wrapper| returns. */ int getauxval_wrapper(unsigned long type, unsigned long *result) { if (getauxval == NULL) { return 0; } /* When |getauxval| returns 0, |errno == 0| indicates a zero value, * whereas |errno != 0| after |getauxval| indicates an error. * https://www.securecoding.cert.org/confluence/pages/viewpage.action?pageId=6619179#ERR10-C.Seterrnotozerobeforecallingalibraryfunctionknowntoseterrno,andcheckerrnoonlyafterthefunctionreturnsavalueindicatingfailure-LibraryFunctionsthatSeterrnoandReturnanIn-BandErrorIndicator */ errno = 0; *result = getauxval(type); return 1; }

The Rust code can then do all the rest of the logic, in particular using std::io::Error::last_os_error() to get errno.

Aha, I did not know about that function. That looks good, but how would we clear errno after reading it in Rust?

briansmith

Note that my first comment in this review was submitted before I hit "Start a review," and so it isn't part of the "review" as defined by Git. Also note I rewrote that comment a bit and GitHub might not have sent you email for each update.

Also note that I have lots of feedback about simplifying the code. Please don't take this too harshly. Basically, I just want us to try hard to make this code as simple as possible, taking advantage of the fact that we only really need need to detect specifically NEON and crypto features. As far as testing goes, IMO the testing here is overkill but I don't object to it. In the end, we're going to need to test this on real devices before it gets merged to master. I'm actually in the process of acquiring the devices now.

As I mentioned below, I think we are better of just implementing getauxval() ourselves in Rust, in a separate PR on top of this PR, instead of implementing the fallback to /proc/self/auxv.

briansmith · 2017-01-13T23:21:34Z

src/cpu_feature/arm_linux/arm_linux.rs

+
+    if let Ok(v) = getauxval_provider.getauxval(AT_HWCAP) {
+        hwcap = v;
+    }


The above can be replaced with let hwcap = getauxval_provider.getauxval(AT_HWCAP).unwrap_or(0);

briansmith · 2017-01-13T23:24:39Z

src/init.rs

+#[cfg(all(any(target_arch = "arm", target_arch = "aarch64"),
+    target_os = "linux"))]
+fn set_cpu_features() {
+    cpu_feature::arm_linux::arm_linux_set_cpu_features();


I think you should just inline arm_linux_set_cpu_features() into this, instead of having it be a separate function, making armcap_from_features() the public function in the submodule. That would simplify the code.

briansmith · 2017-01-13T23:27:44Z

src/cpu_feature/arm_linux/arm_linux.rs

+
+#[cfg(all(any(target_arch = "arm", target_arch = "aarch64"),
+    target_os="linux"))]
+pub fn arm_linux_set_cpu_features() {


In ring we try to organize files top-down. In particular, arm_linux_set_cpu_features() should be at the top of the module if it continues to exist, and its implementation details should be below.

briansmith · 2017-01-13T23:30:41Z

src/cpu_feature/arm_linux/arm_linux.rs

+
+    if let Ok(v) = getauxval_provider.getauxval(AT_HWCAP) {
+        hwcap = v;
+    }


let hwcap = provider.getauxval(AT_HWCAP).unwrap_or(0);

This means we're always calling unwrap_or(0) on the result of provider.getauxval(), so provider.getauxval() should just return 0 on error, instead of returning a Result. Further, if we do that, then getauxval_wrapper() doesn't need to distinguish between the cases where getauxval() doesn't exist, where getauxval() returns 0 without setting errno, and where getauxval() encountered an error: In all three cases, it can just set the output result to zero and we'll get the right semantics.

In the next PR, we may need to distinguish between these cases, but at this point, YAGNI applies, so let's simplify the code accordingly.

Plus, I have an idea to make all this code much simpler: Let's just implement getauxal() ourselves in Rust using the information from http://stackoverflow.com/a/7247142 and http://stackoverflow.com/a/7246388, in particular by iterating past the end of environ. I took a peak ah how getauxval() is implemented in Android's Bionic and that's how it's done anyway.

Then we won't need to write any code to read from /proc/self/auxv, and we won't have to worry about errno semantics, we won't have to worry about the differences between glibc and Android's Bionic or between glibc versions, and we won't have to worry about weak symbol linkage, and we can get rid of all the C code. WDYT?

Sounds good; I'll give it a try. It's been fun learning about this particular flavor of C/Rust interop, but I'd just as soon ditch all that.

briansmith · 2017-01-13T23:33:07Z

src/cpu_feature/arm_linux/arm_linux.rs

+        let mut hwcap2 = 0;
+        if let Ok(v) = getauxval_provider.getauxval(AT_HWCAP2) {
+            hwcap2 = v;
+        }


let hwcap2 = provider.getauxval(AT_HWCAP2).unwrap_or(0);

Done (do you want these Done comments? I miss BitBucket's tasks...)

briansmith · 2017-01-13T23:47:32Z

src/cpu_feature/arm_linux/arm_linux.rs

+const ARM_HWCAP2_AES: AuxvUnsignedLong = 1 << 0;
+const ARM_HWCAP2_PMULL: AuxvUnsignedLong = 1 << 1;
+const ARM_HWCAP2_SHA1: AuxvUnsignedLong = 1 << 2;
+const ARM_HWCAP2_SHA2: AuxvUnsignedLong = 1 << 3;


I suggest you rename auxv::AuxvUnsignedLong to auxv::Type, since it is the type of the type parameter. The fact that it is an unsigned long isn't relevant outside of self::auxv.

I don't love the current name, but it's also the value, so it might be confusing to someone to see that the return value is of type Type. Really it's too bad that the terminology of getauxval uses "type" for input instead of, say, "key". :( I can't think of anything better, so Type it is!

briansmith · 2017-01-14T00:56:48Z

src/cpu_feature/arm_linux/auxv.rs

+    fn test_getauxv_hwcap_linux_finds_hwcap() {
+        let native_getauxval = NativeGetauxvalProvider{};
+        let result = native_getauxval.getauxval(AT_HWCAP);
+        // there should be SOMETHING in the value


I don't think this is true, because by definition all these features are optional; if they weren't optional then AT_HWCAP wouldn't be required to report them. Or, do you have a counterexample?

I suggest we just drop this test.

briansmith · 2017-01-14T00:57:46Z

src/cpu_feature/arm_linux/auxv.rs

+        let native_getauxval = NativeGetauxvalProvider{};
+
+        // AT_NULL aka 0 is effectively the EOF for auxv, so it's never a valid type
+        assert_eq!(GetauxvalError::NotFound, native_getauxval.getauxval(0).unwrap_err());


This test may be more useful for your general-purpose getauxval crate, but I don't think it's useful enough to include in ring, so I suggest we just drop it.

briansmith · 2017-01-14T00:59:09Z

src/cpu_feature/arm_linux/arm_linux.rs

+        let getauxval = NativeGetauxvalProvider{};
+
+        // can't really say anything useful about its result
+        let _ = armcap_from_features(getauxval);


I don't think we need this test, because the tested code will be executed on every test on ARM platforms, so I suggest you just remove the test.

briansmith · 2017-01-14T00:59:47Z

src/cpu_feature/arm_linux/arm_linux.rs

+
+    #[test]
+    fn armcap_for_hwcap2_zero_returns_zero() {
+        assert_eq!(0, super::armcap_for_hwcap2(0));


I don't think we need this test either.

briansmith · 2017-01-14T01:09:40Z

What's the right way to do this (where "this" is "make it testable on x86 linux, but in a production build only have this stuff present on ARM")?

IMO, testing on x86 and x86-64 is a "nice to have" and IMO it's probably not worthwhile to do, once we've verified the code works on ARM and ARM64, because of all the complication it adds. I'd rather we find a way to make it easier to test this on ARM (e.g. make it easy to set up Android dev environments, perhaps via Docker) than to make the code even a little more complex or confusing to facilitate non-ARM testing.

briansmith · 2017-01-14T02:36:43Z

Also, regarding licensing:

Please add the contributor statement to the end of your commit message: https://github.com/briansmith/ring#contributing.
If you add significant amounts of code to a file, feel free to add your own copyright line.
Please state who the copyright holder of these changes is: Is it you, or some employer, or somebody else. Thanks!

…vel of feature detection into init. I agree to license my contributions to each file under the terms given at the top of each file I changed.

marshallpierce · 2017-01-14T03:27:42Z

Do you want the contributor statement in every commit, or just one, or only the last or first one, or...?

I'm the copyright holder; all this is done on my own time.

Also, please don't feel bad about telling me you don't like my approach on something. I'm here to learn how to build a crypto library, not to convince you that my way of building for testability or whatever is gospel. Obviously I choose an approach that seems best to me, and I wipe away a tiny tear when I delete code that enables testability or portability because those things are dear to me, but I'm perfectly happy to admit that my background is not in building low level crypto stuff, so my heuristics for what is worth the lines of code and what is not may well be not well-tuned for this arena. Anyway, I appreciate your thoughtful reviews. You've clearly been doing this sort of code longer than I have, so I'm happy to incorporate your knowledge there into my personal stash.

I agree to license my contributions to each file under the terms given at the top of each file I changed.

coveralls · 2017-01-14T07:23:59Z

Coverage decreased (-0.06%) to 93.408% when pulling 5a19ecc on marshallpierce:cpu-feature-getauxval-wrapper into c431705 on briansmith:master.

coveralls · 2017-01-14T08:32:55Z

Coverage decreased (-0.06%) to 93.408% when pulling 5a19ecc on marshallpierce:cpu-feature-getauxval-wrapper into c431705 on briansmith:master.

coveralls · 2017-01-14T08:32:55Z

Coverage decreased (-0.06%) to 93.408% when pulling 5a19ecc on marshallpierce:cpu-feature-getauxval-wrapper into c431705 on briansmith:master.

coveralls · 2017-01-14T08:32:55Z

Coverage decreased (-0.06%) to 93.408% when pulling 5a19ecc on marshallpierce:cpu-feature-getauxval-wrapper into c431705 on briansmith:master.

coveralls · 2017-01-14T08:32:55Z

Coverage decreased (-0.06%) to 93.408% when pulling 5a19ecc on marshallpierce:cpu-feature-getauxval-wrapper into c431705 on briansmith:master.

briansmith

Thanks! Sorry to request so many small changes.

briansmith · 2017-01-14T03:47:50Z

crypto/cpu-arm-linux.c

-    if (hwcap2 & HWCAP2_PMULL) {
-      GFp_armcap_P |= ARMV8_PMULL;
+    unsigned long auxval = getauxval(type);
+    // map errors to a zero value


According to http://man7.org/linux/man-pages/man3/getauxval.3.html#RETURN_VALUE, there's no reason to check errno here, since auxval will be zero if an error occurs.

Also, all released versions of Android (AFAICT) fail to set errno at all. The fix is checked into the trunk of Android, but it will be years before we can use it. Therefore, we have to just ignore errno.

Apparently stopping writing Android code years ago wasn't enough to leave these problems behind me. ;)

briansmith · 2017-01-14T03:48:26Z

crypto/cpu-arm-linux.c

-  } entry;
+/*
+ * If getauxval is not available, or an error occurs, return 0.
+ * Otherwise, return the value found.


s/found./found (which may be zero)/.

briansmith · 2017-01-14T03:49:02Z

crypto/cpu-arm-linux.c

-#define HWCAP2_PMULL (1 << 1)
-#define HWCAP2_SHA1 (1 << 2)
-#define HWCAP2_SHA2 (1 << 3)
+#ifdef __linux__


#include <errno.h>

briansmith · 2017-01-14T03:49:29Z

crypto/cpu-arm-linux.c

-  /* Matching OpenSSL, only report other features if NEON is present. */
-  if (hwcap & HWCAP_NEON) {
-    GFp_armcap_P |= ARMV7_NEON;
+#include <errno.h>


Move this up to where I indicated above (#includes go first).

briansmith · 2017-01-14T03:50:08Z

include/openssl/arm_arch.h

@@ -104,6 +104,8 @@
 #define __ARM_MAX_ARCH__ 8
 #endif

+/* Keep in sync with src/cpu_feature/arm_linux/arm_linux.rs */


NIT: End sentences with periods.

briansmith · 2017-01-18T01:41:49Z

src/cpu_feature/arm_linux/auxv.rs

+// from [linux]/include/uapi/linux/auxvec.h. First 32 bits of HWCAP
+// even on platforms where unsigned long is 64 bits.
+pub const AT_HWCAP: Type = 16;
+// currently only used by powerpc and arm64 AFAICT


AT_HWCAP2 is used for 32-bit ARM too, in particular for deteecting crypto instructions on ARMv8 CPUs. For example, consider a 32-bit Android app running on Aaarc64 Android, as is common.

briansmith · 2017-01-18T01:43:26Z

src/cpu_feature/arm_linux/arm_linux.rs

+    #[test]
+    fn armcap_for_hwcap2_all_hwcap2_returns_all_armcap() {
+        assert_eq!(ARMV8_AES | ARMV8_PMULL | ARMV8_SHA1 | ARMV8_SHA256,
+            super::armcap_for_hwcap2(ARM_HWCAP2_AES


NIT: The | should be the last character of the preceding line, instead of the first character of the next line.

briansmith · 2017-01-18T01:43:51Z

src/cpu_feature/arm_linux/arm_linux.rs

+    }
+
+    #[test]
+    fn armcap_bits_arm_8_with_neon_only_getauxv_hwcap_and_all_getauxv_hwcap2_yields_all_features_armcap() {


Let's choose function names that are short enough that the fn <name>() { fits in 80 characters.

briansmith · 2017-01-18T01:44:17Z

src/cpu_feature/arm_linux/arm_linux.rs

+        ret |= ARMV8_SHA256;
+    }
+
+    return ret;


s/return ret;/ret/

briansmith · 2017-01-18T01:44:31Z

src/cpu_feature/arm_linux/arm_linux.rs

+        armcap |= armcap_for_hwcap2(hwcap2);
+    }
+
+    return armcap;


s/return armcap;/armcap/

marshallpierce · 2017-01-18T02:40:21Z

src/c.rs

@@ -41,17 +41,6 @@ macro_rules! define_metrics_tests {
      $expected_align_factor:expr ) =>
    {
        #[cfg(test)]
-        extern {


Leaving this in didn't work when adding unsigned_long because it uses the same size and alignment C globals, which then would get redefined.

Sorry, I'm not sure I understand. Did you try defining GFp_unsigned_long_align and GFp_unsigned_long_size in crypto/crypto.c and using them?

marshallpierce · 2017-01-18T02:40:50Z

src/c.rs

+    static GFp_int8_t_size: u16;
+    static GFp_int8_t_align: u16;
+    static GFp_uint8_t_size: u16;
+    static GFp_uint8_t_align: u16;


So instead, I define them all beforehand. Maybe there are cleverer ways to conditionally define stuff in a macro?

coveralls · 2017-01-18T04:07:01Z

Coverage decreased (-0.3%) to 93.128% when pulling 983abfa on marshallpierce:cpu-feature-getauxval-wrapper into c431705 on briansmith:master.

coveralls · 2017-01-18T04:07:01Z

Coverage decreased (-0.3%) to 93.128% when pulling 983abfa on marshallpierce:cpu-feature-getauxval-wrapper into c431705 on briansmith:master.

coveralls · 2017-01-18T11:49:35Z

Coverage decreased (-0.03%) to 93.444% when pulling 088a656 on marshallpierce:cpu-feature-getauxval-wrapper into c431705 on briansmith:master.

coveralls · 2017-01-18T14:08:27Z

Coverage decreased (-0.03%) to 93.444% when pulling 088a656 on marshallpierce:cpu-feature-getauxval-wrapper into c431705 on briansmith:master.

coveralls · 2017-01-19T06:14:36Z

Coverage decreased (-0.03%) to 93.444% when pulling 66cbd27 on marshallpierce:cpu-feature-getauxval-wrapper into c431705 on briansmith:master.

coveralls · 2017-01-19T06:14:36Z

Coverage decreased (-0.03%) to 93.444% when pulling 66cbd27 on marshallpierce:cpu-feature-getauxval-wrapper into c431705 on briansmith:master.

coveralls · 2017-01-19T09:23:21Z

Coverage decreased (-0.03%) to 93.444% when pulling 66cbd27 on marshallpierce:cpu-feature-getauxval-wrapper into c431705 on briansmith:master.

coveralls · 2017-01-19T09:23:21Z

Coverage decreased (-0.03%) to 93.444% when pulling 66cbd27 on marshallpierce:cpu-feature-getauxval-wrapper into c431705 on briansmith:master.

coveralls · 2017-01-19T09:23:21Z

Coverage decreased (-0.03%) to 93.444% when pulling 66cbd27 on marshallpierce:cpu-feature-getauxval-wrapper into c431705 on briansmith:master.

coveralls · 2017-01-19T09:23:22Z

Coverage decreased (-0.03%) to 93.444% when pulling 66cbd27 on marshallpierce:cpu-feature-getauxval-wrapper into c431705 on briansmith:master.

briansmith · 2017-01-19T20:40:05Z

I've ordered some actual hardware so I can test this, and also I'm digging into the Android code as well.

marshallpierce · 2017-01-20T00:10:20Z

Looks like the Android jobs time out and the aarch64 ones fail aes tests: https://travis-ci.org/marshallpierce/ring/builds/193520619. The last merged PR (my .gitignore lines) had one android job time out, but the aarch64 ones passed: https://travis-ci.org/briansmith/ring/builds/189857834

Is it possible that the arm hardware used is the broken hardware listed in #357?

coveralls · 2017-01-20T03:51:32Z

Coverage decreased (-0.03%) to 93.444% when pulling 350fb4a on marshallpierce:cpu-feature-getauxval-wrapper into c431705 on briansmith:master.

coveralls · 2017-01-20T07:57:56Z

Coverage decreased (-0.03%) to 93.444% when pulling 350fb4a on marshallpierce:cpu-feature-getauxval-wrapper into c431705 on briansmith:master.

coveralls · 2017-01-20T07:57:56Z

Coverage decreased (-0.03%) to 93.444% when pulling 350fb4a on marshallpierce:cpu-feature-getauxval-wrapper into c431705 on briansmith:master.

coveralls · 2017-01-20T07:57:56Z

Coverage decreased (-0.03%) to 93.444% when pulling 350fb4a on marshallpierce:cpu-feature-getauxval-wrapper into c431705 on briansmith:master.

coveralls · 2017-01-20T11:53:16Z

Coverage decreased (-0.03%) to 93.444% when pulling 350fb4a on marshallpierce:cpu-feature-getauxval-wrapper into c431705 on briansmith:master.

coveralls · 2017-01-20T11:53:17Z

Coverage decreased (-0.03%) to 93.444% when pulling 350fb4a on marshallpierce:cpu-feature-getauxval-wrapper into c431705 on briansmith:master.

coveralls · 2017-01-20T16:21:38Z

Coverage decreased (-0.03%) to 93.444% when pulling 350fb4a on marshallpierce:cpu-feature-getauxval-wrapper into c431705 on briansmith:master.

coveralls · 2017-01-20T16:21:38Z

Coverage decreased (-0.03%) to 93.444% when pulling 350fb4a on marshallpierce:cpu-feature-getauxval-wrapper into c431705 on briansmith:master.

coveralls · 2017-01-20T16:21:38Z

Coverage decreased (-0.03%) to 93.444% when pulling 350fb4a on marshallpierce:cpu-feature-getauxval-wrapper into c431705 on briansmith:master.

coveralls · 2017-01-20T16:21:38Z

Coverage decreased (-0.03%) to 93.444% when pulling 350fb4a on marshallpierce:cpu-feature-getauxval-wrapper into c431705 on briansmith:master.

briansmith · 2017-02-01T01:07:57Z

Good news: I have some hardware that can be used to test this now. Hoping to get to the review soon.

I'm not sure what's up with that AAarch64 build. I will look into it. I doubt it's this PRs fault.

briansmith · 2019-01-03T01:46:41Z

Sorry that so much time has passed on this, which seems to have gotten stuck on us not being able to debug some issue with failing tests a long, long time ago.

Now I have some time to work on this again, but a lot has changed. In particular, API level 28 is now the minimum for the Google Play store, so there's no reason to worry about whether getauxval() is missing, so we don't need to deal with weak symbol stuff. Also we don't need to worry, AFAICT, about getauxval() returning incomplete results anymore. I already wrote #748 to remove much of that.

I think then, on ARM Linux, we can use libc::getauxval() and avoid a lot of the complexity in this PR. Sorry that wasn't the case when you originally started this.

@marshallpierce Would you be interested in updating the PR?

marshallpierce · 2019-01-08T03:54:28Z

Hypothetically, but I'm pretty maxed out right now with other projects. Give it another year and we'll see ;)

briansmith · 2019-01-17T07:45:02Z

Give it another year and we'll see ;)

:) I wish I could have predicted that time would make most of the complexity here irrelevant. I have a private branch that does this, which I will submit publicly soon, so I'm going to close this PR.

Thanks for the effort you put into this!

marshallpierce force-pushed the cpu-feature-getauxval-wrapper branch 2 times, most recently from 210c17e to f8a628e Compare January 8, 2017 17:01

marshallpierce commented Jan 8, 2017

View reviewed changes

marshallpierce force-pushed the cpu-feature-getauxval-wrapper branch from f8a628e to e111e1d Compare January 8, 2017 17:04

briansmith reviewed Jan 13, 2017

View reviewed changes

briansmith requested changes Jan 14, 2017

View reviewed changes

Detect cpu features on ARM with getauxval()

ddddb02

marshallpierce added 2 commits January 13, 2017 18:50

Improve some type names and comments and other PR feedback.

9781b03

Get rid of getauxval error detection and just return 0. Inline top le…

ee5b621

…vel of feature detection into init. I agree to license my contributions to each file under the terms given at the top of each file I changed.

marshallpierce force-pushed the cpu-feature-getauxval-wrapper branch from e111e1d to ee5b621 Compare January 14, 2017 03:28

Add licenses.

5a19ecc

I agree to license my contributions to each file under the terms given at the top of each file I changed.

Tweak use declarations for arm init code, make arm_linux public

aae35cc

briansmith requested changes Jan 18, 2017

View reviewed changes

marshallpierce added 2 commits January 17, 2017 18:33

Address various PR comments

5c61439

Fix import, again

983abfa

marshallpierce commented Jan 18, 2017

View reviewed changes

Fix unsigned long size name for Windows

088a656

marshallpierce added 3 commits January 19, 2017 10:37

arm-linux-androideabi uses target_os 'android'

91fc9ea

Apply target_os="android" cfg to arm_linux

4acb512

Update cfg on init use

69763c4

Exclude target_os=android from C GFp_cpuid_setup init

350fb4a

briansmith mentioned this pull request Feb 1, 2017

Cpu feature detection #392

Closed

briansmith mentioned this pull request Feb 1, 2017

Ensure crypto instructions are used on AAarch32 & AAarch64 when available. #387

Open

briansmith closed this Jan 17, 2019

flub mentioned this pull request Mar 6, 2023

Send and receive backup over network using QR code deltachat/deltachat-core-rust#4007

Merged

8 tasks

Detect cpu features on ARM with getauxval() #408

Detect cpu features on ARM with getauxval() #408

Conversation

marshallpierce commented Jan 8, 2017

Choose a reason for hiding this comment

briansmith Jan 13, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

briansmith Jan 13, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

briansmith left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

briansmith commented Jan 14, 2017

briansmith commented Jan 14, 2017

marshallpierce commented Jan 14, 2017

coveralls commented Jan 14, 2017 • edited Loading

coveralls commented Jan 14, 2017

coveralls commented Jan 14, 2017

coveralls commented Jan 14, 2017

coveralls commented Jan 14, 2017

briansmith left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

coveralls commented Jan 18, 2017

coveralls commented Jan 18, 2017

coveralls commented Jan 18, 2017 • edited Loading

coveralls commented Jan 18, 2017 • edited Loading

coveralls commented Jan 19, 2017

coveralls commented Jan 19, 2017

coveralls commented Jan 19, 2017

coveralls commented Jan 19, 2017

coveralls commented Jan 19, 2017

coveralls commented Jan 19, 2017

briansmith commented Jan 19, 2017 • edited Loading

marshallpierce commented Jan 20, 2017

coveralls commented Jan 20, 2017 • edited Loading

coveralls commented Jan 20, 2017 • edited Loading

coveralls commented Jan 20, 2017

coveralls commented Jan 20, 2017

coveralls commented Jan 20, 2017 • edited Loading

coveralls commented Jan 20, 2017

coveralls commented Jan 20, 2017

coveralls commented Jan 20, 2017

coveralls commented Jan 20, 2017

coveralls commented Jan 20, 2017

briansmith commented Feb 1, 2017

briansmith commented Jan 3, 2019

briansmith Jan 13, 2017 •

edited

Loading

briansmith Jan 13, 2017 •

edited

Loading

coveralls commented Jan 14, 2017 •

edited

Loading

coveralls commented Jan 18, 2017 •

edited

Loading

coveralls commented Jan 18, 2017 •

edited

Loading

briansmith commented Jan 19, 2017 •

edited

Loading

coveralls commented Jan 20, 2017 •

edited

Loading

coveralls commented Jan 20, 2017 •

edited

Loading

coveralls commented Jan 20, 2017 •

edited

Loading