4 ms·

I understand the motivation for shared libs is the reduced memory footprint for large common libs. I have an alternative idea that avoids the headaches of share

I understand the motivation for shared libs is the reduced memory footprint for large common libs. I have an alternative idea that avoids the headaches of shared lib mismatches and still can reduce the memory footprint. Have relocatable code be statically linked but stored with a hash. When loading a binary see if common relocatable code is already loaded .. if it has the same hash then it is exactly the same and can be safely shared. No version mismatch headaches.

8organicbits 4y ago
I think often the binaries will have been compiled against slightly different versions. With dynamic linking, I can swap 1.0.1 for 1.0.2 or 1.0.3 without issue. The hash would require an exact match, which is likely rare.
- waynecochran 4y ago
  I want an exact match. That is what I developed and tested against. A change, however small, can have unintended consequences. Changing versions is a huge issue from a reliability point of view.
eru 4y ago
Wouldn't you want to randomise some stuff to make attacks harder? (Sorry, I forgot the details.)
cesarb 4y ago
> Have relocatable code be statically linked but stored with a hash. When loading a binary see if common relocatable code is already loaded .. if it has the same hash then it is exactly the same and can be safely shared. It's not actually "code" which is being shared, but instead the memory pages containing that code (the sharing granularity is a single page, since sharing works by pointing the page table entries on each process to the same physical page). So either you'd have to force page alignment for each and every function (highly wasteful, since the page size is at least 4096 bytes), or you're reinventing shared libraries but using a hash instead of a version.
- waynecochran 4y ago
  That's finer grained than I imagined. I am assuming hashes for large pieces of code that are completely relocatable in memory.
- waynecochran 4y ago
  This is not like shared libraries in that my program is guaranteed to load and run regardless of what libs are on the system. Also, I am guaranteed my program is running with the exact same library I tested it with.

8organicbits 4y ago

I think often the binaries will have been compiled against slightly different versions. With dynamic linking, I can swap 1.0.1 for 1.0.2 or 1.0.3 without issue. The hash would require an exact match, which is likely rare.

waynecochran 4y ago
I want an exact match. That is what I developed and tested against. A change, however small, can have unintended consequences. Changing versions is a huge issue from a reliability point of view.

eru 4y ago

Wouldn't you want to randomise some stuff to make attacks harder? (Sorry, I forgot the details.)

cesarb 4y ago

> Have relocatable code be statically linked but stored with a hash. When loading a binary see if common relocatable code is already loaded .. if it has the same hash then it is exactly the same and can be safely shared. It's not actually "code" which is being shared, but instead the memory pages containing that code (the sharing granularity is a single page, since sharing works by pointing the page table entries on each process to the same physical page). So either you'd have to force page alignment for each and every function (highly wasteful, since the page size is at least 4096 bytes), or you're reinventing shared libraries but using a hash instead of a version.

waynecochran 4y ago
That's finer grained than I imagined. I am assuming hashes for large pieces of code that are completely relocatable in memory.
waynecochran 4y ago
This is not like shared libraries in that my program is guaranteed to load and run regardless of what libs are on the system. Also, I am guaranteed my program is running with the exact same library I tested it with.