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

    Not a kernel expert but this is how it reads to me.

    Instead of connecting via a socket through the kernel, this would allow processes to execute functions of other processes already in memory.

    This would normally be prevented by processor memory protections, but a new processor feature has functionality to allow this now.

      • 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?