Contributed by tbert on from the show-your-work dept.
- Making OpenBSD Useful on the Octeon Network Gear Paul Irofti (pirofti@)
- Using routing domains / tables in a production network Peter Hessler (phessler@)
- Making make parallel - legacy code nightmare Marc Espie (espie@)
- arc4random - 1996 to present Theo de Raadt (deraadt@)
- Let's make manuals more useful! [tutorial] [paper] Ingo Schwarze (ingo@)
- Developing Software in a Hostile Environment Ted Unangst (tedu@)
- Taming OpenBSD Network Stack Dragons Martin Pieuchot (mpi@)
- LibreSSL: More Than 30 Days Later Ted Unangst (tedu@)
- vscsi(4) and iscsid(8) - iSCSI initiator the OpenBSD way Claudio Jeker (claudio@)
- Secure Lazy Binding Philip Guenther (guenther@)
(Comments are closed)
By Anonymous Coward (69.70.101.194) on
Comments
By bgpepi (bgpepi) on
https://va.ludost.net/files/eurobsdcon/
By rabysh (192.222.137.246) on
By jbc (111.232.100.160) on
Why is something as vital as linked library loading unprivileged and offsourced to the userland? In the end, an exploit can jump through all the hoops.
Tradition doesn't cut it as a justification.
Link on segfault. Using the original data as verified. It might be slower than even before lazy linking, but your system won't mine bitcoins for the Russian mafia.
Comments
By Philip Guenther (76.253.0.176) guenther@openbsd.org on
> Why is something as vital as linked library loading unprivileged and offsourced to the userland?
I did try to address that point ("why not just do the linking in the kernel?") in my talk after a question from Shawn Webb. In short, putting it in the kernel increases the attack surface of the kernel while still being dependent on data in user space. Moving that library data into kernel space would be...challenging; kernel VA is a limited resource on many architectures.
Side note: don't like lazy linking? Just run with LD_BIND_NOW=1 in your environment and decide for yourself whether you want it or not. (Yeah yeah, that doesn't affect setugid programs; if you really like the result you can just flip it always on in the ld.so on your system; you get the point.)
> In the end, an exploit can jump through all the hoops.
> Tradition doesn't cut it as a justification.
> Link on segfault. Using the original data as verified. It might be slower than even before lazy linking, but your system won't mine bitcoins for the Russian mafia.
I don't think I really understand what you're envisioning as a design. Why would segfaulting be involved?
Regardless, if you believe in the benefits of your design, you should implement it for your favorite architecture and see how it works out and do a presentation at a future convention (eurobsdcon, bsdcan, asiabsdcon, or wherever)
Comments
By jbc (111.232.100.160) on
> I did try to address that point ("why not just do the linking in the kernel?") in my talk after a question from Shawn Webb. In short, putting it in the kernel increases the attack surface of the kernel while still being dependent on data in user space. Moving that library data into kernel space would be...challenging; kernel VA is a limited resource on many architectures.
>
Sorry, I'll watch the talk when/if it is ever made available to be able to criticize with more arguments.
Then why is execve(2) in the kernel? With the current level of randomization it should be about the same expense. Or is my understanding wrong and vax doesn't get the same treatment as amd64?
> I don't think I really understand what you're envisioning as a design. Why would segfaulting be involved?
>
> Regardless, if you believe in the benefits of your design, you should implement it for your favorite architecture and see how it works out and do a presentation at a future convention (eurobsdcon, bsdcan, asiabsdcon, or wherever)
>
Segfault - or whatever way to enter the kernel and resolve stuff in a way that can't be directly affected by user data *after* initial execution and is portable to anything OpenBSD works on regardless of performance. I haven't tried working a solution by myself. If I had - and it was better than yours, I would tell you. I just said, and I stand by it, that I do not like lazy binding as described.
I truly don't want to offend you or anyone else, but "we'll add a few more flags and a super-secret cookie to mmap(2)", just doesn't have the same ring to it as "we'll use this algorithm for cache which works all the same just that it's better in most cases".
When I see/hear the full talk, I might be convinced otherwise, but now, to me, it smells(like my undeadly karma if such a thing exists :)).
Comments
By Philip Guenther (208.86.202.10) guenther@openbsd.org on
> Then why is execve(2) in the kernel?
Because it does stuff that can't be done from user space.
...
> Segfault - or whatever way to enter the kernel and resolve stuff in a way that can't be directly affected by user data *after* initial execution and is portable to anything OpenBSD works on regardless of performance. <...>
I don't see how that's going to have enough information to do what needs to be done.
Comments
By Anonymous Coward (182.250.240.99) on
> ...
... in OpenBSD. Other than the actual CPU context switch and maybe some device access nothing needs kernel mode. It's just convenient - and more secure than a microkernel service in libc.
> I don't see how that's going to have enough information to do what needs to be done.
I don't see how an Operating System could read encrypted pages from swap storage on a page fault.
Comments
By Philip Guenther (208.86.202.10) guenther@openbsd.org on
> > ...
> ... in OpenBSD.
You have a way to implement the setuid and setgid bits in user space?
> Other than the actual CPU context switch and maybe some device access nothing needs kernel mode. It's just convenient - and more secure than a microkernel service in libc.
"It's all about convenience, except for that part where it's needed", is the same as saying "it's needed".
Anyway, I look forward to your presentation and/or diff.