OpenBSD Journal

EuroBSDCon 2014 Papers Online

Contributed by tbert on from the show-your-work dept.

(Comments are closed)


Comments
  1. By Anonymous Coward (69.70.101.194) on

    Any progress on usb storage support for Octeon?

    Comments
    1. By bgpepi (bgpepi) on

      Video
      https://va.ludost.net/files/eurobsdcon/

  2. By rabysh (192.222.137.246) on

    Thanks, that was some really interesting reading, wish I could be there!

  3. By jbc (111.232.100.160) on

    I don't like lazy binding as described. While they are trying to make sure it is reasonably secure whithin bounds, I'm not sure the bounds are justified.
    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
    1. By Philip Guenther (76.253.0.176) guenther@openbsd.org on

      > I don't like lazy binding as described. While they are trying to make sure it is reasonably secure whithin bounds, I'm not sure the bounds are justified.
      > 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
      1. By jbc (111.232.100.160) on

        Thank you for your time,

        > 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
        1. 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
          1. By Anonymous Coward (182.250.240.99) on

            > Because it does stuff that can't be done from user space.
            > ...
            ... 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
            1. By Philip Guenther (208.86.202.10) guenther@openbsd.org on

              > > Because it does stuff that can't be done from user space.
              > > ...
              > ... 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.

Latest Articles

Credits

Copyright © - Daniel Hartmeier. All rights reserved. Articles and comments are copyright their respective authors, submission implies license to publish on this web site. Contents of the archive prior to as well as images and HTML templates were copied from the fabulous original deadly.org with Jose's and Jim's kind permission. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]