1. 35
  1.  

  2. 12

    What’s kind of fascinating about this, at least in the abstract, is that it lets the application developer signal to the operating environment what state the program is in, right?

    Right now that’s just being used for simple things like “kill me if I try to do something I shouldn’t”, but one could consider more exotic use cases.

    For example, if a program has tame’d away all of its io or socket privileges, or something similar, it could be moved to a different interrupt and servicing model by the kernel. A program could be detected to be in a startup phase, and then scheduled differently from running programs until it stops initializing.

    1. 11

      tame() is a very clean and good idea. I saw the initial draft on the ml, back when they had enums bitwise xored to combine fields. Seems like they changed that to instead have space separated strings. Don’t know what to think about that, I prefer the enums tbh.

      No matter how good the interface is, it’s almost certain this will never hit Linux in the next 5-10 years. It’s not because the interface is bad, but because the glibc-devs and other people are scared of simple and straight-forward interfaces, rather not doing anything than implementing an interface which handles the general case rather than trying to cover the 0.5% of edge cases, being complex and bloated.

      We’ve seen it with arc4random(), which is a work of genius. Of course you can use it using libbsd, but in the end, it’s one more unnecessary step to get true and simple randomness. glibc is poison and they can go to hell, all of the dirty bunch! They are major contributors that our software is not benefitting from the great interfaces developed by the hands of ingenius developers like Theo de Raadt and his fellows.

      When something like tame() doesn’t hit the broad spectrum of Linux developers, it will never work out. At least with rand() and OpenBSD’s in-house approach, they could silently convert all rand()-PNG-calls to true arc4random()-calls without changing the softwares' code. tame() doesn’t offer that possibility.

      1. 14

        No matter how good the interface is, it’s almost certain this will never hit Linux in the next 5-10 years. It’s not because the interface is bad, but because the glibc-devs and other people are scared of simple and straight-forward interfaces, rather not doing anything than implementing an interface which handles the general case rather than trying to cover the 0.5% of edge cases, being complex and bloated.

        This is such a tough lesson to learn and to apply. I still fail at it most of the time in my own code, thinking up the weirdest edge cases possible that I need to handle rather than making the 99% case nice and simple.

        1. 10

          Seems like they changed that to instead have space separated strings. Don’t know what to think about that, I prefer the enums tbh.

          I wondered why this happened as well, so I went CVS-spelunking:

          Move to next tame() API. The flags are now passed as a very simple string, which results in tame() code placements being much more recognizeable. tame() can be moved to unistd.h and does not need cpp symbols to turn the bits on and off. The resulting API is a bit unexpected, but simplifies the mapping to enabling bits in the kernel substantially. vague ok's from various including guenther doug semarie

          1. 9

            Among other benefits, this also allows for the possibility of suboptions in the future. Or even just more options than fit in 32 bits. But without terribly complicating the API.

            1. 3

              Ah, thanks for checking this! Well, the reasoning makes sense…

          2. 8

            I’m glad he used Comic Sans. People who are smart will know to pay attention.

            1. 3

              Is that a project-wide thing now? I remember seeing it “militarized” when they were doing the SSH overhaul.

              1. 2

                I think you mean SSL, but yes, it’s clearly a running joke now.