Announcement

Collapse
No announcement yet.

Call Depth Tracking Aligning For Linux 6.2 To Lessen Mitigation Performance Hit For Intel Skylake

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

  • Call Depth Tracking Aligning For Linux 6.2 To Lessen Mitigation Performance Hit For Intel Skylake

    Phoronix: Call Depth Tracking Aligning For Linux 6.2 To Lessen Mitigation Performance Hit For Intel Skylake

    While the Linux 6.1 merge window just passed and the "Call Depth Tracking" patches have been in development the past few months, it looks like that for the Linux 6.2 kernel is where that alternative mitigation technique will be introduced for helping offset some of the significant performance regressions incurred for Intel Skylake era processors as a result of recent CPU security vulnerability mitigations...

    https://www.phoronix.com/news/Call-Depth-Tracking-6.2

  • #2
    Where is the stuffing *less* safe? The first thing that comes to mind for me is calling into into system firmware, even potentially during unwilling calls.

    Comment


    • #3
      Originally posted by Developer12 View Post
      Where is the stuffing *less* safe? The first thing that comes to mind for me is calling into into system firmware, even potentially during unwilling calls.
      it's not actually known whether it's less safe or not. IBRS is known to completely mitigate Retbleed. this stuffing *probably* does, too, but we don't know for sure. it does at least make Retbleed attacks a lot more difficult and has much less performance impact than IBRS.
      Last edited by hotaru; 20 October 2022, 02:15 PM.

      Comment


      • #4
        Originally posted by hotaru View Post

        it's not actually known whether it's less safe or not. IBRS is known to completely mitigate Retbleed. this stuffing *probably* does, too, but we don't know for sure. it does at least make Retbleed attacks a lot more difficult and has much less performance impact than IBRS.
        It most definitely can't do anything about underflows that occur in the return stack buffer during a call into firmware (eg radeon atombios or uefi) or an unintended/unwitting call into system management mode. In both cases code that the CPU executes is outside the kernel's control. I suppose it also can't mitigate userspace, being as it can't track calls that occur there, where as IBRS is more comprehensive instead.

        Comment

        Working...
        X