Announcement

Collapse
No announcement yet.

Intel Proposes Linux Kernel Driver Allow/Deny Filtering

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

  • Intel Proposes Linux Kernel Driver Allow/Deny Filtering

    Phoronix: Intel Proposes Linux Kernel Driver Allow/Deny Filtering

    As part of their work around Trust Domain Extensions (TDX) support for Linux, Intel engineers are proposing a driver filter option for Linux to be able to set allow or deny lists of driver(s) that can or cannot be loaded by the booted kernel...

    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
    Good idea.

    Comment


    • #3
      This looks easy to bypass... Just hex-edit the driver name to a fake one (e.g. rootkit to e1000) et voilĂ !

      Comment


      • #4
        Originally posted by tildearrow View Post
        This looks easy to bypass... Just hex-edit the driver name to a fake one (e.g. rootkit to e1000) et voilĂ !
        Not when they are signed for UEFI Secure Boot enforcement

        Edit: actually that's not the only use-case since modules can be checked against in-kernel trusted store even without Secure Boot.

        Comment


        • #5
          To me, the allow list looks like another way to lock down a device like an Android phone or Chromebook by preventing the end user from running custom compiled kernel modules.

          I can't think of very many use-cases for this outside of locking down devices to prevent loading modules to look for exploits and to lock down corporate workstations. I imagine most end-users installing Ubuntu or Arch won't want, need, or use this.

          Comment


          • #6
            Originally posted by skeevy420 View Post
            To me, the allow list looks like another way to lock down a device like an Android phone or Chromebook by preventing the end user from running custom compiled kernel modules.

            I can't think of very many use-cases for this outside of locking down devices to prevent loading modules to look for exploits and to lock down corporate workstations. I imagine most end-users installing Ubuntu or Arch won't want, need, or use this.
            As you saw in the story, it's mostly for guest virtual machines to prevent them from loading bad kernel modules.

            Comment


            • #7
              Originally posted by tildearrow View Post
              This looks easy to bypass... Just hex-edit the driver name to a fake one (e.g. rootkit to e1000) et voilĂ !
              If you have physical access you can do many things. I can delete my home dir, how does linux protect that? (rhetorical question)

              Comment


              • #8
                What about blacklists and whitelists lol. Man humanity has regressed.

                Still waiting for the activists to come for blackletter, black hats, black tie events, blackmail... seems they're already at war with being in the black. lol

                Comment


                • #9
                  Originally posted by microcode View Post
                  What about blacklists and whitelists lol. Man humanity has regressed.
                  OK. Here we go again

                  However, to me, "allow"/"deny" is just way more descriptive and natural than using colours to describe access control. But that may be a cultural thing

                  Comment


                  • #10
                    Allowing or disallowing drivers is already possible via module signature enforcement, except it's really not very user friendly. Maybe a better approach would be to design a tool to make it easy to use one's own key and sign selected drivers with it.

                    Comment

                    Working...
                    X