Hacker News Reader

Comment by musesum | Hacker News Reader

Ironically, I think Brad Cox had something like this in mind, after coming up with Objective C. Or at least, pluggable components [1]

I wonder what the threat model would be? Injectable binaries seem like a decent attack vector. But, if we're talking 2040, maybe a signable Merkle tree would do the trick.

Meanwhile, have been experimenting with recompiling Metal code at runtime. Was kinda fun with ObjC/C++/OpenGL, a few years ago.

[1] https://thenewstack.io/objective-cs-roots-in-the-life-of-bra...

View on HN

If you read the first edition of his book[1], it's pretty clear about what he was trying for, which IIRC was essentially resumable software components as black boxes that you could buy off the shelf and integrate in your own products.

I find this quote interesting:

> But in addition, “I had just become incredibly annoyed with proprietary languages,” he said. Fortran vendors, for instance, would add extra features to try to lock customers into their particular version.

But this is exactly what he did with Objective-C -- it was a proprietary language until NeXT bought his company! It could have had widespread adoption had there been a widely available implementation.

[1] https://archive.org/details/objectorientedpr00coxb

> resumable software components as black boxes that you could buy off the shelf and integrate in your own products.

Wasn't that one of the goals of CORBA? [D]COM?

I know it was one of the lynchpins of OpenDoc, but that took it even farther, with a document-centric approach to applications.

It was, and COM is pretty much alive on Windows as its main "modern" API (in quotes because VS tooling keeps lacking versus Borland/CodeGear tooling, despite its relevance on Windows APIs).

Hot reloading is a user(/developer) facing tool. You open up the application and put some of your own code in it. Platform vendors have almost universally rejected this model because it takes away control from them, but just like all apps load system libraries because they’re signed and trusted the solution here is to allow the hot reloader to add their own root of trust along with the one in the OS. Then you can just sign your own interpositions and load them safely.

Objective-C used to support reloading but now explicitly does not (dlclose() doesn't do anything) because it's unsafe.

Xcode used to have these features (called Zero Link and fix and continue) but they were quickly removed because nobody used them.

Hot reloading is typically considered to be concept of swapping out an implementation rather than literally unloading the code from memory. Objective-C is mildly limited by its C heritage but one can go pretty far with runtime trickery to get a similar effect. The other features were removed because they were not fully fleshed out and too unreliable to use.

For iOS, we used some runtime trickery to access private APIs. Was needed to access calendar invite details. Could see how a less benign developer could sneak malicious code past Apple's review process.

A famous example of self-modifying code was Microsoft's AARD code, which was decrypted on the fly to check if the user was running a competitor's OS. [1]

I always wondered if the perceived threat of runtime method constructors was an incentive for Apple to push for Swift.

[1] https://en.wikipedia.org/wiki/AARD_code

Self-modifying code is prohibited on iOS by codesigning. However, achieving Turing complete execution capable of calling any API not behind an entitlement is very feasible and regularly passes App Store review for simple cases. The more complicated ones might too, but they aren't delivered via the store very often ;)

… take me through this? Is it evaluating through NSObject keypaths? I’m a noob and just curious.

Easy one is to embed an interpreter and let it call arbitrary Objective-C code

If you can convert data into an API call, then it becomes an issue of steganography. The only way to trust a binary is through 100% code coverage through all possible inputs, which is intractable.

Code signing and a secure enclave may help protect against local use cases, like ransomware, but doesn't protect against hybrid attacks, like granting access to 3rd parties.

Maybe this means that all binaries in 2040 should be derived from open source with AI doing the threat detection.

  > quickly removed because nobody used them

what is the definition of "nobody"?

n=1 and all that, but as a developer i used it all the time and was totally dismayed it was removed...

Erlang has had hotloading for a long time and seems to be fine security wise AFAIK.

Hot reloading’s quality (and to a degree, security) depends mostly on how fine-grained a change can be. The reason Lisp-REPl workloads are so well loved is that very small scopes can be changed easily, Erlang also has a sane encapsulation that can be swapped without much fuss.

just wanted to say i really like the clarity of that explanation

Most of (traditional) Erlang deploymens are in embedded systems. They have a different threat model.

Erlang has a very limited security model. In the default distribution, any process on any node can spawn a process on any other connected node to run any function --- you can send the function too. Modules can have a function to run on load, too. Loading an untrusted module is asking for that module to take over your whole system. Best to make sure nobody unauthorized can do that.

Reply on news.ycombinator.com