4 ms·

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

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-brad-cox/ https://thenewstack.io/objective-cs-roots-in-the-life-of-bra...

dmix 4y ago
Erlang has had hotloading for a long time and seems to be fine security wise AFAIK.
- kaba0 4y ago
  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.
  - jjtheblunt 4y ago
    just wanted to say i really like the clarity of that explanation
- melony 4y ago
  Most of (traditional) Erlang deploymens are in embedded systems. They have a different threat model.
- toast0 4y ago
  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.
astrange 4y ago
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.
- saagarjha 4y ago
  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.
  - musesum 4y ago
    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 https://en.wikipedia.org/wiki/AARD_code
    - saagarjha 4y ago
      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 ;)
      - anonymouse008 4y ago
        … take me through this? Is it evaluating through NSObject keypaths? I’m a noob and just curious.
KerrAvon 4y ago
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 https://archive.org/details/objectorientedpr00coxb
- ChrisMarshallNY 4y ago
  > 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.
  - pjmlp 4y ago
    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).
saagarjha 4y ago
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.

dmix 4y ago

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

kaba0 4y ago
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.
- jjtheblunt 4y ago
  just wanted to say i really like the clarity of that explanation
melony 4y ago
Most of (traditional) Erlang deploymens are in embedded systems. They have a different threat model.
toast0 4y ago
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.

astrange 4y ago

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.

saagarjha 4y ago
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.
- musesum 4y ago
  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 https://en.wikipedia.org/wiki/AARD_code
  - saagarjha 4y ago
    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 ;)
    - anonymouse008 4y ago
      … take me through this? Is it evaluating through NSObject keypaths? I’m a noob and just curious.

KerrAvon 4y ago

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 https://archive.org/details/objectorientedpr00coxb

ChrisMarshallNY 4y ago
> 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.
- pjmlp 4y ago
  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).

saagarjha 4y ago

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.