You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.

59 lines
3.9 KiB

  1. With the latest release of their Architecture Instruction Set Extensions
  2. Programming Reference Intel has finally lifted the veil on a new CPU feature
  3. to debut in next year's Haswell line of processors. This new feature is
  4. called Supervisor Mode Access Prevention (SMAP) and there's a reason why
  5. its name so closely resembles Supervisor Mode Execution Prevention (SMEP),
  6. the feature that debuted with Ivy Bridge processors a few months ago. While the
  7. purpose of SMEP was to control instruction fetches and code execution from
  8. supervisor mode (traditionally used by the kernel component of operating
  9. systems), SMAP is concerned with data accesses from supervisor mode.
  10. In particular, SMEP, when enabled, prevents code execution from userland memory
  11. pages by the kernel (the favourite exploit technique against kernel security
  12. bugs), whereas SMAP will prevent unintended data accesses to userland memory.
  13. The twist in the story and the reason why these security features couldn't be
  14. implemented as one lies in the fact that the kernel does have legitimate need
  15. to access data in userland memory at times while no contemporary kernel needs
  16. to execute code from there. In other words, while SMEP can be enabled
  17. unconditionally by flipping a bit at boot time, SMAP needs more care because it
  18. has to be disabled/enabled around legitimate accessor functions in the kernel.
  19. Intel has added two new instructions for this very purpose (CLAC/STAC) and
  20. repurposed the alignment check status bit in supervisor mode to enable quick
  21. switching around SMAP at runtime. This will require more extensive changes in
  22. kernel code than SMEP did but the amount of code is still quite managable.
  23. Third party kernel modules that don't use the kernel's userland accessor
  24. functions will have to take care of switching SMAP on/off themselves.
  25. What does SMAP mean for PaX? The situation is similar to last year's SMEP that
  26. made efficient implementation of (partial) KERNEXEC possible on amd64
  27. (i386/KERNEXEC continues to rely on segmentation instead which provides better
  28. protection than SMEP can). SMAP's analog feature in PaX is called UDEREF
  29. which so far couldn't be efficiently implemented on amd64 (once again,
  30. i386/UDEREF will continue to rely on segmentation to provide better
  31. userland/kernel separation than SMAP can). Beyond allowing an efficient
  32. implementation of UDEREF there'll be other uses for SMAP (or perhaps a future
  33. variant of it) in PaX: sealed kernel memory whose access is carefully controlled
  34. even for kernel code itself.
  35. What does SMAP mean for security? Similarly to UDEREF, an SMAP enabled kernel
  36. will be prevented from accessing userland memory in unintended ways, e.g.,
  37. attacker controlled pointers can no longer target userland memory directly, but
  38. even simple kernel bugs such as NULL pointer based dereferences will just
  39. trigger a CPU exception instead of letting the attacker take over kernel data
  40. flow. Coupled with SMEP this means that future exploits against memory
  41. corruption bugs will have to entirely rely on targeting kernel memory (which has
  42. been the case under UDEREF/KERNEXEC for many years now). This of course means
  43. that for reliable exploitation detailed knowledge of runtime kernel memory will
  44. become a premium, therefore abusing bugs that leak kernel memory to userland
  45. will become the first step towards exploiting memory corruption bugs.
  46. While UDEREF and SMAP prevent gratuitous memory leaks, they still have to allow
  47. intended userland accesses and that is exactly the escape hatch that several
  48. exploits have already targeted and we can expect more in the future. Fortunately
  49. we are once again at the forefront of this game with several features that
  50. prevent or at least greatly reduce the amount of informaton that can be so
  51. leaked from the kernel to userland (HIDESYM, SANITIZE, SIZE_OVERFLOW, STACKLEAK,
  52. USERCOPY).
  53. TL;DR: Intel implements UDEREF equivalent 6 years after PaX, PaX will make use
  54. of it on amd64 for improved performance.