Announcement

Collapse
No announcement yet.

Kernel Address Space Isolation Aims To Prevent Leaking Data From Hyper Threading Attacks

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

  • Kernel Address Space Isolation Aims To Prevent Leaking Data From Hyper Threading Attacks

    Phoronix: Kernel Address Space Isolation Aims To Prevent Leaking Data From Hyper Threading Attacks

    Kernel Address Space Isolation is an experimental feature in development by Oracle in aiming to prevent leaking sensitive data from Intel Hyper Threading due to speculative execution attacks like L1TF...

    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
    Has this been done by Windows already? (if I remember correctly on 32-bit Windows maps 0x00000000 to 0x7fffffff to user-space and 0x80000000 to 0xffffffff to kernel space)

    Comment


    • #3
      Originally posted by tildearrow View Post
      Has this been done by Windows already? (if I remember correctly on 32-bit Windows maps 0x00000000 to 0x7fffffff to user-space and 0x80000000 to 0xffffffff to kernel space)
      This is about even isolating different areas of the kernel, e.g. KVM.
      Michael Larabel
      https://www.michaellarabel.com/

      Comment


      • #4
        They mean to have fixed physical address (for kernel, process/KVM), not virtual. In normal conditions, when memory space is requested, kernel/process gets random pool of memory which used to be a part of another process in the past and this is a problem as it may contain sensitive information.

        Comment


        • #5
          Wonder how much the licence will cost.

          Comment


          • #6
            Originally posted by Milan Kerslager View Post
            They mean to have fixed physical address (for kernel, process/KVM), not virtual. In normal conditions, when memory space is requested, kernel/process gets random pool of memory which used to be a part of another process in the past and this is a problem as it may contain sensitive information.
            What does that even mean? Whatever it is, it’s nothing to do with this proposal, which as Michael says is meant to allow bits of the kernel (specifically kvm) to run in a separate address space that does not map most of the kernel, and as such prevents any leaks of the rest of kernel memory via side-channel leaks. It is meant as a mitigation for some of the side-channel issues that at present can only be fully mitigated by turning off hyperthreading.

            Comment


            • #7
              Can anyone explain why the HT-related side channel attacks can't be foiled by simply refusing to concurrently run tasks from different processes on the same physical core? In other words, if both hyper-threads sharing a core always belong to the same process, then you pretty much eliminate that attack vector.

              Comment


              • #8
                Originally posted by coder View Post
                Can anyone explain why the HT-related side channel attacks can't be foiled by simply refusing to concurrently run tasks from different processes on the same physical core? In other words, if both hyper-threads sharing a core always belong to the same process, then you pretty much eliminate that attack vector.
                The performance down side is the paired hyper-thread may sit idle. Not because there is no threads to run, but because there's no threads we trust to run at the same time.

                i.e. should a kernel thread and any user-thread run on the matched hyper-threaded pairs? Probably not.

                It's looking like "just disable hyper-threading on Intel" may be the way.






                Comment


                • #9
                  Originally posted by coder View Post
                  Can anyone explain why the HT-related side channel attacks can't be foiled by simply refusing to concurrently run tasks from different processes on the same physical core? In other words, if both hyper-threads sharing a core always belong to the same process, then you pretty much eliminate that attack vector.
                  You still have the problem that one thread might go into kernel mode, or one thread might switch from guest to hypervisor. An alternative to the proposed feature mentioned in the mail thread is exactly that though (for VM's), and in addition stop any SMT siblings if one thread switches to hypervisor.

                  Comment


                  • #10
                    Originally posted by JEBjames View Post
                    The performance down side is the paired hyper-thread may sit idle. Not because there is no threads to run, but because there's no threads we trust to run at the same time.
                    Well, of course there'd be a performance cost, but at least it should be better than completely disabling HT!

                    Comment

                    Working...
                    X