Announcement

Collapse
No announcement yet.

Intel Working With Wine Developers On User-Mode Instruction Prevention

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • Intel Working With Wine Developers On User-Mode Instruction Prevention

    Phoronix: Intel Working With Wine Developers On User-Mode Instruction Prevention

    The Intel developer working on UMIP (User-Mode Instruction Prevention) support for the Linux kernel has been collaborating with Wine developers about this security-minded feature to be introduced with future Intel CPUs...

    http://www.phoronix.com/scan.php?pag...MIP-Intel-Wine

  • #2
    10 bucks someone circumvents UMIP and gets the IDTR base address in privileged containers this year.

    Comment


    • #3
      Is it a feature?
      Well, I feel I little skeptical when I read about a code execution preventing technology, an hardware one in particular: who's deciding what can my PC run or not?

      Comment


      • #4
        Imagine if WINE gets this feature before Windows does...

        Comment


        • #5
          Good, for WINE, charge'em dry!

          Comment


          • #6
            Originally posted by Pickup View Post
            Is it a feature?
            Well, I feel I little skeptical when I read about a code execution preventing technology, an hardware one in particular: who's deciding what can my PC run or not?
            I agree. Surely this sort of restriction could prevent innovative technologies (like Wine) appearing in the future.
            That said, I would hope this can be disabled in the (classic) BIOS.

            Comment


            • #7
              Originally posted by Pickup View Post
              Is it a feature?
              Well, I feel I little skeptical when I read about a code execution preventing technology, an hardware one in particular: who's deciding what can my PC run or not?
              According to the description on the Wine page, it's a kernel-controlled feature like everything else you're fine with, such as protected-mode execution, NX-bit (A.K.A. Hardware DEP), etc.

              (And it can be turned off with a kernel boot parameter, the same way you might turn off KMS because you're on nVidia drivers.)

              As for what it does, it enables the kernel to catch requests for certain types of information (eg. the location of the kernel's interrupt handler table) that legitimate user-mode applications have no business knowing so it can either kill them or return dummy values. (Think of it as CyanogenMod's "allow but return forged values" permissions behaviour, but for certain kernel internals that are visible to user-mode applications for legacy reasons.)
              Last edited by ssokolow; 09 January 2017, 09:29 AM.

              Comment


              • #8
                Originally posted by ssokolow View Post
                As for what it does, it enables the kernel to catch requests for certain types of information (eg. the location of the kernel's interrupt handler table) that legitimate user-mode applications have no business knowing so it can either kill them or return dummy values. (Think of it as CyanogenMod's "allow but return forged values" permissions behaviour, but for certain kernel internals that are visible to user-mode applications for legacy reasons.)
                I like this. Does it really need special hardware support to do this?

                Comment


                • #9
                  Originally posted by starshipeleven View Post
                  I like this. Does it really need special hardware support to do this?
                  UMIP is the same sort of thing as the virtualization extensions.

                  The instructions in question are an ancient part of the x86 ISA and, without the CPU helping to catch them, trying to block access to them presents a trade-off between performance and security. (Because the only guaranteed way to catch all attempts to call them is to run your programs in an x86-on-x86 emulator.)

                  Imagine securely implementing memory protection without CPU assistance. It's a similar sort of problem.

                  Comment

                  Working...
                  X