Mac M1: loading libcrypto in an unsafe way

@phoe

When trying to install cl+ssl on a new M1 mac using quicklisp, it hangs and is pushing me into LDB, showing this error:

This is SBCL 2.0.11, an implementation of ANSI Common Lisp.
More information about SBCL is available at <http://www.sbcl.org/>.

SBCL is free software, provided as is, with absolutely no warranty.
It is mostly in the public domain; some portions are provided under
BSD-style licenses.  See the CREDITS and COPYING files in the
distribution for more information.
* (ql:quickload :cl+ssl)
To load "cl+ssl":
  Load 1 ASDF system:
    cl+ssl
; Loading "cl+ssl"
.WARNING: /usr/local/Cellar/sbcl/2.0.11/libexec/bin/sbcl is loading libcrypto in an unsafe way
fatal error encountered in SBCL pid 55608 pthread 0x101042e00:
SIGABRT received.

Welcome to LDB, a low-level debugger for the Lisp runtime environment.
ldb>

From #lisp on freenode, @phoe pointed this out while helping me:

cl-plus-ssl/src/reload.lisp

Lines 44 to 49 in ff4634a

    
           (:darwin (:or "/opt/local/lib/libcrypto.dylib" ;; MacPorts 
        
                         "/sw/lib/libcrypto.dylib"        ;; Fink 
        
                         "/usr/local/opt/openssl/lib/libcrypto.dylib" ;; Homebrew 
        
                         "/usr/local/lib/libcrypto.dylib" ;; personalized install 
        
                         "libcrypto.dylib"                ;; default system libcrypto, which may have insufficient crypto 
        
                         "/usr/lib/libcrypto.dylib"))

sbcl is loading libcrypto in an unsafe way orthecreedence/cl-async#181

It seems like a solution is to add a specific version of libcrypto.

I do not really understand the meaning of the "WARNING: /usr/local/Cellar/sbcl/2.0.11/libexec/bin/sbcl is loading libcrypto in an unsafe way".

But if the problem is about the version of libressl, user code can load any version instead of the default behaviour.
See the :CL+SSL-FOREIGN-LIBS-ALREADY-LOADED description in the doc (https://common-lisp.net/project/cl-plus-ssl/)

Let us know if that helps.

I do not really understand the meaning of the "WARNING: /usr/local/Cellar/sbcl/2.0.11/libexec/bin/sbcl is loading libcrypto in an unsafe way".

Seems like "Clients should not load the unversioned libcrypto dylib as it does not have a stable ABI."

https://stackoverflow.com/questions/58272830/ has some pointers to use a different SSL library binary.

By reinstalling Homebrew, sbcl and most importantly openssl making sure that in every step we use rosetta 2 it finally works fine.

I guess some parts of that stack was using arm architecture. The :CL+SSL-FOREIGN-LIBS-ALREADY-LOADED tip was what finally gave me a wrong architecture stacktrace, so thanks :)

It's fixed in my PR.

@fjl

@fjl , does the load request for unversioned lib really crashes the process?

@theothornhill says after fixing his packages everything works for him. So I thought the "unsafe way" message is simply a warning for now, not really breaking the load and crashing the process.

Yes, it does work for me. However, it seems like a known problem, so I might just be lucky for some reason :)

says after fixing his packages everything works for him.

It will work if cffi finds the library in /usr/local/lib first, or in any of the other non-system locations.

So I thought the "unsafe way" message is simply a warning for now, not really breaking the load and crashing the process.

The crash happens when loading "/usr/lib/libcrypto.dylib" because it is a stub whose only purpose is to crash the process. You can find other reports of this, for example:

Closing this - versioned paths were added in #115

FWIW, I just got this on a fresh install. Not sure what I'm doing wrong.

@slyrus

@slyrus , probably none of the versioned paths used at

cl-plus-ssl/src/reload.lisp

Line 53 in d4c95b5

;; System-provided libraries. Must be loaded from files with

and

cl-plus-ssl/src/reload.lisp

Line 101 in d4c95b5

;; System-provided libraries, with version in the file name.

are present on your machine.

Please check what version do you have instead.
You can can load them with https://common-lisp.net/project/cl-plus-ssl/#define-libssl-path.

If that works we can add those versions to the default lists.

Using the latest cl+ssl fixed things. Not sure what's changed between HEAD and what's in quicklisp, but the workaround is good enough for me. Thanks!

I encountered the same error on macOS Monterey M1 and my fix was the following:

(ql:quickload :cl+ssl/config)
(cl+ssl/config:define-libssl-path "/opt/homebrew/opt/openssl/lib/libssl.dylib")
(cl+ssl/config:define-libcrypto-path "/opt/homebrew/opt/openssl/lib/libcrypto.dylib")
(ql:quickload :cl+ssl)

I have the same problem on M1. cl+ssl/config will work, but my project needs deployed to linux.

And I found this patch will work:

--- a/src/reload.lisp
+++ b/src/reload.lisp
@@ -44,10 +44,10 @@
     ;; so we can just use just "libssl.so".
     ;; More info at https://github.com/cl-plus-ssl/cl-plus-ssl/pull/2.
     (:openbsd "libcrypto.so")
-    (:darwin (:or "/opt/local/lib/libcrypto.dylib"                ;; MacPorts
+    (:darwin (:or "/opt/homebrew/opt/openssl/lib/libcrypto.dylib" ;; Homebrew Arm64
+                  "/opt/local/lib/libcrypto.dylib"                ;; MacPorts
                   "/sw/lib/libcrypto.dylib"                       ;; Fink
                   "/usr/local/opt/openssl/lib/libcrypto.dylib"    ;; Homebrew
-                  "/opt/homebrew/opt/openssl/lib/libcrypto.dylib" ;; Homebrew Arm64
                   "/usr/local/lib/libcrypto.dylib" ;; personalized install
 
                   ;; System-provided libraries. Must be loaded from files with
@@ -92,10 +92,10 @@
     ;; (missing TLSv1_[1,2]_XXX methods,
     ;; see https://github.com/cl-plus-ssl/cl-plus-ssl/issues/56)
     ;; so first try to load possible custom installations of libssl
-    (:darwin (:or "/opt/local/lib/libssl.dylib"                ;; MacPorts
+    (:darwin (:or "/opt/homebrew/opt/openssl/lib/libssl.dylib" ;; Homebrew Arm64
+                  "/opt/local/lib/libssl.dylib"                ;; MacPorts
                   "/sw/lib/libssl.dylib"                       ;; Fink
                   "/usr/local/opt/openssl/lib/libssl.dylib"    ;; Homebrew
-                  "/opt/homebrew/opt/openssl/lib/libssl.dylib" ;; Homebrew Arm64
                   "/usr/local/lib/libssl.dylib" ;; personalized install
 
                   ;; System-provided libraries, with version in the file name.

but I don't know why.

Someone needs to dig into the dyld_shared_cache on Monterey and check which libssl versions it supports. I don't have Monterey yet, so can't check.

@theothornhill

@theothornhill , could you add (format t "%load-foreign-library ~A" path) at https://github.com/cffi/cffi/blob/eac416d11bb483c33c277d164b4c6daccd9af452/src/cffi-scl.lisp#L307 and reproduce the crash?

I cannot seem to get cffi to print that line, since it seems to crash before we get there.

An even easier test is to run:

sbcl --non-interactive --no-userinit --eval '(load-shared-object "/opt/local/lib/libcrypto.dylib")'

This reproduces for me too.

@theothornhill

@theothornhill , strange that you can't get the line printed. Maybe remove .fasl files and rebuild (that's an unlined function). On Linux .fals files can be removed by rm -rf ~/.cache/common-lisp/, probably on MacOS it's the same.

@theothornhill

@theothornhill @avodonosov I think the wrong line to edit was mentioned. It should be https://github.com/cffi/cffi/blob/eac416d11bb483c33c277d164b4c6daccd9af452/src/cffi-sbcl.lisp#L366 (cffi-sbcl.lisp instead of cffi-scl.lisp)

Thanks, I wondered if that could be the case. I'll check tonight :)

@avodonosov

@avodonosov @daewok I'm sorry, but I cannot get it to work... I've tried to quickload cffi before quickloading cl+ssl, and also with manually recompiling that function, and the functions it is referenced from, since it's an inlined function.

What am I missing?

Difficwlt to say what is missing...

@theothornhill

@theothornhill @avodonosov I think the wrong line to edit was mentioned. It should be https://github.com/cffi/cffi/blob/eac416d11bb483c33c277d164b4c6daccd9af452/src/cffi-sbcl.lisp#L366 (cffi-sbcl.lisp instead of cffi-scl.lisp)

Using your reference I found out that 'try-foreign-library-alternatives' function in libraries.lisp is loading each library from the library-list parameter without checking if its present at specified location. Here is my solution. For me this fixes the sbcl crashes while loading libcrypto library.

@theothornhill

@theothornhill Maybe you can (trace sb-alien:load-shared-object) instead.

@aniketnarvekar That is not a good solution. It looks like your patch is at cffi/cffi#193 (it was mentioned in an earlier comment, not sure why it was deleted).

First, it will not work when loading a system library. You typically do not provide the full path to those, so the probe-file will return NIL except in the unlikely event that *default-pathname-defaults* is bound to the directory containing the library.

Second, Apple has decided to remove ~all system libraries from the file system and store them in a cache elsewhere. So probe-file will never return non-NIL for those. Apple says the correct way to test for library existence is to dlopen them and check for an error. That makes this bug extra rich since it seems that dlopen("/some/non-existent/path/libcrypto.dylib") causes the process to abort instead of returning an error.

Anyone sees a problem if I remove all non-standard paths for Darwin - leaving only /usr/lib/libssl.NN.dylib ?

Anyone sees a problem if I remove all non-standard paths for Darwin - leaving only /usr/lib/libssl.NN.dylib ?

Seems reasonable, especially since cl+ssl/config was introduced.

Others above already mentioned that moving files to /usr/local/lib fixed it, but here's some explicit steps for anyone else struggling with this on osx (I hit this after updating to Monterey),

brew install openssl (probably installed to /usr/local/opt/openssl@3, or a higher @)
brew link openssl doesn't work, (or any flavor of brew link --force openssl@3) so you need to symlink this custom openssl install manually so cl+ssl can find it
based on https://github.com/fjl/cl-plus-ssl/blob/3aaba3feb48e0e23b09c46cc7d51a89868e2ed80/src/reload.lisp#L47 it'll look for /usr/local/lib/libssl.dylib / libcrypto.dylib
so we need to link to the above (after installing with brew):

In total:

brew install openssl
ln -s /usr/local/opt/openssl\@3/lib/libcrypto.dylib /usr/local/lib/libcrypto.dylib
ln -s /usr/local/opt/openssl\@3/lib/libssl.dylib /usr/local/lib/libssl.dylib

On macOs only load custom installation(s) of OpenSSL if they are pres…

@aniketnarvekar

@aniketnarvekar, thank you for confirming a non-existing path crashes the app. I was actually curious to know exactly what path it is - is it one of the path specified in reload.lisp or cffi also falls-back to some default path which causes the crash (reading the cffi code I think it should not, but was curious to be sure).

As for checking the path presence, while @daewok is right that a generic cffi patch is not good for that, we can do that for our specific paths on cl+ssl level. In the commit referenced above I implemented that.

So now we try custom paths only if they are present. I hesitated to remove them altogether - do not want to cause inconvenience for people who may depend on them.

For the record, the custom paths where added in #56.

I'd appreciate if someone tested the last version and confirmed it works on macOS where it previously crashed.

Include re-detection of custom OpenSSL installations into the RELOAD …

When detecting custom OpenSSL installations for macOS, use a run-time…

Navigation Menu

Repository navigation

Mac M1: loading libcrypto in an unsafe way #114

19 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

	(:darwin (:or "/opt/local/lib/libcrypto.dylib" ;; MacPorts
	"/sw/lib/libcrypto.dylib" ;; Fink
	"/usr/local/opt/openssl/lib/libcrypto.dylib" ;; Homebrew
	"/usr/local/lib/libcrypto.dylib" ;; personalized install
	"libcrypto.dylib" ;; default system libcrypto, which may have insufficient crypto
	"/usr/lib/libcrypto.dylib"))

Mac M1: loading libcrypto in an unsafe way #114

Description

Activity

avodonosov commented on Jan 25, 2021

phoe commented on Jan 25, 2021

theothornhill commented on Jan 25, 2021

fjl commented on Jan 31, 2021

avodonosov commented on Jan 31, 2021

theothornhill commented on Jan 31, 2021

fjl commented on Jan 31, 2021

avodonosov commented on Mar 6, 2021

slyrus commented on Oct 9, 2021

avodonosov commented on Oct 10, 2021

slyrus commented on Oct 10, 2021

ngn999 commented on Nov 2, 2021

fjl commented on Nov 4, 2021

19 remaining items

theothornhill commented on Nov 19, 2021

avodonosov commented on Nov 21, 2021

daewok commented on Nov 22, 2021

theothornhill commented on Nov 22, 2021

theothornhill commented on Nov 23, 2021

avodonosov commented on Nov 23, 2021

aniketnarvekar commented on Nov 24, 2021

daewok commented on Nov 24, 2021

avodonosov commented on Nov 27, 2021

daewok commented on Nov 29, 2021

jaemk commented on Dec 7, 2021

avodonosov commented on Dec 9, 2021

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions