Really interested in the idea of dynamic hotpatching for software security.
This is fairly widespread at the OS layer, but I think there's opp for it to happen ubiquitously from the chip up.
The way that software has historically been built and distributed it is effectively impossible to keep things up to date.
eMudhra key gets leaked and now suddenly all your Electron apps have to update. A vuln happen in Go stdlib and suddenly thousands of independent binaries need updates. This is an impossible situation.
You need to be running something on the OS at the root layer that can hotpatch _all_ of the software above it. This implies a hierarchical system where a root layer hotpatches e.g., the JVM, which then hotpatches Rhino, which hotpatches a JS lib.
Centrally managed, instantly distributable, instantly revertable.
Greasemonkey for everything.
Who is working on this and can I invest?
This is fairly widespread at the OS layer, but I think there's opp for it to happen ubiquitously from the chip up.
The way that software has historically been built and distributed it is effectively impossible to keep things up to date.
eMudhra key gets leaked and now suddenly all your Electron apps have to update. A vuln happen in Go stdlib and suddenly thousands of independent binaries need updates. This is an impossible situation.
You need to be running something on the OS at the root layer that can hotpatch _all_ of the software above it. This implies a hierarchical system where a root layer hotpatches e.g., the JVM, which then hotpatches Rhino, which hotpatches a JS lib.
Centrally managed, instantly distributable, instantly revertable.
Greasemonkey for everything.
Who is working on this and can I invest?
9
0
5
975
@aboodman this has been possible for years but its more trouble than its worth generally speaking
1) the code paths arent the same
2) best practices > hopeful magic fix-alls
3) changing byte code on the fly fucks with all forms of compliance
1) the code paths arent the same
2) best practices > hopeful magic fix-alls
3) changing byte code on the fly fucks with all forms of compliance
1
0
1
384
@aboodman i doubt it
you're better off shipping middleware for most of these things, which is what people already do
you're better off shipping middleware for most of these things, which is what people already do
1
0
0
32
@zeeg I don't understand how middleware helps me update all the Node versions on computers in my org.
1
0
0
27
@aboodman it doesnt, but it blocks network attacks, which are the primary concern you're protecting against
1
0
0
42
@zeeg How does it do that? The bad node version is baked into a thousand random ass apps installed on clients.
1
0
0
92
@zeeg I get what you're saying on the server though. You control the front door so you can do a lot there. And you ostensibly control all the code on the machine.
1
0
0
113
@aboodman yeah i just dont think anything changes here because the number of things that can go wrong via bytecode changes is large, and again, opening that door opens up another large vector of attacks
im sure a lot of the fortune 500 already do byte code patching, but likely not live
im sure a lot of the fortune 500 already do byte code patching, but likely not live
Oct 24, 2026 路 11:36 PM UTC
0
0
0
46

