New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Segmentation fault in warp TLS on ARM platform #499

Closed
andreyk0 opened this Issue Dec 28, 2015 · 5 comments

Comments

Projects
None yet
2 participants
@andreyk0

andreyk0 commented Dec 28, 2015

Apologies if this is not the right place to ask about platform-specific issues.

I have an easy to reproduce crash (segfault), this is the smallest piece of code I could narrow it down to: https://gist.github.com/andreyk0/5ffd9dd97fca4a02f22d

Threaded runtime seems significant (can't get it to crash without -threaded flag), on a single-cpu ARM board it takes a few tries, on a dual-core (A20) board it crashes on the first try.
Also, responseFile seems significant as well, didn't crash with bytestring (even if read from the same file)
A simple curl -k -v 'https://myhost:8443/' triggers the crash.

Build environment:
stack Version 0.1.10.0 arm
ghc: 7.10.3 (official build downloaded from the GHC ARM link)
GNU gold (GNU Binutils for Debian 2.25) 1.11
LLVM 3.5.2
Debian/jessie image (run via QEMU)

Execution environment:
Debian/jessie
Linux lime2 4.2.6-sunxi #1 SMP Sun Nov 29 10:33:44 CET 2015 armv7l GNU/Linux
https://www.olimex.com/wiki/A20-OLinuXino-LIME

I'm not sure how to produce a fully debug-enabled binary (including all the libs) with stack lts build.
In the original project, from which this small example is derived, I've switched cryptonite lib and a few others to a local dependency (built with additional ghc flags) and gdb showed it crashed somewhere around a call to cryptonite_aes_generic_gcm_encrypt. Some times a bit earlier, some times inside or a bit after, depending on debug prints I've added elsewhere. Headers tend to make it through, file doesn't. Best I could tell, input (the one being encrypted) bytestring gets somehow corrupt.

Thanks for taking a look!

@andreyk0

This comment has been minimized.

andreyk0 commented Dec 30, 2015

I've tried to narrow it down a bit more, it crashes because 'pread' in warp/Network/Wai/Handler/Warp/SendFile.hs returns -1 (error).

E.g. running strace
8440 pread(11, 0xb6100534, 5, 18446744072469087376) = -1 EINVAL (Invalid argument)

Offset is messed up and -1 taken as a result causes it to crash down the line inside encryption methods.

What's weird is that offset value from the app POV is actually 0.
Debug tracing it in readSendFile shows as much.
The weird part is that adding debug trace (to print offset value) to positionRead "fixes" the problem, it prints offset 0, pread call succeeds and there's no crash.

I have no idea how to debug it beyond that, maybe someone with the knowledge of GHC and ARM will read this...

Still, even if you dismiss it as a platform-specific fluke, positionRead could probably benefit from adding an error check for -1 or at least an assert.

@kazu-yamamoto kazu-yamamoto self-assigned this Jan 12, 2016

@kazu-yamamoto

This comment has been minimized.

Contributor

kazu-yamamoto commented Jan 12, 2016

Good catch. Thanks. I will add error handling for pread.

@kazu-yamamoto

This comment has been minimized.

Contributor

kazu-yamamoto commented Jan 12, 2016

I pushed the patch above to master. Please test.

@andreyk0

This comment has been minimized.

andreyk0 commented Jan 14, 2016

👍 LGTM, thanks for the fix!

@kazu-yamamoto

This comment has been minimized.

Contributor

kazu-yamamoto commented Jan 15, 2016

A new version has been released.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment