Announcement

Collapse
No announcement yet.

TPM HMAC Encryption Being Pulled Back To x86_64 By Default For Linux 6.10

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

  • TPM HMAC Encryption Being Pulled Back To x86_64 By Default For Linux 6.10

    Phoronix: TPM HMAC Encryption Being Pulled Back To x86_64 By Default For Linux 6.10

    One of the new security features coming with Linux 6.10 is TPM bus encryption and integrity protection to fend off a wave of possible attacks against Trusted Platform Module recovery keys, TPM sniffing, etc. This functionality was merged for the Linux 6.10 merge window but is now being pulled back to x86_64-only by default where it's been sufficiently tested...

    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
    Is it easy to disable or change that TPM crap?

    Comment


    • #3
      Just remember, there's a reason that TPM 1.x is "poo poo crapola", when it "was" the impenetrable "lock box" of choice at one time. That is, the, now required by Microsoft, TPM 2.x, is secure "today" and where all keys need to be created/placed, .... today. So, while I wouldn't say it's "crap", I would say we're banking on it. Even in Linux.

      Comment


      • #4
        Originally posted by timofonic View Post
        Is it easy to disable or change that TPM crap?
        Sure, you can just not use secure boot or TPM-backed dick encryption or any of the other features that make use of it. I don't see why you'd want that, though, given even the FSF (or was it the OSI? Or GNU? I forget which) have dine their analysis and figured that, no, it can't be used to further advance DRM or take away user freedoms. The way it's specced, you're still ultimately in control and, assuming it's implemented properly, it should fulfill its stated goal of improving security against unauthorized boot volume alterations and physical tampering.

        EDIT: I may have mixed up the FSF's position on SecureBoot (which is neutral-positive) with the GNU foundation's view on TPM2 (which is negative and views it as a big step towards locking people out of using computers as they want). I've read too much of Pottering's blog posts on trusted boot, and documentation on FIDO/WebAuthn to look past the potential benefits of TPM, though.

        EDIT2: FSF's position is mixed, depending on who's in control.



        When fully controlled by the user, TPM can be a useful way to strengthen encryption and user privacy, but when it's in the hands of Microsoft, we're not optimistic.‚Äč
        Last edited by Fifteen; 28 May 2024, 11:06 AM.

        Comment


        • #5
          I hope they don't enable this by default for fTPM (firmware TPM), as then the whole Ryzen sudden freeze debacle will start all over again.
          Last edited by emansom; 28 May 2024, 02:58 PM.

          Comment


          • #6
            Originally posted by timofonic View Post
            Is it easy to disable or change that TPM crap?
            What exactly is "that crap" that you are talking about and what exactly do you want to change it to?

            Sorry, but you sound like a /*stupid*/ illiterate person triggered over an acronym someone told them about while having absolutely no idea what that acronym actually represents. As evidenced by use of generic words with no substance. You don't know what it is, but you know that you want to do something with it, does not matter what, "disable", "change", anything!
            Last edited by intelfx; 29 May 2024, 12:07 AM.

            Comment


            • #7
              Originally posted by intelfx View Post
              What exactly is "that crap" that you are talking about and what exactly do you want to change it to?
              There are always people who want to disable cryptographic authentication and encryption. Some feel they, for example, decrease performance, while others believe they restrict access to data that should always be open source. It would be much better to use digital equipment without SSL/TLS in modern infrastructures and without unnecessary privacy requirements.

              Comment


              • #8
                How about writing the kernel in a more secure programming language like rust where safety verification takes place right at compilation unlike C. And just in case some C and C++ apologists get angry. Don't even start to debate me by telling the old argument that C and C++ were safe if developers were experienced and good enough. This is the whole point. There is more badly written C, C++ code than good one. We can't rely on a few very good programmers, go after bad ones, rework, patch and correct their shortcomings with growing complexity of the kernel. We don't have the capacities and time for this.

                I am convinced that companies could not talk the linux community into shady measures like tpm, if we closed potential security holes fundamentally at the base by transparent, open and clean means. We have them and we should use them. And yes i know this will take time.
                Last edited by M.Bahr; 29 May 2024, 04:54 AM.

                Comment


                • #9
                  Originally posted by M.Bahr View Post
                  How about writing the kernel in a more secure programming language like rust where safety verification takes place right at compilation unlike C. And just in case some C and C++ apologists get angry. Don't even start to debate me by telling the old argument that C and C++ were safe if developers were experienced and good enough. This is the whole point. There is more badly written C, C++ code than good one. We can't rely on a few very good programmers, go after bad ones, rework, patch and correct their shortcomings with growing complexity of the kernel. We don't have the capacities and time for this.

                  I am convinced that companies could not talk the linux community into shady measures like tpm, if we closed potential security holes fundamentally at the base by transparent, open and clean means. We have them and we should use them. And yes i know this will take time.
                  Writing a kernel in Rust does not make the system secure.
                  Writing a kernel in Rust does not make TPM or other secure elements useless.
                  Writing a kernel in Rust does not make communication with TPM secure.

                  Comment


                  • #10
                    Originally posted by Jakobson View Post

                    Writing a kernel in Rust does not make the system secure.
                    Writing a kernel in Rust does not make TPM or other secure elements useless.
                    Writing a kernel in Rust does not make communication with TPM secure.
                    I would appreciate if you actually let be the cheap rhetorics like your red herings and strawmen. I didn't claim all of this! I was talking about giving the linux kernel a more robust base against major problems in computer architecture like memory safety. This is one of the main attack surfaces of hackers. You would know this if you were a programmer or got a deeper understanding about how a computer actually works. I am talking about tackling a major problem at its roots. Of course rust doesn't guarantee absolute security. This is a naive and idiotic objection, sorry ...

                    Whoever promotes TPM is not sane in his mind from a security standpoint or got absolutely no clue about security at all. TPM is only a temporal patch. Once the system got infiltrated it can serve as an legit backdoor. This is a well known conceptional weak point. In principal all hardware security implementations violate the zero trust concept. Another big concern is the delegation of security to one or limited sources, which can be infiltrated or corrupted themselves.

                    Comment

                    Working...
                    X