Announcement

Collapse
No announcement yet.

Linux 5.8 Set To Optionally Flush The L1d Cache On Context Switch To Increase Security

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

  • Linux 5.8 Set To Optionally Flush The L1d Cache On Context Switch To Increase Security

    Phoronix: Linux 5.8 Set To Optionally Flush The L1d Cache On Context Switch To Increase Security

    The Linux kernel patches that have been spearheaded by Amazon AWS engineers to optionally flush the L1 data cache on each context switch have now been queued in the x86/mm branch ahead of the upcoming Linux 5.8 kernel cycle...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    I just had to flush my cache after buffering some rather large logs. Almost had a buffer overflow...

    Comment


    • #3
      As each process has its own address space, flushing the L1 cache on context switches is hardly a big deal. I doubt that there's gonna be much of a performance drop, with most benchmarks showing no performance loss (of course, actual benchmarks can prove me wrong here).

      Comment


      • #4
        Originally posted by vladpetric View Post
        As each process has its own address space, flushing the L1 cache on context switches is hardly a big deal.
        What about .text segments from shared libs (e.g. libc)? For processes without much cache pressure, flushing that on every context switch seems wasteful. Not to mention the time it takes to perform the flush itself.
        Last edited by JustinTurdeau; 22 May 2020, 12:28 PM.

        Comment


        • #5
          Originally posted by JustinTurdeau View Post

          What about cached .text segments from shared libs (e.g. libc)? For processes without much cache pressure, flushing that on every context switch seems wasteful. Not to mention the time it takes to perform the flush itself.
          The text segment is code (it really should be cached in the instruction cache). This patch works on the L1 data cache.

          As for the cost of a flush - it greatly depends on how much modified data (cachelines that the current process wrote to) you have that hasn't been written back to the L2 (if you have writeback, as opposed to writethrough L1 caches, which you normally do). Because all the unmodified data can just be ignored. Essentially, if you have no writes whatsoever, there is no cost to flushing.

          That makes the cost somewhat difficult to asses. I would guess an average of 20-100 cycles, for modern processors, which in the case of a context switch is hardly a big deal.

          Comment


          • #6
            Suppose an Application that is reading from disk and does some calculation on the data. Every read the cache gets flushed which could slow down the calculation.

            Comment


            • #7
              Originally posted by vladpetric View Post
              The text segment is code (it really should be cached in the instruction cache). This patch works on the L1 data cache.
              Ah, good point. I overlooked that part.

              There's still plenty of data in shared libs though; e.g. lookup tables, etc. It's still a bunch of extra memory accesses that could have been cache hits and it still reduces the useful work done in every timeslice.
              Last edited by JustinTurdeau; 22 May 2020, 12:56 PM.

              Comment


              • #8
                ... as long as "mitigations=off" covers this as well

                Comment


                • #9
                  Originally posted by JustinTurdeau View Post

                  Ah, good point. I overlooked that part.
                  The other part of my point is likely incorrect.

                  I've actually looked at the patch itself, and their approach to flushing seems to be a brute force one - essentially write enough stuff (in a side buffer that nobody uses) to force everything out of the L1 cache

                  Like pressure washing.

                  Yeap, super slow.
                  Last edited by vladpetric; 22 May 2020, 12:54 PM.

                  Comment


                  • #10
                    I did look at the patch it is really slow, what I understand fast review what it doing

                    ctx from user to kernel mode
                    1) save user mode ctx and L1 cache
                    2) fill whole L1 cache with zero
                    3) upload kernel mode data to L1 cache

                    ctx from kernel to user mode
                    1) save kernel mode ctx and L1 cache
                    2) fill whole L1 cache with zero
                    3) upload usermode mode data to L1 cache

                    This is will make whole os very slow. we do not talk about few 100 cl here
                    it will make sure nothing can leak from the cache betwin user mode and kernel mode from the L1 cache any more.

                    But this patch is overdoing it.
                    Last edited by GreatLord; 22 May 2020, 02:25 PM.

                    Comment

                    Working...
                    X