It Looks Like Raptor Is Gearing Up To Release A New Open-Source POWER System

[madscientist159]

Barring fragile UEFI implementations that need ME Cleaner to be run in a reduced mode, it does two things, neither of which I've seen an AMD equivalent for:

First, it sets the HAP (High Assurance Platform) flag which, if it doesn't actually do what it says (which is described elsewhere as disabling the ME), could potentially get Intel sued by an enterprise or government customer with very deep pockets.

Looking at related cases, this would not work. The ME uses mutable firmware, the HAP bit not working as intended would likely be classified a simple bug and and a firmware update issued with no real consequences to Intel. The one exception to this would be if Intel signed a contract that specified the behavior of the ME in HAP mode, then they might be in breach of contract. No one outside of Intel and its intended customer(s) for HAP would know the exact language, though, or even if such contracts exist in the first place, and certainly a random person using the HAP bit would not be able to bring a lawsuit and actually win since they modified the operation of the ME in unauthorized ways.

For what it's worth, this is one of the problems with mutable, vendor-controlled firmware in high security positions. The vendor has no real responsibility for damage caused by bugs in the firmware components, and is normally able to issue an update as the sole remedy (if the product is even still supported at the point of discovery, if not, there may be no responsibility for a remedy at all).

Second, it takes advantage of the following characteristics of the ME firmware's design to do what, as far as can be observed, hangs the ME after the bring-up completes:

1. Each firmware module is its own partition, they are signed but the partition table isn't, and the system doesn't check for their presence or integrity until the moment when it tries to load them.
2. The reset watchdog isn't enabled until after the BUP (bring-up) partition has done its job.
3. To ease the edit-compile-test cycle, BUP, POLICY (secondary initialization and helper APIs), KERNEL, the network stack, and various other modules are separate partitions.

The kernel is still running, though. Does anyone know for certain that there isn't a "HAP attention sequence" that wakes it back up? Fundamentally what you have is a dormant highly privileged CPU, waiting for a potential exploit to silently take control and resume operation.

The PSP would be pretty useless if its default mode of operation were to start in a "we'll get sued if this isn't actually 'disabled' and we get caught" mode and, likewise, it'd also be pretty useless if its default mode of operation were to bring up the board, then die for lack of a kernel before reaching the "enable watchdog" mark.

I still intend to grab a cheap, used, pre-PSP Opteron if I can find one with a suitably low TDP (I have no air-conditioning and want something that can be cooled quietly) but, beyond that, as much as I hate Intel's business practices (eg. welching on their deal with AMD in the 386/486 era, fighting the OLPC XO because it wasn't intel-based, etc.), ME Cleaner is a killer feature.

In the end if you feel better about using a "cleaned" Intel machine, that's your choice. Just don't be surprised if an exploit against the HAP-set ME is found in the future.

[madscientist159]

madscientist159
the oculink is really expensive for my use and budget, any other pcie to m.2 adaptor like this one will work too?
https://www.amazon.com/EZDIY-FAB-Exp...CI+Express+M.2

Any passive, single PCIe to M.2 NVMe adapter will work.

the firmware guide i think is ok for heavy tech people, i understood nothing, is it planned a newbie step by step guide or an easyer firmware update metod like a kind of script to launch on linux, or a file to download in an usb and use it inside a bios, something like x86 bios update i mean

Something like this is in the works. We're waiting for required upstream kernel changes to propagate to the distributions first.

could you share if the video output connector is vga or something else?

Not yet. October is when the full reveal happens.

about glamor is it possible to make in your wiki an how to guide to disable it? because as before i found nothing on web i can understand
or maybe just speak/work with xorg mantainers to disable it as default on power machines should be even better

It's not a POWER limitation, it's that Glamor should not be enabled on 2D-only graphics like the ASpeed devices. If we could get them to blacklist Glamor by default on the ASpeed devices, that would be great. For now, it's an Xorg.conf edit to set "AccelMethod" "none".

you told the sata do not need blob controller, is this a news from the upcoming prodouct? because i saw on talos 2 is needed to buy proprietary Microsemi PM8068 SAS controller

Correct. SATA != SAS.

[freespirit]

madscientist159
thank you for the reply, i'm really curious to see this product, i will buy it if the price will be more friendly than other product because seems what i was waiting for, and your answers helped me to understood if i can use it without too much problems for my needs

as debian user, i saw there is the ppc64le, but is not a livecd, are you in touch with debian developer or do you make a debian live cd by yourself? i think is important when the system have problems, live cd and other tools like clonezilla are a must have, is it planned to have them available for this platform?

how can i know when the firmware update tool will be available? i see this page https://www.raptorcs.com/content/base/software.html but is empty now, this tool and other usefull things, like livecd or some recovery tool like clonezilla, will be there when available? or where should i look?

as i understood from you and the amd engineer the microcode inside power is placed by IBM is closed source is it right? what do this microcode does?

[madscientist159]

madscientist159
thank you for the reply, i'm really curious to see this product, i will buy it if the price will be more friendly than other product because seems what i was waiting for, and your answers helped me to understood if i can use it without too much problems for my needs

as debian user, i saw there is the ppc64le, but is not a livecd, are you in touch with debian developer or do you make a debian live cd by yourself? i think is important when the system have problems, live cd and other tools like clonezilla are a must have, is it planned to have them available for this platform?

We actually have a working live CD internally. This has not been released yet because we are still working on integrating the Debian installer.

how can i know when the firmware update tool will be available? i see this page https://www.raptorcs.com/content/base/software.html but is empty now, this tool and other usefull things, like livecd or some recovery tool like clonezilla, will be there when available? or where should i look?

Most of the system software is actually accessible from the Wiki at https://wiki.raptorcs.com/wiki/Talos_II#See_also A category reserved for software will also be created at some point to make it easier to find.

as i understood from you and the amd engineer the microcode inside power is placed by IBM is closed source is it right? what do this microcode does?

The microcode isn't so much closed source (implying mutable, compileable code running on a CPU) as it is part of the closed HDL describing the functionality of the processor. HDL is the literal description of how the processor should behave at a hardware level. Essentially, the microcode is part of the CPU silicon design; unlike x86 where this is able to be updated and changed by specific third parties after manufacture (thus introducing legal, security, and ownership uncertainty), on both POWER and (most) ARM processors the microcode in question is a series of wires and transistors inside the processor itself. It is part of the fixed hardware comprising the CPU alongside the instruction decoder, ALU, and I/O blocks, unlike modern x86 designs.

[freespirit]

madscientist159
it look awesome, thanks for your work

i have a last question about ddr4
i saw your compatibility list, how can i know if i found a ddr4 ecc reg that is not on list if it works? shound't be a kind of standard? the incompatibility is about a model or a kind of specification? when looking for the memory what else should i looking for other than ddr4 ecc reg?

[madscientist159]

madscientist159
it look awesome, thanks for your work

i have a last question about ddr4
i saw your compatibility list, how can i know if i found a ddr4 ecc reg that is not on list if it works? shound't be a kind of standard? the incompatibility is about a model or a kind of specification? when looking for the memory what else should i looking for other than ddr4 ecc reg?

Most DDR4 ECC registered RAM will work fine. The HCL is just a list of known-working modules that have been tested by Raptor and/or the community. We do recommend that you stay away from early Hynix modules as they did not meet the full DDR4 standard, as well as LR-DIMM since firmware support is not yet available for LR-DIMM modules.

[freespirit]

madscientist159
watching the compatibility list, i saw also the soundcards section, i don't have special needs, but it pop me up a question i hope you can share, the product you will present in october, do have an integrated audio or do i need an external sound card?
thank you

[madscientist159]

madscientist159
watching the compatibility list, i saw also the soundcards section, i don't have special needs, but it pop me up a question i hope you can share, the product you will present in october, do have an integrated audio or do i need an external sound card?
thank you

