51–60 of 84 posts
I remember my Gentoo days freshman year in college. I spent more time compiling updates than actually using the computer.
I remember my Gentoo days freshman year in college. I spent more time compiling updates than actually using the computer.
[0] https://www.dropbox.com/s/w1zlftin1cojkhr/kernel_compile.mov...
Earlier quoted context omitted.
I thought openbsd did it after boot?
OpenBSD relinks sshd. Which is relatively small thing that is linked from relatively large objects (ie. it is the typical modern C code). Relinking thing like glibc on demand is going to be problematic, because it is structured as to allow small binary sizes for static linking and thus almost every function that is part of glibc API is a separate compilation unit and object file. Linking that into .so is slow, no mat…
you can link in the background at idle priority, and if you don't complete before reboot: no big deal
Earlier quoted context omitted.
OpenBSD relinks sshd. Which is relatively small thing that is linked from relatively large objects (ie. it is the typical modern C code). Relinking thing like glibc on demand is going to be problematic, because it is structured as to allow small binary sizes for static linking and thus almost every function that is part of glibc API is a separate compilation unit and object file. Linking that into .so is slow, no mat…
doesn't matter how long it takes if you don't block the boot process doing it you can link in the background at idle priority, and if you don't complete before reboot: no big deal
Openbsd also puts a fair amount of work into removing ROP gadgets. For example. https://marc.info/?l=openbsd-cvs&m=152824407931917
I wonder if just shuffling it on every release (even minor) isn’t sufficient (and actually even publishing that order). That doesn’t have full security benefit (attackers have a finite set of options) but keeps reproducible builds and the ability to distribute pre-linked binaries while raising the attack complexity significantly since no two machines are likely running the exact same version. That means an exploit ha…
Earlier quoted context omitted.
doesn't matter how long it takes if you don't block the boot process doing it you can link in the background at idle priority, and if you don't complete before reboot: no big deal
Relinking glibc would block the boot process.
it's a dynamic library, and this isn't windoze with awful mandatory locking
as long as the underlying version is unchanged: there should be no problem whatsoever