OpenBSD Journal
Home : : Add Story : : Archives : : About : : Create Account : : Login :
EuroBSDCon 2014 Papers Online
Contributed by tbert on Wed Oct 1 06:37:07 2014 (GMT)
from the show-your-work dept.

[topicconf]

<< EuroBSDCon 2014 Opens | Reply | Flattened | Collapsed | OpenBSD 5.6 Pre-Orders Available >>

Threshold: Help

Related Links
more by tbert


  Re: EuroBSDCon 2014 Papers Online (mod -2/16)
by Anonymous Coward (69.70.101.194) on Wed Oct 1 16:21:31 2014 (GMT)
  Any progress on usb storage support for Octeon?
  [ Show thread ] [ Reply to this comment ] [ Mod Up ] [ Mod Down ]

       
Re: EuroBSDCon 2014 Papers Online (mod 1/11)
by bgpepi (bgpepi) on Wed Oct 1 23:28:35 2014 (GMT)
  Video
https://va.ludost.net/files/eurobsdcon/

  [ Show thread ] [ Reply to this comment ] [ Mod Up ] [ Mod Down ]

  Re: EuroBSDCon 2014 Papers Online (mod 1/15)
by rabysh (192.222.137.246) on Thu Oct 2 03:33:26 2014 (GMT)
  Thanks, that was some really interesting reading, wish I could be there!
  [ Show thread ] [ Reply to this comment ] [ Mod Up ] [ Mod Down ]

  Re: EuroBSDCon 2014 Papers Online (mod 2/8)
by jbc (111.232.100.160) on Sun Oct 5 11:20:07 2014 (GMT)
  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.

  [ Show thread ] [ Reply to this comment ] [ Mod Up ] [ Mod Down ]

       
Re: EuroBSDCon 2014 Papers Online (mod 5/7)
by Philip Guenther (76.253.0.176) (guenther@openbsd.org) on Mon Oct 6 02:40:36 2014 (GMT)
  > 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)
  [ Show thread ] [ Reply to this comment ] [ Mod Up ] [ Mod Down ]

         
Re: EuroBSDCon 2014 Papers Online (mod 4/6)
by jbc (111.232.100.160) on Mon Oct 6 12:37:41 2014 (GMT)
  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 :)).
  [ Show thread ] [ Reply to this comment ] [ Mod Up ] [ Mod Down ]

           
Re: EuroBSDCon 2014 Papers Online (mod 1/5)
by Philip Guenther (208.86.202.10) (guenther@openbsd.org) on Mon Oct 6 15:30:53 2014 (GMT)
  ...
> 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.
  [ Show thread ] [ Reply to this comment ] [ Mod Up ] [ Mod Down ]

             
Re: EuroBSDCon 2014 Papers Online (mod -1/9)
by Anonymous Coward (182.250.240.99) on Mon Oct 6 17:10:56 2014 (GMT)
  > 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.
  [ Show thread ] [ Reply to this comment ] [ Mod Up ] [ Mod Down ]

               
Re: EuroBSDCon 2014 Papers Online (mod 5/7)
by Philip Guenther (208.86.202.10) (guenther@openbsd.org) on Mon Oct 6 21:30:07 2014 (GMT)
  > > 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.
  [ Show thread ] [ Reply to this comment ] [ Mod Up ] [ Mod Down ]

[ Home | Add Story | Archives | Polls | About ]

Copyright © 2004-2008 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 April 2nd 2004 as well as images and HTML templates were copied from the fabulous original deadly.org with Jose's and Jim's kind permission. Some icons from slashdot.org used with permission from Kathleen. This journal runs as CGI with httpd(8) on OpenBSD, the source code is BSD licensed. Search engine is ht://Dig. undeadly \Un*dead"ly\, a. Not subject to death; immortal. [Obs.]