• jonne@infosec.pub
      link
      fedilink
      arrow-up
      12
      ·
      2 days ago

      Their use case is to run their own application(s) on their own servers in their own datacenter, so they’re probably ok with that tradeoff. But yeah, I can imagine this opening up a whole bunch of security issues if this starts getting used widely.

    • MadhuGururajan
      link
      fedilink
      English
      arrow-up
      6
      arrow-down
      1
      ·
      2 days ago

      The gist is that a system call is introduced to go into the PCB and change the Effective UID of a process. Security is ensured by a processor MPK which is a CPU provided guard so that a {Process, Library} has only a restricted set of Effective UIDs it can switch to. This operations is supposed to use 30 to 50 clock cycles. So entry + exit is supposed to be done in 100 cycles. This is considered low overhead context switch compared to the traditional context switch on Linux for slower IPCs. They don’t do a comparison against iouring, or simply multi-threaded process.

      • treadful@lemmy.zip
        link
        fedilink
        English
        arrow-up
        5
        ·
        2 days ago

        You sound like you’re living in the weeds, friend.

        What’s MPK? And by UID I assume you’re not talking about the system level user ID but some kind of processor-level process ID?

        • MadhuGururajan
          link
          fedilink
          English
          arrow-up
          2
          ·
          2 hours ago

          I don’t know the details of the MPK. So I consider it as some kind of function that maps {process PID, DLL} => Set of UID. And by UID, I AM talking about the system level user ID. Remember that this feature is a processor level feature. So it has to be transparent to the OS (well at least, to the OS Scheduler). Hence the output of this feature should be understandable to the OS kernel. Or so I hope as the implementation details are vague till now.