getrandom.cr fails in Alpine under Docker (crystal 1.13.2) #15034
Comments
|
I'm assuming the same code using |
Blacksmoke16
added
kind:bug
|
This failure only affects the interpreter. Compiled Crystal works fine. The interpreter is an experimental feature and missing support for musl libc. This is tracked in the meta issue #11555 (although at this point I'm not aware of further details). |
|
AFAIR we don't call the libc |
|
We specifically use crystal/src/crystal/system/unix/getrandom.cr Lines 6 to 19 in cde543a |
|
The real problem is that whereas the syscall returns the negative of the crystal/src/crystal/system/unix/getrandom.cr Lines 105 to 110 in cde543a As |
|
I am in the process of testing #15035 and suspect it should fix the issue for me, but I wonder why not use the musl libc function that imitates the standard libc function? Either way, I like making the Crystal function match the syscall itself is better than matching the libc functions. The less libc dependencies, the better. |
|
When the feature was implemented That was in 2017. The libc symbol was released in glibc 2.25, and even the EOL Ubuntu 18.04 for example had glibc 2.27. I think it's fine to assume that the symbol exists nowadays, and we can simplify the implementation to always use the libc call. That would avoid the init check and the urandom fallback. |
|
Hm I can still reproduce this issue even with #15035 🤔 $ docker run --rm -it alpine:edge
$ apk add crystal git
$ git clone https://github.com/crystal-lang/crystal
$ cd crystal
$ bin/crystal i
Crystal interpreter 1.13.2 (2024-08-29).
EXPERIMENTAL SOFTWARE: if you find a bug, please consider opening an issue in
https://github.com/crystal-lang/crystal/issues/new/
Unhandled exception: getrandom: Bad address (RuntimeError)
from raise|219|1|/crystal/src/raise.cr
from sys_getrandom|112|11|/crystal/src/crystal/system/unix/getrandom.cr
from loop|143|5|/crystal/src/kernel.cr
from sys_getrandom|105|5|/crystal/src/crystal/system/unix/getrandom.cr
from getrandom|89|20|/crystal/src/crystal/system/unix/getrandom.cr
from random_bytes|56|7|/crystal/src/crystal/system/unix/getrandom.cr
from /crystal/src/crystal/hasher.cr|83|3|/crystal/src/crystal/hasher.cr |
|
There is something wrong with It returns a slice whose pointer is the same as the size, hence the Bytes.new(16)[0, 4].to_unsafe # => Pointer(UInt8)@0x4
Bytes.new(16)[4, 8]?.try &.to_unsafe # => Pointer(UInt8)@0x8 |
The `getrandom(2)` syscall was added in 2017 and at the time we couldn't expect the glibc 2.25 to be widely available, but we're in 2024 now, and even Ubuntu 18.04 LTS that is now EOL had a compatible glibc release (2.27). I assume musl-libc also added the symbol at the same time. We can simplify the implementation to assume `getrandom` is available, which avoids the initial check, initialization and fallback to urandom. We still fallback to urandom at compile time when targeting android api level < 28 (we support 24+). An issue is that executables will now expect glibc 2.25+ (for example), though the interpreter already did. We also expect kernel 2.6.18 to be compatible, but `getrandom` was added in 3.17 which means it depends on how the libc symbol is implemented —does it fallback to urandom, does it fail? Related to #15034. Co-authored-by: Johannes Müller <straightshoota@gmail.com>
Dockerfile:
I did test and confirm that running docker with --privileged does not impact the failure.
I found a duplicate at #12967 and didn't understand why it was marked "completed".
It seems the error should not be musl-specific as I don't see how musl would change the arguements to the syscall. It looks instead that
crystalmight be depending on only certain errors and a failure mode of providing a bad address isn't properly handled.strace:
https://git.musl-libc.org/cgit/musl/tree/src/linux/getrandom.c:
This seems identical to the way libc handles it:
The text was updated successfully, but these errors were encountered: