29 ms·
macOS 11: copies of dynamic libraries are no longer present on the file system
- afandian 6y agoHow common is this technique for loading libraries? How about in the kind of POSIX tools that are available, but not exclusive to, on mac os (sucha as bash, termux, vim, git, apache etc)?
- zaarn 6y agoThe old code checks for the filepath to be present before attempting to dlopen it. The new way requires you to dlopen the path. This is very meh because dlopen already executes code from the library, so if you didn't want that, good luck. (glibc and some other core libs like openssl like to detect plugins by probing the paths for libs and only loading them when necessary)
- afandian 6y agoYeah. So I understand it has been considered best practice to check the file before opening it? Does that mean we can assume that most well-written programs will follow the pattern and break on mac os? I would have thought that even if Apple did make this change they could trap the fopen or whatever and return something useful based on a heuristic? It wouldn't be the first time that they put exceptions and heuristics in for software compatibility.
- chrisseaton 6y ago> So I understand it has been considered best practice to check the file before opening it? Check it... for what?
- coldtea 6y agoFor presence...
- chrisseaton 6y agoWhy do you need to separately check for presence before you use dlopen? If it's not there dlopen will give you a nice error message - no need to check yourself. Are you currently checking files are there before you dlopen them? How do you avoid a race between the stat and the dlopen? What happens if the file is removed between them? Seems broken and you shouldn't be doing this in the first place.
- zaarn 6y agoIt is usually unlikely that a file will be removed between stat and dlopen, such errors occur rarely. Even more rarely when the file happens to be a systems lib or plugin lib. Some errors occur rarely enough that it isn't worth worrying about.
- unilynx 6y agoIt has never been good practice to check before open - open first, then check. And if you're creating a file, use exclusive mode, don't check first. You're opening yourself up to a lot of race conditions otherwise, and this has been the source of many security vulnerabilities
- jdub 6y agoNON-system libraries? Lots. e.g. reading through a directory of dynamically loadable plugins System libraries (depending how Apple defines that)? Unusual.
- lultimouomo 6y agoI would expect this to impact mainly build systems, and I would expect to impact them really hard. But to be honest this is just a gut feeling. On the other hand, I am sure that Apple has thought this through, as we all know developer experience is of paramount importance for them.
- DCKing 6y agoNot a macOS dev but maybe one can clarify: is the title "No more system shared libraries in macOS 11" actually true? The documentation reads to me as a restriction on how you read dynamic libraries (is using only dlopen controversial here? also just trying to understand), not on which system libraries are actually there. It seems dlopen with custom system dylibs would still work if there is also a means to get your dylibs in the system cache? Based on that piece of docs alone I see no reason to grab my pitchfork just yet. Anyway, I was expecting a few shitstorms to start happening over macOS 11. Apple not announcing any major deprecations (edit: or removals) for this transition - even OpenGL/CL is still there, depecrated - was suspicious.
- akmarinov 6y agoOpenGL was deprecated last year
- kalleboo 6y agoEveryone thought it was deprecated last year so that they didn't have to support it on ARM Macs, but it appears (not 100% confirmed until people actually get these things) like it is still there and working on ARM Macs (albeit deprecated)
- pjmlp 6y agoIt is officially documented as being available in ARM Macs.
- kalleboo 6y agoYeah but prerelease documentation has been wrong before.
- oneplane 6y agoIsn't that why it's called "Pre" release? If there is a chance of changes between the release and what comes before that I'd say that makes sense. Say a 'release' turns out to have a discrepancy between documentation and reality, that's when the problems start to mount.
- jonny383 6y agoFor end users, this transition will be fairly seamless. For developers, let the nightmares begin.
- celeritascelery 6y agoI assume this is for privacy (an app can’t fingerprint you by looking at which libraries you have) but macOS is starting to become a terrible dev environment. Why are they locking down my device from me?
- antishatter 6y agoWhen you say "Starting To" I presume you mean from about 2015 on. It's clear Windows is trying to pick up slack and also be cloud developer friendly with WSL integration. Apple sticking with Intel and now reverting to a terrible proprietary cpu architecture, locking software down more and more, releasing pro versions with inadequate options and keyboard all acts to ensure they lose their status as top developer environment Before they dropped powerpc for intel, no one would have considered using a mac for dev work. It's clear they don't understand the developer market at all or are only interested in Mobile because the revenue is insane. They had a good ten years as the best dev environment but as they say "The King is dead, long live the King".
- tannhaeuser 6y ago> Apple sticking with Intel and now reverting to a terrible proprietary cpu architecture Are you referring to the ARM instruction set generally being more open for custom instructions? Going by the number of licensees and producers of ARM silicon, I'd say ARM is less proprietary compared to x86 which is basically just produced by Intel, AMD, and a Chinese licensor AFAIK.
- quantummkv 6y ago> Apple sticking with Intel and now reverting to a terrible proprietary cpu architecture ARM is more open than x86. In fact, you could start your own ARM chip design company today. Which is something you cannot do with x86 at all, even if your were to do a complete takeover of AMD or Intel. > Before they dropped powerpc for intel, no one would have considered using a mac for dev work. DHH wrote Ruby on Rails on a Powerbook. Microsoft did all the development of the original XBox on PowerPC Macs. A lot of developers used macs before Intel, and they will use them after Intel. > They had a good ten years as the best dev environment but as they say "The King is dead, long live the King". Given the Frankenstein horror show that is Windows with WSL2 and the terminal lack of a polished working GUI in Linux, Mac is still the best dev environment unless you are doing some platform specific work.
- choeger 6y agoIf I read this correctly, this is absolutely bonkers. Basically the "System libraries" do not exist as files anymore? So they just deprecated normal dynamic linking for a subset of libraries? But as I know the Mac folks around there, they are going to swallow it. Because, uhm,..., It's Apple.
- chrisseaton 6y ago> this is absolutely bonkers Why do you care if the files are on the disk or not though? What are you using that for?
- choeger 6y agoFor linking.
- nojito 6y agoEssentially breaks many fingerprinting strategies. This is a very good change.
- loeg 6y agoCan you elaborate on what fingerprinting attack is broken by this model?
- quotemstr 6y agoBecause now, you can only probe for the existence of a specific shared library. You can't just enumerate all the libraries that happen to be available. That said, this change appears to apply only to system libraries --- how much fingerprinting entropy is contained in the system library list that isn't already contained in the OS version information?
- plorkyeran 6y agoZero, because the set of system libraries is fixed and doesn't vary between machines.
- oefrha 6y agoNo more system dylibs on the filesystem; only loadable with dlopen (from shipped dyld cache). The title is a shocker that sounds like system libraries are no longer dynamically linked... Edit: Since this comment is currently at the top, here's a better link to the source: https://developer.apple.com/documentation/macos-release-notes/macos-big-sur-11-beta-release-notes#:~:text=built-in%20dynamic%20linker%20cache https://developer.apple.com/documentation/macos-release-note... (using scroll-to-text fragment[1] since there's unfortunately no usable anchor to the specific entry; not supported in non-Chromium browsers at the moment, in that case search for "built-in dynamic linker cache"). [1] https://caniuse.com/#feat=url-scroll-to-text-fragment https://caniuse.com/#feat=url-scroll-to-text-fragment
- enedil 6y agoI agree with it, the title should be changed. I thought the same and it's the only reason I looked at the comments.
- ohgodplsno 6y ago>not supported in non-Chromium browsers at the moment Not supported in any-browser-that-follows-the-spec, really, considering scroll-to-text is a google made, unilaterally implemented, nonstandard extension (https://wicg.github.io/scroll-to-text-fragment/ https://wicg.github.io/scroll-to-text-fragment/)
- oefrha 6y agoI never said it's a standard. Anyway, I'm interested in providing information about dyld cache (and as an aside explaining why my best-effort link doesn't work in some browsers), not encouraging more tribalistic Chrome/anti-Chrome debate, so we can stop right here.
- jefftk 6y agoMore context: https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/zlLSxQ9BA8Y/uw9HcwIVDQAJ https://groups.google.com/a/chromium.org/forum/#!msg/blink-d...
- 6y ago
- nojito 6y agoClearly a change for privacy reasons. You aren’t allowed to go fishing around the system anymore.
- gspr 6y ago> You aren’t allowed to go fishing around the system anymore. Sure you can. You'll now `stat` around for everything you did before, but now you'll have to `dlopen` the system libraries instead. Surely no privacy win?
- nly 6y agoIsn't this the model that has been encouraged on Windows forever with COM, WinRT and .NET etc? When you consume an API in one of those environments you don't have to worry about the location of the physical assets (library files). I don't see the big deal as long as app local copies of e.g. curl can still be used
- Hello71 6y agoSounds like it to me. Similar to Windows WinSxS directory, or system32 redirection, or Program Files (x86).
- jjoonathan 6y agoNow we need a /System/Library/WOWARM to contain old x64 libraries and /System/Library/AMD64 to contain arm libraries and it will be perfect!
- djxfade 6y agoI know that you are ironic here, but for the uninformed, macOS supports "fat" binaries, where the machine code for multiple archetictures can be embedded in the same bundle
- brian_herman__ 6y agocan we get a binary with 68k, powerpc, x86, and arm and call the binary .fatso
- saagarjha 6y agoSadly by tradition standalone dynamic libraries on macOS end in "lib", as in "dylib" or "jnilib", unless there is a good reason to not do so (pam, for example).
- jjoonathan 6y agoYep, and for the sake of making sure everyone can appreciate the joke I suppose I should explain the other half. During the 32 -> 64 bit transition, Windows took the opposite approach: instead of packing both architectures into a single "fat" library file, they would separate them into different folders. 64 bit libraries would be "native" and go into the usual system library folder and legacy 32 bit versions would go into a new "Windows on Windows" emulation folder. Good so far. The problem is that the usual system library folder was /Windows/System32 which alludes to 32-bit-ness but will now hold 64 bit libraries. That's a bit facepalm, but sacrifices had to be made for compatibility, or something (I would assume). For the emulation folder they chose /Windows/SysWOW64 because "Windows on Windows" ran on 64 bit and emulated 32 bit. Fair enough, I suppose, but now a folder with a name alluding to 64-bit-ness will contain 32 bit libraries, so we have a double facepalm: C:\Windows\System32 is where the 64 bit libraries live C:\Windows\SysWOW64 is where the 32 bit libraries live This is silly enough that it deserves a good-natured elbow-jab every now and then.
- AlexandrB 6y agoNot to be paranoid, but with this change what stops Apple from silently shipping libraries with backdoors/surveillance if requested by law enforcement. How would a security researcher catch the change without being able to examine the library files?
- hellcow 6y agoThey don't need to ship a backdoor because all files in iCloud (photos, documents, etc.) aren't E2E encrypted anyway. According to Reuters they readily share that with the government, despite all their FBI-thwarted-yet-again posturing in the press. Not to mention they could just backdoor the kernel, and since that's not open-source, good luck detecting that.
- chungus_khan 6y agoAnd of course they do, surveillance is the law in the US. They are expected to comply.
- admax88q 6y agoIf you're worried about those types of things you shouldn't be using proprietary operating systems, there's a million ways Apple can backdoor your system without you knowing
- chrisseaton 6y ago> How would a security researcher catch the change without being able to examine the library files? How would you know that Apple was loading what was on disk, before this change?
- loeg 6y agoAfter dlopen() you are free to examine the in-memory contents, including writing them out to disk if you like. Apple as an attacker could easily hide a backdoor in either model.
- Hackbraten 6y agoIt’s pretty trivial to re-extract the dylibs from the cache. For example, jtool2 does it for iOS, where Apple has already purged system dylib files.
- icedchai 6y agoTo think, the Amiga was doing something like this in the 80's. The "OpenLibrary" call would transparently access shared libraries either in ROM, already loaded into memory, or on disk.
- sys_64738 6y agoWell ARM is a 1980s technology so seems apt.
- messe 6y agox86 is 1980s. POWER is 1990s. MIPS is 1980s. Sparc is 1980s. What would you prefer they use? Itanium? RISC-V?
- xenophonf 6y agoItanium is 2000s. RISC-V is 2010s. Apple could make a great leap forward by adopting the Mill, an ISA so novel that it hasn't even been released yet!
- fnordsensei 6y agoThe Mill: https://en.wikipedia.org/wiki/Mill_architecture https://en.wikipedia.org/wiki/Mill_architecture
- deleted 6y ago[deleted]
- icedchai 6y agoToo bad Alpha died. Those machines were like lightning (for the 90's, anyway.)
- messe 6y agoIIRC even Windows NT could run on Alpha. I wonder if computing would've been different had we gotten a modern 64-bit architecture with very little legacy become commonplace in the 90s. Makes me think of the Tanenbaum quote from 1992: "Of course 5 years from now that will be different, but 5 years from now everyone will be running free GNU on their 200 MIPS, 64M SPARCstation-5".
- dfalzone 6y agoHow will we write our own libraries, then?
- dfalzone 6y agoHow would we write our own libraries?
- tannhaeuser 6y agoI guess just as before, by using install_name_tool to burn the install location into a .dylib (with special vars), and then link against it? The question seems rather, how to link against system libs if these are no longer palpable files.
- Spivak 6y agoI think this is a good change. It's eliminates a potential avenue of accidentally doing the wrong thing but not noticing because it "works on my machine."
- loeg 6y agoIn what scenario does it eliminate this?
- olliej 6y agoI have had to deal with bugs in the past caused by people using incorrect case for paths to dlopen(), etc. Lots (I wouldn't be surprised if most) osx devs use case sensitive filesystems, but the default in case-insensitive, and so dlopen(path) fails if you have (say) "/system/..." instead of "/System/..."
- messe 6y agoPretty similar to what they do with kexts on iOS.
- sjnu 6y agoFrees up a gig or two of disk space. Good.
- loeg 6y agoFrees up cheap disk space by moving the library contents to expensive RAM? That doesn't seem like a good thing. And it also doesn't seem possible — you want system libraries to survive reboot. Presumably these files exist somewhere on disk, just hidden.
- saagarjha 6y agoNot hidden, just inside the ROSP partition at /System/Library/dyld.
- plorkyeran 6y agoThe dylib cache is stored on disk. It's saving disk space by only having that copy of the libraries instead of two copies.
- loeg 6y agoWhat would the second copy be?
- viraptor 6y agoCan anyone come up with a reason this would be preferable to having just the index cached for the linker and handing out mapped memory / open files instead? What's the benefit here over essentially ld.so.cache with bells and whistles?
- bdash 6y agoIt reduces disk space. Historically the dyld_shared_cache has been a pre-bound copy of most system libraries that is mapped into memory once and then shared across all processes. It was updated automatically by the system at various times, and if a given system library was determined to be newer then the dynamic linker would simply load it from disk. The result of this was that for most system libraries you ended up with two copies on disk: one at the normal location, and one within the shared cache. Now only the latter copy exists, and Apple ships it directly rather than creating it on each machine from the copy of the system libraries that they ship.
- beervirus 6y agoDisk is cheap, and we're not talking about a huge amount of space. Surely there's a better justification.
- kolinko 6y agoOn lower end laptops it isn’t cheap. Also these savings add up - a few hundred MB here and there and you end up with a system that’s 10GB lighter on a laptop that has just 128/256GB of space.
- stephc_int13 6y agoI don't see why it should be any different.
- eugenekolo 6y agoIf I understand correctly, this is just the same behavior as iOS's "dyld_shared_cache" which is basically all the system shared libraries stuffed into a single file. https://iphonedevwiki.net/index.php/Dyld_shared_cache https://iphonedevwiki.net/index.php/Dyld_shared_cache
- saagarjha 6y agoCorrect, all the system libraries can be now found in the dyld shared cache can be found in /System/Library/dyld/dyld_shared_cache_x86_64(h) (it's moved in Big Sur!).
- tobyhinloopen 6y agoSo the title is wrong? The libs are just not directly accessible from the file system
- 0x0 6y agoThis is mildly interesting but not much more than that. Who cares if the set of system libraries are available in a series of separate dylib files, instead of being packed together in one mega archive? Most comments here on HN seem to misunderstand what this is.
- asveikau 6y agoPeople writing third party linkers or debuggers is one. I often dig at shared libraries using tools like nm to see what functions are where.
- 0x0 6y agoI'm sure there will be a way to unpack the mega archive and run nm (or maybe even run nm directly on the mega archive). Relax :)
- saagarjha 6y agoSadly: $ nm /System/Library/dyld/dyld_shared_cache_x86_64h /Applications/Xcode-beta.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/nm: error: /System/Library/dyld/dyld_shared_cache_x86_64h: Invalid argument. But yes, there are tools to pick apart a shared cache, some which work better than others.
- asveikau 6y agoI never said I wasn't relaxed about it. I don't even use a Mac much. But the platform does seem to have been in a multi-year process of technical decline, and much of that does speak to a "we know better than you, and everybody else" attitude.
- prewett 6y agoA number of the changes that Apple has been making seem to be security related. One reason to just dlopen() rather than stat() and dlopen() is the race-condition, which an attacker could use to get a program to use the wrong library. Similarly macOS' locked-down root partition. Checking hashes of binaries is also for security, to make sure the binary you're running is the one the developer thought they were giving you. So on the one hand the platform is in "slow technical decline" yet we (HN) claim to value security. It seems to me that the platform is doing well technically. We all remember the mess Microsoft had 10 years ago with security vulnerability du jour; Apple seems to be pre-emptively protecting its users. I submit that the "technical decline" is really "macOS is changing from a freewheeling Unix system to a secure system" and people here want to be cowboys and artists with their own private filesystem canvas. I understand the frustration, but Linux still exists. Apple isn't in the business of making a dev playground, but a computer that Just Works for people. It seems to me there isn't a technical decline, it's that HN is revealing itself to value the plasticity of traditional Unix over security (now that security has gotten good enough). I expect that SELinux has similar chafing restrictions, the only difference is that Linux is more of a set of parts so you get to (must) choose how you put those tools together.
- qppo 6y agotwo questions Does this break pkg-config? What about fishing for dylibs in .bundle directories that may be installed in multiple locations?
- ddevault 6y agoIs there a good term which distinguishes a general-purpose OS (Unix, Windows, Plan 9, etc) from operating systems like Android, iOS, Windows RT, etc? The term "operating system" is being overloaded to ship systems which are really more of a graphical shell than a classical operating system. The moves to lock down operating systems, ostensibly made for "security" reasons but conveniently centralizing power and authority with the vendor at the same time, are being marketed to consumers as the same kind of product as a conventional operating system while in fact being profoundly different.
- saagarjha 6y agoI think you're in the wrong thread.
- coldtea 6y agoAre those guys in the twitter thread looking for an excuse to vent? It's a minor annoyance at best, and with security/speed benefits...
- john_alan 6y agoYeah I mean what system libs do people even use? Does this affect homebrew?
- quotemstr 6y agoGood. Apple is basically the only entity seriously looking at dynamic linking performance these days. We can do a lot better in the ELF world. We should not only copy dyld's closure cache, but also teach the kernel to do relocations on demand, like NT does. A relocated data-segment page should be a clean page, not a dirty page!
- jtbayly 6y agoSomebody asked on Twitter, "doesn't this break all of Brew?" Does anybody know?
- unilynx 6y agoI don't see why, Brew just uses the standard compilation tools any other software on OSX uses, so it'll work the way any other tool works Brew either uses the system libraries (which still work) or compiles its own version (which is not affected by this)
- pdimitar 6y agoLikely an unpopular opinion: not everything has to be a file. UNIX removed a lot of obstacles and helped usher in the era of computing accessible to individuals -- but we can't keep relying on old paradigms when it's now clear (with the benefit of hindsight) that it's not a be-all-end-all solution. Filesystems are awful databases and I believe everyone who was a programmer for some time realizes this. The lack of ACID being at the top. The sooner we move to specialized APIs for, well, everything, the better off we're going to be. --- As one recent example, the PS 5 will just directly load 3D artefacts from the SSD storage to the GPU when the corresponding API is called. This gives Sony peace of mind that people won't be coming up with 100+ ways of doing it by themselves which Sony will then have to support for the entirety of the PS 5 lifecycle. We the programmers have demonstrated to ourselves, time and again, that too much freedom can actually be a bad thing. It's okay to move away from the "everything is a file" philosophy. If anything, I'd love to see a Linux-like OS that utilizes sqlite3 for, say, the entirety of the current `/etc` directory and uses sqlite3's backup/changeset APIs to do incremental and point-in-time backups. Sure it's little less transparent but you can't ever capture an inconsistent snapshot. That has to be an improvement, right? --- EDIT: I suppose people can't find a link between my comment and the topic but my point was that moving to dedicated APIs -- and not relying on the filesystem -- for various services (like loading a dynamic library) is a good thing because the "everything is a file" paradigm isn't as bulletproof as it's made out to be (also because "stat" + "dlopen" one after another are race-condition prone as others pointed out). I'd love to hear the downvoters elaborate their reasoning.
- jlokier 6y agoI wonder how many years we've got where you're still able to read the big mega archive... Someday it may sit in some kind of "protected enclave", mapped into your process with "execute-only" permission for code, and maybe graded protections for its data as well, so you can't debug, trace, instrument, reverse engineer or otherwise get to really know the system libraries to see what they are doing and learn from them. The trend has been that way for a while. For the moment, that kind of isolation is done at process boundaries, on devices that have enclaves. There is no technical reason why that kind of isolation cannot extend inside processes, for a company that designs its own CPUs. For the same kind of "black boxes" as we already have inside mobile devices, but with faster API calls and data exchange than doing it across processes boundaries.
- szc 6y agoSorry, but the /usr model for compiling is out of date / flawed. It isn't about "me" it is about "you" the target for running the executable. For many years, macOS has supported being a cross compilation environment for multiple platforms and multiple OS releases. This means that include files and libraries for the target OS and platform are not stored at the "host filesystem" paths that were used in the 1960's, 1970's and 1980's... (an embarrassingly long list). Include files and references to libraries are available in the SDKs. One should use the SDK path as a prefix for the include and library paths - something that most GNU tools, and other open source projects have supported for a very long time, but sadly a little inconsistently. There are runtime tools and recipes that can be used to get these paths, including for "myself". All compilation on macOS should be considered as cross compilation -- because macOS simultaneously supports multiple architectures and OS versions. This really is a good abstracted model for all compilation. This has benefits! Install time and disk space usage are reduced for most customers and developers. Developers on x86_64 do not need the aarch64 content in /System, /usr to compile. Install the SDKs for the targets you wish to compile for.