Hacker News Reader

Comment by nrclark | Hacker News Reader

Shared libraries are a pain for sure. They also have a lot of really nice advantages, including:

  - You can upgrade core functionality in one location
  - You can fix security bugs without needing to re-install the world
  - Overall, they take up less disk-space and RAM
  - They can take much less cache, which is significant today

The cache aspect is one that I'm surprised not to see people talk about more. Why would I want to blow out my CPU cache loading 20 instances of libSSL? That slows down performance of the entire system.

View on HN

That is just not how cpu cache works on multi-user systems. There is no L1 icache sharing between programs.

You don’t have to go much further down the hierarchy before you’re sharing one copy of common code & static data.

I think the dream is you could have one SSL process that others communicated with. Message passing at large.

It's not without cost, though. Moving messages around causes CPU data cache pressure and CPU cycles you wouldn't otherwise have spent if you merely referenced shared memory that's mapped into your process.

Right. I didn't mean that to be why it is correct. Just giving some comment to what was actually suggested. Static linking is not the only alternative to dynamic linking.

So, like some sort of shared library that my programs dynamically communicate with? How is this functionally different from a shared object?

It isn't really. The actual big problem with shared libraries is that developers cannot be trusted not to change their interfaces or behavior and break things. That's true regardless of what mechanism you use to share code.

> How is this functionally different from a shared object?

Because it's a separate process, so when it crashes your application can put up a "SSL failed, reconnecting" message and carry on. Also when your application has read-something-somewhere security vulnerability, it can't compromise your SSL keys.

Nitpick: it's not one process, but one executable; you can have multiple SSL daemons using the same (read-only) binary, so a attack on one only gets one set of keys. (The same attack will probably work on every instance of the same version of SSLd, but shared objects don't fix that.)

Reply on news.ycombinator.com