[n5110 and others] libressl broken on linux < 3.17

As already mentioned in pmbootstrap#1662 (closed), the new libressl version needs a syscall not available in linux before 3.17. I have just upgraded my Samsung Galaxy Note 8.0 tablet (n5110) with linux 3.0.101 and I can confirm that this also affects my device. I cannot pull via https from the pmOS repos (crashes reproducibly) and also Falkon crashes on certain occassions like when typing a URL in the address bar. Nheko crashes directly when starting, too.

@ollieparanoid mentioned in the chat that it might be possible to patch the kernels to support this. I assume this would be necessary for all devices with a kernel version below 3.17.

changed the description

By Michael Hamann on 2018-10-05T18:34:03

changed the description

By Michael Hamann on 2018-10-05T18:42:27

Do note that Alpine is planning to move back to OpenSSL in the future. Does anyone know if they also use a syscall not supported before 3.17?

By Bart Ribbers on 2018-10-05T19:33:14

Further investigation reveals: libressl is not to blame for this. This is due to a musl libc update that adds getentropy() and getrandom(). When libressl detects that these are present, they are used and when they fail, it triggers a SIGKILL. Contrary to what is suggested in pmbootstrap#1662 (closed), the file crypto/compat/getentropy_linux.c is not used. If it was used, libressl would already fall back to reading from /dev/urandom if the syscall fails. Instead, the getentropy() implementation of musl libc is used in crypto/compat/arc4random.c, fails and then in crypto/compat/arc4random_linux.h in _getentropy_fail SIGKILL is triggered. Note that according to the configure output, arc4random is indeed missing but getentropy() is found.

As this is in musl libc, I assume that this affects basically all crypto implementations and possibly further code that wants to get random numbers. [edit] A quick search reveals: this also affects qtbase/QRandomGenerator.

By Michael Hamann on 2018-10-05T21:23:41

Due to the widespread use of the syscall (searching reveal issues that talk about using it in basically any programming language or library that deals with random numbers) I assume that backporting it is the only possible solution (apart from mainlining). There are some pointers in this issue of OrangePiLibra. As far as I understand, the original implementation has been further improved/fixed in certain regards.

By Michael Hamann on 2018-10-05T21:34:50

Terrific research @michitux!

As far as I understand, the original implementation has been further improved/fixed in certain regards.

This goes for just about everything else in the vendor kernels, they are full of security holes that would be patched if we could use upstream kernels instead. From that perspective this won't make much of a difference imho.

The issue you've linked points to a pine64 branch with backport patches:

• https://github.com/longsleep/linux-pine64/commit/fdb4d6b6a5bdd314a5170211fda04b2053b3a415
• https://github.com/longsleep/linux-pine64/commit/b83483f17e43280f3e7df2d0f20c7a9cc2800c58

Could you try to apply those two to your kernel and check if that fixes the issue?

By Oliver Smith on 2018-10-10T18:53:16

mentioned in merge request !54 (merged)

By Valentin Marinov on 2018-10-19T08:12:08

These patches are for 3.10. The n5110 unfortunately is stuck on 3.0. I would rather try to further backport e.g. the patches found at https://github.com/LineageOS/android_kernel_sony_apq8064/search?q=getrandom&type=Commits which have already been backported to 3.4. Note that 3.0 doesn't even have "arch/x86/syscalls/syscall_64.tbl" so these patches also definitely won't apply cleanly (but that file is irrelevant anyway as far as I understand). Also the number of syscalls present for arm is different. I have no idea about these numbers but I suspect we should not change them. The patches in https://github.com/archlinuxarm/PKGBUILDs/tree/master/core/linux-imx6 seem to suggest that. I don't know if I'll find time to look into this anytime soon.

By Michael Hamann on 2018-11-07T18:49:05

mentioned in merge request !69 (merged)

By Michael Hamann on 2018-11-11T10:07:59

mentioned in commit aefde918

By Michael Hamann on 2018-11-27T06:58:15

Added to the wiki. Doesn't seem like we can fix this for all kernels in a feasible way, so for those who it concerns, they can attempt a backport like @michitux did it.

https://wiki.postmarketos.org/wiki/Troubleshooting:kernel#TLS_.28SSL.2FHTTPS.29_is_broken.21

By Oliver Smith on 2018-12-26T18:00:54

closed

By Oliver Smith on 2018-12-26T18:00:55

mentioned in commit wiki@76c88d2c

By postmarketOS Wiki bot on 2018-12-26T18:42:44

I think you used the wrong header there (at least in the mobile view it displays your section under another section)

By Luca Weiss on 2018-12-27T12:20:42

I think you used the wrong header there (at least in the mobile view it displays your section under another section)

Thanks, fixed!

By Oliver Smith on 2018-12-30T17:51:46