Stories
Slash Boxes
Comments

SoylentNews is people

posted by martyb on Sunday August 20 2017, @12:07PM   Printer-friendly [Skip to comment(s)]
from the TLA-Approved? dept.

Submitted via IRC for TheMightyBuzzard

Since the launch of AMD Ryzen, a small piece of hardware that handles basic memory initialization as well as many security functions has been the center of some controversy. Called the Platform Security Processor (the "PSP" for short) it is essentially an arm core with complete access to the entire system. Its actions can be considered "above root" level and are for the most part invisible to the OS. It is similar in this regard to Intel's Management Engine, but is in some ways even more powerful.

Why is this a bad thing? Well, let's play a theoretical. What happens if a bug is discovered in the PSP, and malware takes control of it? How would you remove it (Answer: you couldn't). How would you know you needed to remove it? (answer, unless it made itself obvious, you also wouldn't). This scenario is obviously not a good one, and is a concern for many who asked AMD to open-source the PSPs code for general community auditing.

Bit late to the reporting but we haven't covered it yet, so here it is. And I was so looking forward to a new desktop too. Guess this one will have to stay alive until ARM becomes a viable replacement.

Source: https://www.techpowerup.com/235313/amd-confirms-its-platform-security-processor-code-will-remain-closed-source

Previous:
The Intel Management Engine, and How it Stops Screenshots
Intel x86 Considered Harmful
Of Intel's Hardware Rootkit
Intel Management Engine Partially Defeated
EFF: Intel's Management Engine is a Security Hazard
Malware uses Intel AMT feature to steal data, avoid firewalls


Original Submission

Related Stories

The Intel Management Engine, and How it Stops Screenshots 52 comments

Over at Hackernews is a link to a discussion on how the Intel Management Engine (ME) is preventing screenshots, by bypassing the host CPU.

If you're on an Intel machine that you've purchased in the past 2-3 years, that computer almost certainly has an Intel Management Engine. You might not know what that is, and that's okay. You may also be unaware that the operating system on your computer could be leveraging features in the Intel Management Engine when consuming DRM Media.

This links to a blog posting on the Intel ME in response to Rosyna Keller's twitter posting about being unable to take screenshots from Netflix (The Rosyna of the article title).

The core of the technical detail is taken from Igor Skochinsky's presentation on the ME (PDF Link) . The article raises the questions over the position of the ME in the system and the security implications of the ME subverting the host machine hardware outside of the main processor:

Given that the ME sits in a position where it can configure the chipset and operate on the PCI bus, there are some serious security implications here I wish I could mitigate. Among them is the ability of the ME to run arbitrary code on the host CPU via option ROMs or presenting a disk-drive to boot from. Also among those abilities is the possibility to perform DMA to access host CPU memory. And another one is the ability to configure and use PCI devices present in the system (such as the ethernet card).

Intel x86 Considered Harmful 33 comments

Joanna Rutkowska's blog points to recent paper on a survey of the various problems and attacks presented against the x86 platform over the last 10 years. The paper does not present new exploits but does cover: the BIOS (UEFI) and booting; peripherals; the Intel Management Engine; and several other aspects of x86 insecurity. Some of the problems appear insurmountable as described.


Original Submission

Of Intel's Hardware Rootkit 93 comments

From Damien Zammit, we have this fun little tidbit:

Recent Intel x86 processors implement a secret, powerful control mechanism that runs on a separate chip that no one is allowed to audit or examine. When these are eventually compromised, they'll expose all affected systems to nearly un-killable, undetectable rootkit attacks. I've made it my mission to open up this system and make free, open replacements, before it's too late.

The Intel Management Engine (ME) is a subsystem composed of a special 32-bit ARC microprocessor that's physically located inside the chipset. It is an extra general purpose computer running a firmware blob that is sold as a management system for big enterprise deployments.

When you purchase your system with a mainboard and Intel x86 CPU, you are also buying this hardware add-on: an extra computer that controls the main CPU. This extra computer runs completely out-of-band with the main x86 CPU meaning that it can function totally independently even when your main CPU is in a low power state like S3 (suspend).

On some chipsets, the firmware running on the ME implements a system called Intel's Active Management Technology (AMT). This is entirely transparent to the operating system, which means that this extra computer can do its job regardless of which operating system is installed and running on the main CPU.

The purpose of AMT is to provide a way to manage computers remotely (this is similar to an older system called "Intelligent Platform Management Interface" or IPMI, but more powerful). To achieve this task, the ME is capable of accessing any memory region without the main x86 CPU knowing about the existence of these accesses. It also runs a TCP/IP server on your network interface and packets entering and leaving your machine on certain ports bypass any firewall running on your system.

Yeah, and I'm sure they pinky-swear never to allow the NSA access to any computer via it. I'll be using AMD from now on, slower or not, thanks.


Original Submission

Intel Management Engine Partially Defeated 39 comments

In some shiny good news to us of the tinfoil hat crew, Phoronix is reporting:

Many free software advocates have been concerned by Intel's binary-only Management Engine (ME) built into the motherboards on newer generations of Intel motherboards. The good news is there is now a working, third-party approach for disabling the ME and reducing the risk of its binary blobs.

Via an open-source, third-party tool called me_cleaner it's possible to partially deblob Intel's ME firmware images by removing any unnecessary partitions from the firmware, reducing its ability to interface with the system. The me_cleaner works not only with free software firmware images like Coreboot/Libreboot but can also work with factory-blobbed images. I was able to confirm with a Coreboot developer that this program can disable the ME on older boards or devices with BootGuard and disable Secure Boot. This is all done with a Python script.

Those unfamiliar with the implications on Intel's ME for those wanting a fully-open system can read about it on Libreboot.org.

Looks like I may not have to go ARM on my next desktop build after all.


Original Submission

EFF: Intel's Management Engine is a Security Hazard 50 comments

Submitted via IRC for TheMightyBuzzard

Since 2008, most of Intel's chipsets have contained a tiny homunculus computer called the "Management Engine" (ME). The ME is a largely undocumented master controller for your CPU: it works with system firmware during boot and has direct access to system memory, the screen, keyboard, and network. All of the code inside the ME is secret, signed, and tightly controlled by Intel. Last week, vulnerabilities in the Active Management (AMT) module in some Management Engines have caused lots of machines with Intel CPUs to be disastrously vulnerable to remote and local attackers. While AMT can be disabled, there is presently no way to disable or limit the Management Engine in general. Intel urgently needs to provide one.

[...] EFF believes that Intel needs to provide a minimum level of transparency and user control of the Management Engines inside our computers, in order to prevent this cybersecurity disaster from recurring. Unless that happens, we are concerned that it may not be appropriate to use Intel CPUs in many kinds of critical infrastructure systems.

It's a crying shame the what the EFF says doesn't hold a whole lot of weight.

Source: The Electronic Frontier Foundation


Original Submission

Malware uses Intel AMT feature to steal data, avoid firewalls 56 comments

Malware uses Intel AMT feature to steal data, avoid firewalls

Microsoft's security team has come across a malware family that uses Intel's Active Management Technology (AMT) Serial-over-LAN (SOL) interface as a file transfer tool.

Because of the way the Intel AMT SOL technology works, SOL traffic bypasses the local computer's networking stack, so local firewalls or security products won't be able to detect or block the malware while it's exfiltrating data from infected hosts.

and . . .

Intel AMT SOL exposes hidden networking interface

This is because Intel AMT SOL is part of the Intel ME (Management Engine), a separate processor embedded with Intel CPUs, which runs its own operating system.

Intel ME runs even when the main processor is powered off, and while this feature looks pretty shady, Intel built ME to provide remote administration capabilities to companies that manage large networks of thousands of computers.

I always believed the Intel Management Engine was a bad idea and a huge target for sophisticated hackers. Your hardware. Pre-compromised from the factory. A processor baked into your microprocessor with full access to the hardware. It runs a secret binary blob -- and the primary microprocessor won't run without it.

This probably isn't the last time that this will be exploited. Probably not even be the first, given the difficulty to detect it. The wonderful thing is that your OS isn't aware of the compromise and is unable to interfere with it.


Original Submission

PSPtool Allows Further Investigation of AMD's Platform Security Processor 11 comments

AMD Secure Technology PSP Firmware Now Explorable, Thanks to Researcher's Tool

A security researcher this week released the PSPtool, a software tool that "aims to lower the entry barrier for looking into the code running" on the AMD Platform Security Processor (PSP), officially known as AMD Secure Technology, and other AMD subsystems. The PSP serves similar functions to those of Intel's Management Engine (ME) processor. However, just like the Intel ME, the secretive and undocumented nature of the chip worries security and privacy advocates.

The researcher going by the online name of cwerling described the PSPTool as a "Swiss Army knife" for dealing with the AMD PSP's firmware. The tool is based on reverse-engineering efforts of AMD's proprietary file system that the company uses to pack firmware blobs into UEFI firmware images.

Usually, all firmware blobs can be parsed by another software program called the UEFITool. However, in this case AMD's firmware files are located in padding volumes that can't be parsed by the UEFITool. This is the reason for the PSPTool, which can locate the PSP firmware within UEFI images and parse it. Through this tool, more researchers can look into what their local PSP chip is doing to their computers, as its actions are normally hidden from the operating system or the main processor.

Previously: AMD to Consider Coreboot/Libreboot Support
AMD Confirms its Platform Security Processor Code will Remain Closed-Source

Related: Intel Management Engine Partially Defeated
EFF: Intel's Management Engine is a Security Hazard\
Disabling Intel ME 11 Via Undocumented Mode
Intel Management Engine Critical Firmware Update
HP Chip Protects Intel's Management Engine


Original Submission

This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
(1)
  • (Score: 2) by jasassin on Sunday August 20 2017, @12:19PM (4 children)

    by jasassin (3566) <jasassin@gmail.com> on Sunday August 20 2017, @12:19PM (#556657) Journal

    With all the instability problems I've been reading about with the Ryzen systems (too lazy to cite on an android), this is the least of their worries.

    Lot's of upset people with their Ryzen systems seg-faulting (very quickly under max load [there's even a shell script called kill-ryzen.sh]). I highly recommend avoiding Ryzen until this problem has been solved.

    --
    jasassin@gmail.com Key fingerprint = 0644 173D 8EED AB73 C2A6 B363 8A70 579B B6A7 02CA
    • (Score: 2) by vux984 on Sunday August 20 2017, @12:42PM (2 children)

      by vux984 (5045) on Sunday August 20 2017, @12:42PM (#556661)

      Really? I read the newer threadripper cpus didn't have issue.

      • (Score: 2) by jasassin on Sunday August 20 2017, @01:11PM (1 child)

        by jasassin (3566) <jasassin@gmail.com> on Sunday August 20 2017, @01:11PM (#556664) Journal

        Really? I read the newer threadripper cpus didn't have issue.

        Time will tell. I wouldn't spend $999 to find out. Someone will. If Ryzen is still busted, why would you buy threadripper?

        --
        jasassin@gmail.com Key fingerprint = 0644 173D 8EED AB73 C2A6 B363 8A70 579B B6A7 02CA
        • (Score: 2) by vux984 on Sunday August 20 2017, @07:31PM

          by vux984 (5045) on Sunday August 20 2017, @07:31PM (#556762)

          Time will tell. I wouldn't spend $999 to find out. Someone will.

          I think that's the point - they already did. all the various hardware forums and testing sites that I have seen that have tested it, have found that it doesn't seg fault under high thread load etc.

          If Ryzen is still busted, why would you buy threadripper?

          Why would I buy a product that is not busted?? The answer is in the question.

    • (Score: 2) by tibman on Sunday August 20 2017, @07:04PM

      by tibman (134) Subscriber Badge on Sunday August 20 2017, @07:04PM (#556754)

      I've been running a Ryzen 7 1800x since launch. Haven't had issues. The only ongoing issue that i know of is highly parallel compiling on linux. Sucks for Gentoo users out of the box.

      --
      SN won't survive on lurkers alone. Write comments.
  • (Score: 2) by c0lo on Sunday August 20 2017, @01:48PM (7 children)

    by c0lo (156) Subscriber Badge on Sunday August 20 2017, @01:48PM (#556673) Journal

    And I was so looking forward to a new desktop too. Guess this one will have to stay alive until ARM becomes a viable replacement.

    When ARM will become a viable replacement for AMD... you can expect a "security processor" be embedded - perhaps it will be an Intel Atom?

    --
    https://www.youtube.com/watch?v=aoFiw2jMy-0
    • (Score: 3, Interesting) by takyon on Sunday August 20 2017, @01:55PM (5 children)

      by takyon (881) <{takyon} {at} {soylentnews.org}> on Sunday August 20 2017, @01:55PM (#556675) Journal

      Hack the ARM PSP in AMD chips, then run all your code on a single tiny ARM core.

      --
      [SIG] 10/28/2017: Soylent Upgrade v14 [soylentnews.org]
      • (Score: 2) by opinionated_science on Sunday August 20 2017, @02:01PM

        by opinionated_science (4031) on Sunday August 20 2017, @02:01PM (#556678)

        it would be interesting to establish the "lowest power active state" of a PC.

        AMD could get a huge leap if they let us into this chip, as developers could make neat code that could run in the background , *by* the user.

        Not the system...

      • (Score: 0) by Anonymous Coward on Sunday August 20 2017, @02:22PM (3 children)

        by Anonymous Coward on Sunday August 20 2017, @02:22PM (#556684)

        Once you achieve that first point, there is little reason to distrust the AMD cores any more, is there?

        And we already have open-source implementations running on ARM's PSP: https://archive.fosdem.org/2016/schedule/event/microkernels_genode_usb_armory/ [fosdem.org]

        • (Score: 2) by takyon on Sunday August 20 2017, @02:44PM (2 children)

          by takyon (881) <{takyon} {at} {soylentnews.org}> on Sunday August 20 2017, @02:44PM (#556692) Journal

          I made that comment after I woke up and it's the very definition of overrated.

          To be clear, nobody has been able to slap open source code onto a TrustZone ARM in an AMD chip?

          --
          [SIG] 10/28/2017: Soylent Upgrade v14 [soylentnews.org]
          • (Score: 2, Insightful) by Anonymous Coward on Sunday August 20 2017, @04:32PM (1 child)

            by Anonymous Coward on Sunday August 20 2017, @04:32PM (#556713)

            ARM is not viable because TrustZone does the...
            same as the PSP, it has a stage 0 bootloader burned into the SoC on all modern ARM processors that either completely disables the TrustZone support (rendering you unable to use it for your own purposes, as well as unable to load OEM support for it in relation to apps that require it for DRM purposes) or enables it, but only with OEM signed images and thus leaves you unable to run your own code inside it, same as the problem with AMD's PSP and Intel's ME implementations.

            Having said all this: If VIA Technologies wasn't a bunch of mismanaged retards, they have the perfect opportunity here to reenter the PC market, make end to end open systems (big if since their shit is closed source because of all the patent violations they have, even after all their 'patent licensing/covenants', they could easily coup 1-5 percent of the PC market so long as their hardware supported 16+ gigs of ram and ~3ghz+ clockrates. There are quite a few people who would take 2012 era performance if they could ensure pre-ME levels of information security (which may or may not be a mistaken belief, but given that we are down to 3 hardware manufacturers for all PC hardware in the world, all basically beholden to the US Government and affiliated foreign intelligence agencies and a notoriously long lived agenda of backdooring hardware or software all in the name of 'security', this isn't a far fetched concern to have.

            Sadly as they haven't produced a new design in 5 years and charge 400+ dollars for itx or smaller embedded computers without even ECC support, I can't see them getting something to market before x86 has finally lost its relevance to the market.

            • (Score: 2) by vux984 on Sunday August 20 2017, @07:39PM

              by vux984 (5045) on Sunday August 20 2017, @07:39PM (#556766)

              There are quite a few people who would take 2012 era performance if they could ensure pre-ME levels of information security

              I don't think it's anywhere near the 1-5% range though. Take the people who use linux on the desktop, and then from that group take the people who would sacrifice power consumption, performance, etc, etc for the added possible security. There are lots of reasons to use linux and better/knowable security from the silicon up thanks to more openness is just one of them. You are looking at maybe 0.05% to 0.1%.

    • (Score: 2) by TheRaven on Monday August 21 2017, @08:21AM

      by TheRaven (270) on Monday August 21 2017, @08:21AM (#556923) Journal

      ARM provides a feature called TrustZone that is integrated with the memory bus and allows you to restrict access to parts of physical memory to cores or peripherals running in a designated secure state. Some implementations, such as Apple's, use this in conjunction with a separate core that can protect itself against the rest of the system and can store encryption keys without the rest of the system being able to access them.

      The problem is not the existence of such a coprocessor, it's the fact that it's running code over which the user has no control. On an iOS device, this isn't much of a problem: almost all of the code is out of the user's control, so the fact that the secure core is out of their control isn't much different. On a general-purpose machine, it's a problem, but currently ARM provides sample code to run in the secure enclave but users can replace it (as long as the SoC maker doesn't prevent them from doing so).

      --
      sudo mod me up
  • (Score: 1, Interesting) by Anonymous Coward on Sunday August 20 2017, @02:07PM (9 children)

    by Anonymous Coward on Sunday August 20 2017, @02:07PM (#556679)

    The code in question must include a driver of sorts for the onboard ethernet. So disable that and get an ethernet card that uses a different chip. This has not been tested but "should work". Can anyone show how this wouldn't work? Thanks.

    • (Score: 3, Interesting) by jasassin on Sunday August 20 2017, @02:30PM (1 child)

      by jasassin (3566) <jasassin@gmail.com> on Sunday August 20 2017, @02:30PM (#556688) Journal

      It's hard to disable code that is built into hardware that cannot be disassembled without destroying the hardware itself. Disabling the ethernet section of the code (if that were possible) would make no difference because the chip has access to all memory and underlying hardware. The only way to be sure is to setup a firewall between the hardware and the internet and watch every packet that goes in and out. If the device starts sending packets to some address... then you know. Without something in the middle to tell you will be completely oblivious.

      Now, I am not a network programmer. I know there are layers below TCP/IP. Perhaps these clandestine transmissions could bypass detection from say a FreeBSD router with two ethernet cards. I do not know. If it does. I'd sure love to know how to send information across the internet at a level that low.

      --
      jasassin@gmail.com Key fingerprint = 0644 173D 8EED AB73 C2A6 B363 8A70 579B B6A7 02CA
      • (Score: 1, Informative) by Anonymous Coward on Monday August 21 2017, @03:25AM

        by Anonymous Coward on Monday August 21 2017, @03:25AM (#556862)

        TCP/UDP (inet routable) → IP (inet routable) → MAC (link local) → Ethernet (link local)

        OSI model [wikipedia.org]

        I'd sure love to know how to send information across the internet at a level that low.

        I don't believe this is possible, unless..,

        What's really going to bake your noodle later on is whether or not this code detects packets with the evil bit set, intercepts them, and prevents the OS network driver from even seeing them.

        Of course there's also things like hiding a payload in ICMP packets or whatnot. Perhaps sufficiently advanced stenography could hijack DNS queries without hiding them from the OS network driver and without alerting security researchers to the presence of stenography. I'm certain the NSA has thought about all of this before.

        It's too bad the NSA's mission cannot be changed from weakening information system security to building the most hardened information system security possible. (Something a bit easier to approach than selinux plz.)

    • (Score: 2) by Runaway1956 on Sunday August 20 2017, @02:33PM (6 children)

      by Runaway1956 (2926) Subscriber Badge on Sunday August 20 2017, @02:33PM (#556690) Homepage Journal

      Uhhhh - if the ARM has super-root, and you can't control the ARM, then how do you know that the network is disabled? For a wired network, just unplug it, right? But, how 'bout wireless? I suppose you could snip a wire to ensure the network is disabled . . .

      (yes, I took the liberty of replacing your "ethernet" with "network" for the purpose of pointing out that you don't know what's enabled or disabled if you can't see what the chip is doing)

      --
      Taking bets: When does Biden's approval rating reach 15%?
      • (Score: 2) by jasassin on Sunday August 20 2017, @02:46PM (5 children)

        by jasassin (3566) <jasassin@gmail.com> on Sunday August 20 2017, @02:46PM (#556693) Journal

        From the article: Bit late to the reporting but we haven't covered it yet, so here it is. And I was so looking forward to a new desktop too. Guess this one will have to stay alive until ARM becomes a viable replacement.

        The fucking chip controlling the spy bullshit is ARM so he wants to wait for an ARM based CPU to solve his problems. I am confused. Help me out here Runaway1956. Please.

        --
        jasassin@gmail.com Key fingerprint = 0644 173D 8EED AB73 C2A6 B363 8A70 579B B6A7 02CA
        • (Score: 2) by Runaway1956 on Sunday August 20 2017, @03:57PM (4 children)

          by Runaway1956 (2926) Subscriber Badge on Sunday August 20 2017, @03:57PM (#556707) Homepage Journal

          I'm not quite certain, but it seems that ARM CPU's are open source, whereas this specific chip is not. Whether that be so or not, if he has an ARM CPU, then apparently he has access to the CPU's full functionality. Here, we have an ARM which is not accessible by the operating system. The OS only seens the x86 chip, and can't see the ARM. What would we even call this - a parallel installation of the hardware? Customer accessible CPU can do almost anything, the non-customer accessible CPU can do anything at all, in secret.

          All of that leads me to wonder why any other CPU can't be wired into a system to snoop on the system. Just build a dual CPU mainboard, let the customer have access to one side, and keep the other side for your own nefarious purposes. Isn't that exactly what is described here, except the second CPU is considerably less powerful than the customer-accessible chip?

          --
          Taking bets: When does Biden's approval rating reach 15%?
          • (Score: 1, Insightful) by Anonymous Coward on Sunday August 20 2017, @04:06PM (3 children)

            by Anonymous Coward on Sunday August 20 2017, @04:06PM (#556710)

            All modern arm cpu's have a similar negative ring trustzone cpu. This is the only reason why you can buy hollywood movies and music on your android and iphone.

            • (Score: 2) by Runaway1956 on Sunday August 20 2017, @04:23PM (1 child)

              by Runaway1956 (2926) Subscriber Badge on Sunday August 20 2017, @04:23PM (#556712) Homepage Journal

              I wasn't aware of that. That makes the GP's quote even more interesting. Why is the author waiting for an ARM CPU then?

              --
              Taking bets: When does Biden's approval rating reach 15%?
              • (Score: 1, Interesting) by Anonymous Coward on Sunday August 20 2017, @04:38PM

                by Anonymous Coward on Sunday August 20 2017, @04:38PM (#556714)

                Also *SOME* very few ARM SoCs are programmed with stage0 bootloaders (mostly for development boards) that allows you to program the trustzone ring/core yourself (TrustZone can be implemented either as time sharing inside of a shared ARM core, or using a dedicated ARM core with memory maps separating 'trusted' and 'untrusted' regions of memory and i/o devices.)

                A few may also allow a toggle switch which can enable/disable the firmware signing check, but in practice no manufacturer producing a non-dev board actually does that, since it might negatively affect DRM certification, the same I assume was the original reason for the Intel ME and then AMD PSP crap (but given the push for decryption capabilities by Congress, Intelligence Agencies, and Law Enforcement, I assume it has become a major cornerstone of their new encryption breakage strategies, since either pulling the keys out via the management cores or reducing the entropy of the RNG is a lot easier than trying to brute force the keys/'truly random' keys later on.

            • (Score: 0) by Anonymous Coward on Sunday August 20 2017, @10:38PM

              by Anonymous Coward on Sunday August 20 2017, @10:38PM (#556804)

              I would never buy hollywood videos or music on my phone

  • (Score: 0) by Anonymous Coward on Sunday August 20 2017, @03:08PM (3 children)

    by Anonymous Coward on Sunday August 20 2017, @03:08PM (#556695)

    Can't someone decap one of the processors and read the contents of PSP?
    What about using a electron microscope?

    • (Score: 0) by Anonymous Coward on Sunday August 20 2017, @03:49PM (1 child)

      by Anonymous Coward on Sunday August 20 2017, @03:49PM (#556702)

      Ask the NSA.

      • (Score: 2) by requerdanos on Sunday August 20 2017, @11:19PM

        by requerdanos (5997) on Sunday August 20 2017, @11:19PM (#556810) Journal

        Can't someone decap one of the processors and read the contents of PSP?
        What about using a electron microscope?

        Ask the NSA.

        Asking publicly in a forum buzzing with keywords about encryption and backdoors* == asking the NSA directly.

        * or anywhere mentioning bomb, president, allah, terrorist acts, holy fire, etc. I'm sure they don't (always) read it live over the wire, but they sure flag it for review. Hi guys--Go Redskins.

    • (Score: 0) by Anonymous Coward on Sunday August 20 2017, @04:49PM

      by Anonymous Coward on Sunday August 20 2017, @04:49PM (#556717)

      The stored code is encrypted, signed with a master key of which only the private key is available in the cpu. So you COULD in theory pull out the decryption key and decrypt the code stored in prom in the CPU or an image from flash/update file. However you may or may not be able to figure out the image, and since you can't modify it without failing the checksum, it becomes a lot more difficult to debug it to attempt to reverse engineer what sections of it do. There is a series of blog posts somewhere covering what was required to reverse engineer the information needed for the me_cleaner utility up on github. Suffice it to say it took multiple people 3-5 years including numerous false starts to get far enough along to realize they could zero out sections of the firmware to disable features, and what regions had checksums in them that had to be available and what they were summed against to ensure the system would boot and stay booted up while disabling all the components that (hopefully!) contained the features of concern. And even then said modifications would result in the loss of the software TPM, which nobody should really use since the key extraction I mentioned in previous threads is completely possible if either a bug or intentional backdoor were inserted into that code. But as it is if you have software that requires TPM attestation to run, your only choices are not to run it, or open up the potential for TPM code related backdoors on systems with the Intel AMT/ME code running on them. (Which there are systems with seperate TPM chips, like many retail motherboards had/have headers for, basically all Intel notebooks use the software TPM in place of a hardware model, hence the loss of all TPM/attestation features if you remove those regions using me_cleaner from your firmware image, which btw, is not a trivial task itself, since the ME also blanks and/or locks memory ranges in the SPI flash leaving you unable to reflash from firmware from in-system without a valid checksum. Thankfully external flashing still works so long as the correct checksums for ME components exist in the modified firmware image.

  • (Score: 5, Informative) by RamiK on Sunday August 20 2017, @03:14PM

    by RamiK (1813) on Sunday August 20 2017, @03:14PM (#556696)

    Root is the lowest UID (0) and everything above it is userland. So if anything, it's "below root" or sub-root.

    Though more importantly, stop making up terminology and use the following:

    Ring 3: user-mode: root starts here.

    Ring 0: kernel-mode. supervisor. Restricted to kernel modules.

    Ring -1: optional hypervisor. using your CPU.

    Ring -2: SMM. still using your CPU.

    Ring -3: AMT\ME\PSP. using a special processor.

    Ring -2 and -3 are separated since compromising the SMM doesn't mean you can execute arbitrary code on the ME processor. But compromising ring -3 means you own everything.

    Similarly -1 and -2 since compromising the hypervisor doesn't give you access to the SMM functions.

    Same follows...

    --
    compiling...
  • (Score: 1, Informative) by Anonymous Coward on Sunday August 20 2017, @04:42PM (5 children)

    by Anonymous Coward on Sunday August 20 2017, @04:42PM (#556716)

    And I was so looking forward to a new desktop too. Guess this one will have to stay alive until ARM becomes a viable replacement.

    Or you could buy a TALOS now. [raptorcs.com]

    • (Score: 0) by Anonymous Coward on Sunday August 20 2017, @04:57PM

      by Anonymous Coward on Sunday August 20 2017, @04:57PM (#556719)

      You could buy a *LOT* of LGA775/AM3/AM3+/G34 systems, including in fact Raptor Engineering's own ported libreboot bios for the ASUS Dual G34 board.

      And as a point defeating the purchase of their Talos board (which I will note is pretty nice since it supports dual Power9 gpus, DDR4, and PCIe4 (the latter needed to take full advantage of current gen GPGPUs (AMD/Nvidia or Intel's Xeon Phi PCIe Boards) with 64 bit BAR and IOMMU)) the Talos board contains DUAL BROADCOM ETHERNET ADAPTERS. The Broadcom notorious for their NDAs, and hardware with sufficient cpu resources in it to be backdoored with network accessible rootkits without ever hitting the system proper. Like that wifi exploit that was just discovered in one of the b43xx(x) chipsets...

      There were a few other similarly concerning pieces of hardware in there, excluding one's trust/distrust of IBM built processors.

    • (Score: 2) by requerdanos on Sunday August 20 2017, @11:48PM (3 children)

      by requerdanos (5997) on Sunday August 20 2017, @11:48PM (#556813) Journal

      I was so looking forward to... ARM becomes a viable replacement... etc.

      Or you could buy a TALOS now.

      Well, the TALOS dual-processor (therefore 8-core) motherboard with CPUs+Fans and 32GB of RAM seems to run about US$3200 [raptorcs.com], whereas earlier this year I spent about $638 on a motherboard with an 8 core Ryzen* chip+CPU Cooler and 32GB RAM, for a difference of over $2500.

      Granted the talos is a much higher-end piece of equipment, but I don't need all that workstation-server-high-end-y bit; I just want fast cores that anticipate my every need as well as modern technology can. Plus, the $638 was a stretch financially; I couldn't do $3200 for a single motherboard combo. And technically you can pre-order now, but I wouldn't go so far as to say that you can "buy" one right now.

      As an aside, I wonder how the two motherboards I mention would benchmark against each other with things like gcc and handbrake (which eat more of my CPU cycles than anything else, I reckon).

      To stress: It is enormously important for equipment I buy to be my servant, not someone else's. It's shameful that this should even be a point to be negotiated. It's right there in Asimov's laws [xkcd.com], law #2**, codified before I was even born.

      *Ryzen: Yes, it's pretty easy to get it to segfault. I can do it at will with simple operations that my previous AMD FX chip handled fine; I don't even have to stress all the cores at once. To use a car analogy, it's like a fiberglass sportscar: "fast but crashy".

      ** Law #2 technically says obey orders of "humans," not the owner, but the first law, not allowing humans to come to harm, would prevent the manufacturer from foisting a PlatformSecurityProcessor or ManagementEngine on me, harming me (to whatever extent).

      • (Score: 3, Informative) by Marand on Monday August 21 2017, @01:15AM (2 children)

        by Marand (1081) on Monday August 21 2017, @01:15AM (#556821) Journal

        *Ryzen: Yes, it's pretty easy to get it to segfault. I can do it at will with simple operations that my previous AMD FX chip handled fine; I don't even have to stress all the cores at once.

        You may have a problem with your memory settings, especially voltages. I've been messing with it since March and it seems that a lot of RAM's advertised timings and voltages (especially XMP profiles) are just completely useless. After some trial and error, the only segfaults I'm getting now are from the massive parralel compiles that are intended to cause them and a known problem with some early chips. (Fairly minor issue in practice, but hoping for a microcode fix.) I had to bump the cpu northbridge voltage and the RAM voltages up slightly to get it stable, though. The chips' profile suggests they can run at 1.2v but they'r ridiculously unstable at that, even with 2T command rate. (Early AM4 BIOSes were locked to 1T, which made it even worse.)

        If it's that crashy for you, make sure you've got the latest BIOS for your board and start tweaking some. Also, try disabling Core C6 state (a power saving option), it's been reported to help on Linux.

        • (Score: 0) by Anonymous Coward on Monday September 04 2017, @07:33PM (1 child)

          by Anonymous Coward on Monday September 04 2017, @07:33PM (#563535)

          If you have a Gigabyte motherboard, check there isn't a bios update; a recent bios for the 350 series (I think; my memory is not what it was) had some stupid bug - a 0.5 where they meant 0.05 or something like that - which resulted in it basically overclocking the chipset and CPU to the point it was throttling. Apparently they don't test their shit before unleashing it on the unsuspecting public.

          • (Score: 2) by Marand on Wednesday September 06 2017, @07:04AM

            by Marand (1081) on Wednesday September 06 2017, @07:04AM (#564069) Journal

            Wow, that's absolutely terrible, and makes me glad I didn't go with Gigabyte. I saw that their Linux support had been pretty bad for the previous generation of boards, to the point that people couldn't even get basic things like USB working without lots of dumb workarounds, and there wasn't enough data at the time to show that they'd improved any for AM4, so I skipped them entirely. Went with MSI instead, because reports of their AM3 stuff seemed to indicate they weren't releasing broken garbage, plus I've had good luck with their hardware in past, so I figured it would be a pretty safe choice.

            So far I've been right, and the biggest problem I've had with MS specifically is that they're about a month later than the other board makers with bios updates...but I'd rather have a late bios update than a broken one, so as long as I don't start getting them late AND broken, I'm okay with it. :)

            I do need to go back and try testing voltages again, see if I can either get the XMP profile's settings (the 1.2v) stable or get some extra mhz out of the chips. The last bios update MSI put out has a new opcache control option, which seems to act as a workaround for the whole micro-op issue that affects some early Ryzens (mine included). Using it seems to successfully stop the gcc segfaults, and maybe there's a chance some of my stability issues were related to it. Though I think most of my RAM trouble is because I bought when Ryzen was just released, so there wasn't really anything AM4-specific available for RAM at the time. Very little info, XMP profiles based on Intel chipsets, etc., so I've had to work around that.

            No big deal, though; I knew there'd be some tweaking and trial-and-error when I chose early adoption, so it doesn't bother me, and the hardware's damn good.

  • (Score: 2) by gnuman on Sunday August 20 2017, @07:12PM

    by gnuman (5013) on Sunday August 20 2017, @07:12PM (#556757)

    maybe they needed to do this not to have their processors classified as munitions and banned from sale in China and elsewhere?

(1)