Intel Working With Wine Developers On User-Mode Instruction Prevention

[phoronix]

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?page=news_item&px=UMIP-Intel-Wine

[c117152]

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

[Pickup]

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?

[ldo17]

Imagine if WINE gets this feature before Windows does...

[AdamOne]

Good, for WINE, charge'em dry!

[kpedersen]

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.

[ssokolow]

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.)

[starshipeleven]

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?

[ssokolow]

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.