I can't share anything more other than to note that integrated sound is available.

[ssokolow]

Looking at related cases, this would not work. The ME uses mutable firmware, the HAP bit not working as intended would likely be classified a simple bug and and a firmware update issued with no real consequences to Intel. The one exception to this would be if Intel signed a contract that specified the behavior of the ME in HAP mode, then they might be in breach of contract. No one outside of Intel and its intended customer(s) for HAP would know the exact language, though, or even if such contracts exist in the first place, and certainly a random person using the HAP bit would not be able to bring a lawsuit and actually win since they modified the operation of the ME in unauthorized ways.

For what it's worth, this is one of the problems with mutable, vendor-controlled firmware in high security positions. The vendor has no real responsibility for damage caused by bugs in the firmware components, and is normally able to issue an update as the sole remedy (if the product is even still supported at the point of discovery, if not, there may be no responsibility for a remedy at all).

Fair enough.

The kernel is still running, though. Does anyone know for certain that there isn't a "HAP attention sequence" that wakes it back up? Fundamentally what you have is a dormant highly privileged CPU, waiting for a potential exploit to silently take control and resume operation.

In the end if you feel better about using a "cleaned" Intel machine, that's your choice. Just don't be surprised if an exploit against the HAP-set ME is found in the future.

Citation, please? Everything I've read gave the impression that me_cleaner is applying a second mitigation, entirely separate from the HAP bit, which involves exploiting a convenience for the Intel developers to carve out bits the BUP firmware didn't expect to ever be missing and exploiting the fact that there's a window in which the ME can crash without the reset watchdog being enabled yet. (An impression reinforced by the kinds of error messages that UEFI tends to give if the "carve out bits of the firmware" mitigation is enabled without also enabling the "set HAP bit" mitigation.)

[madscientist159]

Citation, please? Everything I've read gave the impression that me_cleaner is applying a second mitigation, entirely separate from the HAP bit, which involves exploiting a convenience for the Intel developers to carve out bits the BUP firmware didn't expect to ever be missing and exploiting the fact that there's a window in which the ME can crash without the reset watchdog being enabled yet. (An impression reinforced by the kinds of error messages that UEFI tends to give if the "carve out bits of the firmware" mitigation is enabled without also enabling the "set HAP bit" mitigation.)

It gets tricky, partly because one is relying on undocumented behaviour from the ME components. Apparently different "flavors" of the ME react differently to the invalid inputs created by ME Cleaner, but I am not aware of any of them "crashing" the kernel -- only asking nicely for the ME to halt its userspace after bringup (note "asking nicely" versus "forcibly disabling" -- there is a large difference between those two in terms of assurance). There's also some attempt to remove components from the ME firmware image without really understanding what this does -- does the ME fall back to an internal ROM version of the missing data? Does it start listening for a network upload of the missing data?

http://blog.ptsecurity.com/2017/08/d...-intel-me.html has some additional information. I'd like to call out the following, since I think the information you have above may have been a misquote of this section:

We found that deleting partitions with the ME file system results in an error during reading of the cfg_rules file. This file contains a number of different system settings. Among them, as we believe, is the flag that we called "bup_not_temporary_disable". If this flag is not set, the entire subsystem is switched to TemporaryDisable mode, and since the flag is a global variable initialized by zero, the read error is regarded as a configuration requiring disconnection.

We also checked the firmware of server and mobile versions of ME (SPS 4.x and TXE 3.x). In the server version, this flag is always set to 1; in the mobile version, it is ignored. This means that this method will not work in server and mobile versions (Apollo Lake) of ME.

Personally, I don't like the sound of TemporaryDisable, it sounds, well, temporary. ;-) Also looks like this hack may only work on certain desktop variants (?). In any case, the ME hardware is still quite active, so for instance this malware injection vector https://www.theregister.co.uk/2018/0...tel_jtag_flaw/ would still work on your "cleaned" Intel box.