Discussion on Purism

General Discussion
23

This is thread is a showcase of why a trusted level of 2 should be needed to participate in tangential discussions (though some might argue that this is directly relevant to Qubes). Relevant thread here.

Once a product/company had been badmouthed there’s a pattern of new accounts being made with the sole purpose of taking a side. Two brand new accounts are posting here, for example, and neither seem to have an interest in Qubes. What’s worse, they’re making lengthy posts that take considerable effort to get through. This is obviously leading to increased workloads for the mod(s) and clogging up the moderation queue.

As I’ve mentioned before, I’m not going to bother arguing with those in entrenched positions spouting long-winded sophistry, since I have better things to do with my time.

4 Likes
24

Sorry, but this was unreadable.

1 Like
25

never mind man just saying… don’t worry and don’t do anything “dark”/illegal

personally i’m satisfied with my purism hardware… hardware networking and alike aren’t really my things
so u know time saving and easy

safe not very expensive and…

26

hi folks, Michael here from the Qubes OS project.

I was part of the original effort of talking with Purism to get their laptop certified. Since everyone has had some distance now, it is maybe good time to clarify what should be already pretty clear (see unman’s posts above).

First, the Qubes OS project is happy to currently have two manufacturers with certification. Certification is a well-thought-out process with benefits to the manufacturer and to the free-and-open-source Qubes OS project.

The current process makes clear the conditions for certification, in particular that the manufacturer offer to customers the same configuration for at least a year. This point was made explicit out of the experience with Purism and the Librem 13, which went through a number of hardware changes as the company worked to stabilize its laptop offering while at the same time already selling it to end-users.

Maintaining a hardware certification while changing the hardware is not possible, and troubleshooting and re-certifying each new hardware iteration was seen as cost-prohibitive to the Purism team, so they dropped seeking certification for their laptop.

I think for both projects it was a learning experience, and we wish the best to the Purism team.

9 Likes
27

FYI I also posted this message on the Purism forum.

1 Like
28

Reply by Purism CSO there:

29

What happened previously with Purism?

30

I couldn’t agree more.

Personally, I think that Purism is the worst and dishonest “Privacy” BS marketing company ever.

Dasharo seems to be honest about what they can or can’t do, much more affordable, orders are actually delivered, and because of that they truly deserve to be supported by us and certified by Qubes Os.

2 Likes
31

Hi @fsflover
Sincerely enjoy reading your perspective. Agree with you far more than I
disagree (except perhaps with regard to purism).
Really appreciate your work in the forum too. Thank you!

Since you asked a direct question about purism’s “invented simple”
wording, I’ll risk veering off-topic to respond.

They invented simple words “disabled” and “neutralized” and stick to
them. What’s wrong with that? IMO it makes it easier for the public to
understand compared with “HAP bit”.

The main problem, as I see it, is oversimplification.

For instance in link we both referred to, the author states that “disabled” is “…the
ME is officially “disabled” and is known to be completely stopped and non-functional”.

Maybe you know more about the High Assurance Program (HAP), or have done
extensive testing, but the article’s claim that the “the ME is
officially “disabled” and is known to be completely stopped and non-
functional”, not only states that the HAP bit soft-disable strap method
is “official” (whatever that exactly means), but also states the HAP bit
method means the ME “is known to be completely stopped and
non-functional”. Perhaps it is, I don’t know.

To quote c0d3z3r0 in me_cleaner issue 340:
“Well, what you describe is actually the soft-disable strap. What I
described initially was actual cleaning/wiping of modules to prevent
their code to run, even if HAP would had a backdoor.”

Nephiel responded in the same issue
“Right, I only flipped the soft-disable bit, so the rest of the ME code
is still in there, and there is no guarantee it can’t be invoked some
other way.”

I repeat all of this not to spread FUD (fear, uncertainty, and doubt)
but to illustrate why I think purism’s “invented” terminology and
oversimplification could be misleading to someone truly concerned about
Intel’s ME. It seems strange to me that someone who does not trust
Intel’s Management Engine would trust Intel’s HAP soft-disable bit flip.

One last quote from Thierry (@Insurgo) from almost five years ago, may be worthy of inclusion:

“Neutralizing/Deactivating/Deleting/Freeing Intel ME is a word game
where a lot of ink spilled over the last years. I suggest you to read
this doc: How does it work? · corna/me_cleaner Wiki · GitHub
Basically, Intel ME version <11 can be deactivated, since no kernel
needs to be present in the firmware for validation prior to initialization,
resulting in the BUP module only being launched, permitting the machine
to boot, where version >11 requires the kernel and syslib modules to be
present and validated at initialization. So even if Intel ME is neutralized by
me_cleaner, the modules are still there in >11. Could they be executed?
That depends on your beliefs and threat modeling.”

Emphasis added.

Edited

Edit: 10-15-23 hopefully for better forum readability and clarity.

3 Likes
32

According to this interesting thread from 2021 on Purism forum, Librem 14 has an Version 12 ME. Not sure if that means you got yours before then?

33

@Insurgo corrected that quote in his next post:

" Sorry to have misadvertised Purism work. Didn’t went across that post: Neutralizing the Intel Management Engine on Librem Laptops – Purism

So it seems that Intel ME deactivation is on par with Ivy bridge, resulting in only the ROMP and BUP modules being required to initialize ME.

For firmware binary blob requirements, FSP is still required, see here: https://github.com/osresearch/heads/tree/master/blobs/librem_skl and here https://github.com/osresearch/heads/blob/master/config/coreboot-librem13v2.config"

Perhaps @Insurgo or someone else more knowledgable than me can clarify how that affect the question Could they be executed?

2 Likes
34

Appreciate you sharing your research. My understanding, admittedly limited and likely out of date was that the ME kernel and syslib modules (and probably more) are still present in the Comet Lake based Librem 14. Would love to learn that I’m wrong and the Comet Lake ME situation is, as you say, “on par with Ivy bridge”.

IMO that’s quite unfortunate but not surprising. Thanks again for sharing your research @ubersecure

+1
I also would be interested in reading and learning more about this.

35

Tried to have bing understand the differences prior of posting outcome below (still imperfect. Confusion still present but lowered)

Model Processor Generation Codename Example highest end CPUs ME Deactivation ME Neutering ME Removal Qubes Support
Librem 13 v1 5th Broadwell i7-5557U Yes Yes No Yes
Librem 13 v2 6th Skylake i7-6500U Yes No* No Yes
Librem 13 v3/v4 7th/8th Kaby Lake/Coffee Lake i7-8550U Yes** No* No Yes
Librem 14 v1 10th Comet Lake i7-10710U Yes** No* No Yes
Librem Mini v1/v2/v3 8th/10th/11th Coffee Lake/Tiger Lake-U i7-1165G7 Yes** No* No Yes
ThinkPad X200/T400 etc Centrino 2/Centrino vPro/Centrino vPro2/Centrino vPro3/Centrino vPro4/Centrino vPro5/Centrino vPro6/Centrino vPro7/Centrino vPro8/Centrino vPro9 (modded) Penryn/Cantiga/Montevina/Montevina Plus Core 2 Extreme QX9300/QX9400/QX9500/QX9600/QX9700/QX9800/QX9900 (modded) No***** No***** Yes****** No
ThinkPad X230/T430/W530 etc 3rd Ivy Bridge i7-3612QE (modded) Yes Yes*** No Yes
*Neutering is not possible for these chipsets because they require other modules then BUP/BUP+ROMP to be present and signed in the ME firmware. Those include kernel, Java runtime and policies to be in signed digest validated at ME platform initialization and cannot be removed.
**Deactivation is possible for these chipsets, but requires a newer version of me_cleaner or coreboot that supports the ME 12 firmware.
***Neutering is possible for these chipsets by removing all modules except BUP and ROMP.
*****Deactivation and neutering are not possible for these chiosets because they use an older version of ME (ME6 or lower) that does not support the HAP bit or me_cleaner.
******Removal is possible for these chipsets because they do not have the hardware checks and dependencies that require the ME firmware to be present and valid on the system. This can be done by using coreboot or libreboot as the firmware.

As you can see, the Librem models have ME deactivation and Qubes OS support, while the ThinkPad X230 models have ME deactivation and neutering, and also Qubes OS support. The ThinkPad X200 models can remove ME entirely, but they do not have ME deactivation, neutering or Qubes OS support.

Source: Conversation with Bing, 16/10/2023
(1) Lenovo ThinkPad X200 Review | Laptop Mag. Lenovo ThinkPad X200 Review | Laptop Mag.
(2) ThinkPad X series - Wikipedia. ThinkPad X series - Wikipedia.
(3) Lenovo ThinkPad X200 review: Lenovo ThinkPad X200 - CNET. Lenovo ThinkPad X200 review: Lenovo ThinkPad X200 - CNET.
(4) ThinkPad X230 Product Specifications Reference (PSREF). https://psref.lenovo.com/syspool/Sys/PDF/withdrawnbook/ThinkPad_X230.pdf.
(5) ThinkPad X230 Product Specifications Reference (PSREF). https://psref.lenovo.com/syspool/sys/pdf/withdrawnbook/thinkpad_x230_we.pdf.
(6) Lenovo ThinkPad X230 review: Lenovo ThinkPad X230 - CNET. Lenovo ThinkPad X230 review: Lenovo ThinkPad X230 - CNET.
(7) Purism– Librem 5. Purism– Librem 5.
(8) Purism– Products. Purism– Products.
(9) Librem 5 - Wikipedia. Librem 5 - Wikipedia.
(10) Librem - Wikipedia. Librem - Wikipedia.

After two hours or so clarifying and making certain Bing understands the whole confusion about terminology :

I’m sorry for the confusion. I have searched the web for more information about ME deactivation, neutering and removal, and I have revised my knowledge and answers accordingly. Here is what I have learned:

  • ME removal: This is a method that completely removes the ME firmware from the system, leaving no trace or functionality of it. This method would be ideal for users who want to have full control and transparency over their system, without any proprietary or potentially harmful firmware. However, this method is only possible for some older processors, such as Penryn and Yonah, that do not have the hardware checks and dependencies that require the ME firmware to be present and valid on the system. If the ME firmware is missing or corrupted, the system will either not boot at all or shut down after 30 minutes. This method can be done by using coreboot or libreboot as the firmware. This method was discovered by the libreboot project.
  • ME deactivation: This is a method that uses a special bit in the ME firmware called the HAP (High Assurance Platform) bit. This bit was originally intended for government use, to disable ME functionality for security reasons. By setting this bit to 1, the ME firmware will stop running after the hardware initialization phase, effectively deactivating most of its functions. However, this method does not remove or modify any code or data from the ME firmware, so it is possible that some residual functions may still be active or that the HAP bit may be reset by a malicious actor. This method is supported by some tools, such as me_cleaner and coreboot, and it works for most Intel processors from Sandy Bridge to Kaby Lake. This method was discovered by Positive Technologies, who found a way to use the HAP bit to disable ME without triggering any errors.
  • ME neutering: This is a method that goes beyond deactivation and tries to remove or modify as much code and data from the ME firmware as possible, without breaking the system. This method aims to reduce the attack surface and the potential harm of ME, by eliminating unnecessary modules and features. However, this method is not always possible or safe, as some parts of the ME firmware are essential for the system to boot and function properly. For example, some processors, such as Sandy Bridge and Ivy Bridge, require a module called BUP (Bring Up) to be present and signed in the ME firmware, otherwise the system will shut down after 30 minutes. This module can be kept in the ME firmware, while other modules can be removed or modified, resulting in neutering. This method is also supported by some tools, such as me_cleaner and coreboot, and it works for some Intel processors from Sandy Bridge to Broadwell. Neutering is when BUP and ROMP are required but kernel and other modules are signed and cannot be removed. This method was discovered by Trammell Hudson, who found a way to use an undocumented “AltMeDisable” bit to disable most of the ME functions after booting.

I think the confusion lies within revisions of same models. Librem existed across multiple chipset revisions. Their model labeling is in regard of screen size, not necessarily chipsets.

Bing answers correctly

You are right, the Librem models are labeled by screen size instead of chipset revision, which can cause some confusion. According to the coreboot firmware page², the Librem 13 v1 has a Broadwell processor, which supports ME neutering. The Librem 13 v2 has a Skylake processor, which does not support ME neutering. The Librem 13 v3 and v4 have Kaby Lake and Coffee Lake processors, respectively, which also do not support ME neutering. The Librem 14 v1 has a Comet Lake processor, which does not support ME neutering either. The Librem Mini v1, v2 and v3 have Coffee Lake and Tiger Lake-U processors, which do not support ME neutering as well. The only Librem model that supports ME neutering is the Librem 13 v1. All the other models can only deactivate ME using the HAP bit. I hope this clears up the confusion. :blush:

Source: Conversation with Bing, 16/10/2023
(1) Coreboot Firmware on Purism Librem Devices – Purism. Coreboot Firmware on Purism Librem Devices – Purism.
(2) Librem 5 Hardware - Phones (Librem 5) - Purism community. Librem 5 Hardware - Librem 5 - Purism community.
(3) Librem 5 Phone – Birch - Purism. Librem 5 Phone – Birch.
(4) undefined. Librem 5 Phone – Evergreen.

Here again, note that this applies to chipsets and not models.

My attempt to clarify this is still at the same place as always, referred multiple times at Platform blobs, collaborators/maintainers/testers for faster problems resolution · Issue #692 · linuxboot/heads · GitHub

Edit: multiple in link of core 2 duo, neutering/deactivation/removal of ME legend.

6 Likes
36

Thank you @Justin for your kind words.

I disagree that oversimplification is a problem. It would only be a problem if you had few possibilities to dig deeper, like with Apple, but in fact Purism usually provides all links and detailed technical explanations. (It’s like saying that new terms should never be invented to simplify speech, because they “can be misleading to someone truly concerned”.) I think that new terms make it easier to talk, if done well and transparently, which is the case here, see also below.

On the one hand, I agree with you here: “completely stopped” and “non-functional” are misleading. Since beginning of time, Purism oversold their work with too much hype. (So I’ve been always checking what they actually do, and I’ve been in general satisfied with less.) Of course, as far as I understand, disabling means you only “ask” Intel ME to switch off and must trust it to obey.
On the other hand, NSA and co. must have a method to close this backdoor for themselves, and indeed it was eventually discovered, without official disclosure. The latter makes it actually more trustable in my view, since Intel definitely doesn’t want you to tinker with Intel ME, but they likely had to provide a way to disable to “appropriate” users. So in the end, it’s quite likely (despite unverifiable) that Intel ME is actually deactivated, or disabled by it’s own will. This is exactly how I understand this:

I hope I clarified above that the “official”, from the point of view of the ME software itseld, way of disabling the code gives us a good reason to trust that it works, as long as Intel did not expect that users knew about this possibility. I could be mistaken, but I think it’s the case. If not, it could be a trap of course.

Concerning the new, useful definitions, consider this post by me_cleaner: They provide two different ways to fight with Intel ME but call them by the same name “Disable”. Later, with the new generation of Intel CPUs only one approach still works but the name stays the same, and people, like you or c0d3z3r0, start to ask reasonable questions like “how can this be true if it’s impossible?” Indeed we can’t do half of it now.

The other part, which is called “neutralize” by Purism, sounds very appropriate to me, too, since it very well reflects that this is action goes against the ME’s own plans, which is true.

To repeat, in my opinion, the real reason for the misunderstanding in your quotes/links comes from the misleading original me_cleaner’s definition, which doesn’t distinguish two very different cases.

It won’t be off-topic, if I move it to the appropriate place, which I just did.

Yes, I daily drive a Librem 15.

@ubersecure That update by @Insurgo was correct, but it was written before Librem 14 was released (in 2020). I think Purism say sufficiently clearly that ME in Librem 14 is “only” disabled but not neutralized. What is unclear with it?

4 Likes
37

Thank you @Insurgo for the nice table. However, I believe it’s not very accurate.

I am not sure that this is accurate, see this and this:

Also, there is no Librem 15 in the table.

I don’t think Librem 5 phone is relevant here.

3 Likes
38

The only truth is looking inside of the firmwares that are built and their blobs dependencies.

Sorry for references on librem5, and librem15 missing, but they also come in different chipsets depending on their revisions, but it doesn’t change the fact: they are post broadwell and therefore are in ME >= 11, which is not fully neuteurable. I wrote about this so many times in the past, I can’t believe there is still confusion about this but because terminology intricacies.

As described under Platform blobs, collaborators/maintainers/testers for faster problems resolution · Issue #692 · linuxboot/heads · GitHub there is no such thing as fully neutereable ME after =>11 and this documentation is the reference How does it work? · corna/me_cleaner Wiki · GitHub.

If we take for example what is built from Heads CircleCI.

user@heads-tests-deb12:~/heads$ ~/heads/blobs/xx30/me_cleaner.py heads-librem_15v3-v0.2.0-1809-gbd2a8eb.rom
Full image detected
Found FPT header at 0x1010
Found 2 partition(s)
Found FTPR header: FTPR partition spans from 0x1000 to 0xa8000
Found FTPR manifest at 0x1478
ME/TXE firmware version 11.0.18.1002 (generation 3)
Public key match: Intel ME, firmware versions 11.x.x.x
The HAP bit is SET
Reading partitions list...
 FTPR (0x00001000 - 0x0000a8000, 0x000a7000 total bytes): NOT removed
 MFS  (0x000a8000 - 0x00010c000, 0x00064000 total bytes): removed
Removing partition entries in FPT...
Removing EFFS presence flag...
Correcting checksum (0x01)...
Reading FTPR modules list...
 FTPR.man     (uncompressed, 0x001478 - 0x00207c): NOT removed, partition manif.
 rbe.met      (uncompressed, 0x00207c - 0x002112): NOT removed, module metadata
 kernel.met   (uncompressed, 0x002112 - 0x0021a0): NOT removed, module metadata
 syslib.met   (uncompressed, 0x0021a0 - 0x002204): NOT removed, module metadata
 bup.met      (uncompressed, 0x002204 - 0x0026a4): NOT removed, module metadata
 pm.met       (uncompressed, 0x0026a4 - 0x002752): NOT removed, module metadata
 syncman.met  (uncompressed, 0x002752 - 0x0027e8): NOT removed, module metadata
 vfs.met      (uncompressed, 0x0027e8 - 0x003148): NOT removed, module metadata
 evtdisp.met  (uncompressed, 0x003148 - 0x0032d6): NOT removed, module metadata
 loadmgr.met  (uncompressed, 0x0032d6 - 0x0033fe): NOT removed, module metadata
 busdrv.met   (uncompressed, 0x0033fe - 0x0037b0): NOT removed, module metadata
 gpio.met     (uncompressed, 0x0037b0 - 0x0038bc): NOT removed, module metadata
 prtc.met     (uncompressed, 0x0038bc - 0x003a6c): NOT removed, module metadata
 policy.met   (uncompressed, 0x003a6c - 0x003c36): NOT removed, module metadata
 crypto.met   (uncompressed, 0x003c36 - 0x003dc0): NOT removed, module metadata
 heci.met     (uncompressed, 0x003dc0 - 0x003f74): NOT removed, module metadata
 storage.met  (uncompressed, 0x003f74 - 0x004258): NOT removed, module metadata
 pmdrv.met    (uncompressed, 0x004258 - 0x00437c): NOT removed, module metadata
 maestro.met  (uncompressed, 0x00437c - 0x004466): NOT removed, module metadata
 fpf.met      (uncompressed, 0x004466 - 0x00455a): NOT removed, module metadata
 hci.met      (uncompressed, 0x00455a - 0x004704): NOT removed, module metadata
 fwupdate.met (uncompressed, 0x004704 - 0x00480c): NOT removed, module metadata
 ptt.met      (uncompressed, 0x00480c - 0x0048fe): NOT removed, module metadata
 touch_fw.met (uncompressed, 0x0048fe - 0x004a40): NOT removed, module metadata
 rbe          (Huffman     , 0x004a40 - 0x0070c0): NOT removed, essential
 kernel       (Huffman     , 0x0070c0 - 0x015dc0): NOT removed, essential
 syslib       (Huffman     , 0x015dc0 - 0x028a00): NOT removed, essential
 bup          (Huffman     , 0x028a00 - 0x051600): NOT removed, essential
 pm           (LZMA/uncomp., 0x051600 - 0x053f80): removed
 syncman      (LZMA/uncomp., 0x053f80 - 0x0544c0): removed
 vfs          (LZMA/uncomp., 0x0544c0 - 0x05c2c0): removed
 evtdisp      (LZMA/uncomp., 0x05c2c0 - 0x05dd40): removed
 loadmgr      (LZMA/uncomp., 0x05dd40 - 0x060b80): removed
 busdrv       (LZMA/uncomp., 0x060b80 - 0x063980): removed
 gpio         (LZMA/uncomp., 0x063980 - 0x064e00): removed
 prtc         (LZMA/uncomp., 0x064e00 - 0x065bc0): removed
 policy       (LZMA/uncomp., 0x065bc0 - 0x06c280): removed
 crypto       (LZMA/uncomp., 0x06c280 - 0x07be00): removed
 heci         (LZMA/uncomp., 0x07be00 - 0x07fec0): removed
 storage      (LZMA/uncomp., 0x07fec0 - 0x084640): removed
 pmdrv        (LZMA/uncomp., 0x084640 - 0x085e40): removed
 maestro      (LZMA/uncomp., 0x085e40 - 0x088d40): removed
 fpf          (LZMA/uncomp., 0x088d40 - 0x08a740): removed
 hci          (LZMA/uncomp., 0x08a740 - 0x08afc0): removed
 fwupdate     (LZMA/uncomp., 0x08afc0 - 0x08f840): removed
 ptt          (LZMA/uncomp., 0x08f840 - 0x0a3980): removed
 touch_fw     (LZMA/uncomp., 0x0a3980 - 0x0a8000): removed
The ME minimum size should be 352256 bytes (0x56000 bytes)
The ME region can be reduced up to:
 00001000:00056fff me
Checking the FTPR RSA signature... VALID
Done! Good luck!

As you can see, a lot of modules have been removed, but take note of the essential modules, which cannot be removed, just like referred documentation by me_cleaner.

So if we go back at statements: “kernel and rbe”, they are still there.

X230:

user@heads-tests-deb12:~/heads/blobs/xx30$ ./download_clean_me.sh 
Usage: ./download_clean_me.sh -m <me_cleaner>(optional)
### Creating temp dir
### Downloading https://download.lenovo.com/pccbbs/mobiles/g1rg24ww.exe...
--2023-10-16 18:03:33--  https://download.lenovo.com/pccbbs/mobiles/g1rg24ww.exe
Resolving download.lenovo.com (download.lenovo.com)... 23.195.77.12
Connecting to download.lenovo.com (download.lenovo.com)|23.195.77.12|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 4626016 (4.4M) [application/octet-stream]
Saving to: ‘g1rg24ww.exe’

g1rg24ww.exe                          100%[=======================================================================>]   4.41M  8.39MB/s    in 0.5s    

2023-10-16 18:03:34 (8.39 MB/s) - ‘g1rg24ww.exe’ saved [4626016/4626016]

### Verifying expected hash of g1rg24ww.exe
g1rg24ww.exe: OK
### Extracting g1rg24ww.exe...
Extracting "Intel Management Engine 8.1 Firmware for Windows 7/8/8.1" - setup data version 5.4.2
 - "app/FwDetect.exe"
 - "app/FwUpdate.exe"
 - "app/FWUpdLcl.exe"
 - "app/FWUpdLcl64.exe"
 - "app/Idrvdll.dll"
 - "app/ME8_5M_Production.bin"
 - "app/MEInfoWin.exe"
 - "app/MEUpdate.CMD"
 - "app/Pmxdll.dll"
 - "app/SLA_TOOLS.pdf"
Done.
### Verifying expected hash of app/ME8_5M_Production.bin
app/ME8_5M_Production.bin: OK
###Applying me_cleaner to neuter+deactivate+maximize reduction of ME on , outputting minimized ME under /home/user/heads/blobs/xx30/me.bin... 
ME/TXE image detected
Found FPT header at 0x10
Found 23 partition(s)
Found FTPR header: FTPR partition spans from 0x180000 to 0x24a000
ME/TXE firmware version 8.1.72.3002
Public key match: Intel ME, firmware versions 7.x.x.x, 8.x.x.x
Reading partitions list...
 ???? (0x000003c0 - 0x000000400, 0x00000040 total bytes): removed
 FOVD (0x00000400 - 0x000001000, 0x00000c00 total bytes): removed
 MDES (0x00001000 - 0x000002000, 0x00001000 total bytes): removed
 FCRS (0x00002000 - 0x000003000, 0x00001000 total bytes): removed
 EFFS (0x00003000 - 0x0000df000, 0x000dc000 total bytes): removed
 BIAL (NVRAM partition, no data, 0x0000add0 total bytes): nothing to remove
 BIEL (NVRAM partition, no data, 0x00003000 total bytes): nothing to remove
 BIIS (NVRAM partition, no data, 0x00036000 total bytes): nothing to remove
 NVCL (NVRAM partition, no data, 0x00010511 total bytes): nothing to remove
 NVCM (NVRAM partition, no data, 0x0000493f total bytes): nothing to remove
 NVCP (NVRAM partition, no data, 0x0000a553 total bytes): nothing to remove
 NVJC (NVRAM partition, no data, 0x00004000 total bytes): nothing to remove
 NVKR (NVRAM partition, no data, 0x0001257d total bytes): nothing to remove
 NVOS (NVRAM partition, no data, 0x00034af7 total bytes): nothing to remove
 NVSH (NVRAM partition, no data, 0x00007609 total bytes): nothing to remove
 NVTD (NVRAM partition, no data, 0x00001eac total bytes): nothing to remove
 PLDM (NVRAM partition, no data, 0x0000a000 total bytes): nothing to remove
 GLUT (0x000df000 - 0x0000e3000, 0x00004000 total bytes): removed
 LOCL (0x000e3000 - 0x0000e7000, 0x00004000 total bytes): removed
 WCOD (0x000e7000 - 0x000140000, 0x00059000 total bytes): removed
 MDMV (0x00140000 - 0x000180000, 0x00040000 total bytes): removed
 FTPR (0x00180000 - 0x00024a000, 0x000ca000 total bytes): NOT removed
 NFTP (0x0024a000 - 0x0004a4000, 0x0025a000 total bytes): removed
Removing partition entries in FPT...
Removing EFFS presence flag...
Correcting checksum (0xed)...
Reading FTPR modules list...
 UPDATE           (LZMA   , 0x1cc508 - 0x1cc6c6       ): removed
 ROMP             (Huffman, fragmented data, ~2 KiB   ): NOT removed, essential
 BUP              (Huffman, fragmented data, ~56 KiB  ): NOT removed, essential
 KERNEL           (Huffman, fragmented data, ~135 KiB ): removed
 POLICY           (Huffman, fragmented data, ~91 KiB  ): removed
 HOSTCOMM         (LZMA   , 0x1cc6c6 - 0x1d343f       ): removed
 RSA              (LZMA   , 0x1d343f - 0x1d872a       ): removed
 CLS              (LZMA   , 0x1d872a - 0x1ddec0       ): removed
 TDT              (LZMA   , 0x1ddec0 - 0x1e45be       ): removed
 FTCS             (Huffman, fragmented data, ~18 KiB  ): removed
 ClsPriv          (LZMA   , 0x1e45be - 0x1e499f       ): removed
 SESSMGR          (LZMA   , 0x1e499f - 0x1f32cb       ): removed
Relocating FTPR from 0x180000 - 0x24a000 to 0xd00 - 0xcad00...
 Adjusting FPT entry...
 Adjusting LUT start offset...
 Adjusting Huffman start offset...
 Adjusting chunks offsets...
 Moving data...
The ME minimum size should be 98304 bytes (0x18000 bytes)
Truncating file at 0x18000...
Checking the FTPR RSA signature... VALID
Done! Good luck!
### Verifying expected hash of me.bin
/home/user/heads/blobs/xx30/me.bin: OK
###Cleaning up...
/home/user/heads/blobs/xx30

X220:

user@heads-tests-deb12:~/heads/blobs/xx20$ ./download_parse_me.sh 
### Creating temp dir
### Downloading https://download.lenovo.com/ibmdl/pub/pc/pccbbs/mobiles/83rf46ww.exe...
--2023-10-16 18:02:42--  https://download.lenovo.com/ibmdl/pub/pc/pccbbs/mobiles/83rf46ww.exe
Resolving download.lenovo.com (download.lenovo.com)... 23.207.56.164
Connecting to download.lenovo.com (download.lenovo.com)|23.207.56.164|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 3661480 (3.5M) [application/octet-stream]
Saving to: ‘83rf46ww.exe’

83rf46ww.exe                          100%[=======================================================================>]   3.49M  6.39MB/s    in 0.5s    

2023-10-16 18:02:44 (6.39 MB/s) - ‘83rf46ww.exe’ saved [3661480/3661480]

### Verifying expected hash of 83rf46ww.exe
83rf46ww.exe: OK
### Extracting 83rf46ww.exe...
Extracting "Intel Management Engine 7.1 Firmware for Windows XP/Vista/7/8" - setup data version 5.4.2
 - "app/ME7_5M_UPD_Production.bin"
Done.
### Verifying expected hash of app/ME7_5M_UPD_Production.bin
app/ME7_5M_UPD_Production.bin: OK
###Generating neuter+deactivate+maximize reduction of ME on , outputting minimized ME under /home/user/heads/blobs/xx20/me.bin... 
Starting ME 7.x Update parser.
 UPDATE           (LZMA   , 0x044a5a - 0x044aec       ): removed
 BUP              (Huffman, fragmented data, ~48 KiB  ): NOT removed, essential
 KERNEL           (Huffman, fragmented data, ~122 KiB ): removed
 POLICY           (Huffman, fragmented data, ~86 KiB  ): removed
 HOSTCOMM         (LZMA   , 0x044aec - 0x04a082       ): removed
 RSA              (LZMA   , 0x04a082 - 0x04eb3f       ): removed
 CLS              (LZMA   , 0x04eb3f - 0x053551       ): removed
 TDT              (LZMA   , 0x053551 - 0x0596fc       ): removed
 FTCS             (Huffman, fragmented data, ~15 KiB  ): removed
Relocating  from 0x0 - 0x0 to 0x400 - 0x400...
 Adjusting FPT entry...
 Adjusting LUT start offset...
 Adjusting Huffman start offset...
 Adjusting chunks offsets...
 Moving data...
The ME minimum size should be 84992 bytes (0x14c00 bytes)
Truncating file at 0x14c00...
/home/user/heads/blobs/xx20/me.bin is VALID
### Verifying expected hash of me.bin
/home/user/heads/blobs/xx20/me.bin: OK
###Cleaning up...
/home/user/heads/blobs/xx20

It is true to say that neutering is applied, but corna doc is right after Skylake:

As you can see, things are a bit more complex but the overall concept is the same: one RSA signature over the hash chains of the modules. As before, the hashes are not checked all at once but only when needed, allowing us to remove some modules without problem. Unfortunately it seems that the hashes of the modules rbe, bup, kernel and syslib are checked together, increasing the number of the fundamental modules to four.

  • Sandy: BUP
  • Ivy: BUP+ROMP (neutered)
  • Skylake+: BUP+RBE+KERNEL+SYSLIB. (partly neutered)

More recent:

  • No neutering. Only HAP: Deactivated.

Note: This has nothing to do with Purism but chipset and ME versions coming with those. Purism does what can be done to neuter and their articles are pretty clear on what they do and can do with state of current research and the chipsets in use. So are the other vendors that care enough to disable ME. But newer platforms cannot use the term neutering anymore. It should be partly neutered only, where newer platforms simply can’t neuter anymore on ME>=12 where discussion are continuing here Add soft-disable support for Intel ME 12, 14, 15 and 16 by XutaxKamay · Pull Request #384 · corna/me_cleaner · GitHub

Edit: repointing to the discussion on ME differences 3rd gen vs 10th gen - Intel ME - #24 by Insurgo

4 Likes
39

ubersecure does this discussion clarify things?

I tremendously appreciate Thierry’s table in Discussion on Purism - #35 by Insurgo (though I regret that he had to make it). I understand it to say that the Comet Lake Librem 14 @ubersecure linked to (previously in another thread now, thx @fsflover ) could be ME Deactivated (or “disabled” to use purism terms) but not neutered or removed. If I’ve misunderstood, please!, anyone, correct me.

Is the Purism Librem 14 Comet Lake FSP also well understood and worthy of discussion?

I’m confused, but thankfully I doubt I’d ever seriously consider buying a Purism product.

I wish I had the time and motivation to write a response to this. unman’s comments above, basically sum up my opinion:

40

Yes, Purism did say that clearly but I was confused about things like ME version. @Insurgo 's posts have cleared all that up.

1 Like
41

I don’t know if this is on topic (@fsflover feel free to move this
wherever you want, buried in the Purism thread if you desire, but
preferably not “hidden” in All Around Qubes).

Personally I miss Taiidan’s perspective. He/she might have been
abrasive, like myself, but at least they tried to speak truth.

Almost five years ago on the qubes-users mailing list Taiidan wrote in
HCL - Purism Librem 13 v2

“People need to know the truth about what they would be purchasing, this
issue isn’t and never was the fact that you are selling non-free laptops -
it is that you are claiming they are somehow open source firwmare/libre/me
disabled when they are not and could never be.”

…

“The business model of somehow keeping up open source firmware releases
with new x86 hardware without any vendor cooperation is impossible- it
would take years and millions to reverse engineer FSP thus x86 will
never be free.”

…

"X230 can’t have ME disabled like T400 only nerfed the hw init “bup”
module still runs (although more than skylake stuff where the kernel
runs and then is politely asked to shut off)

My (Justin’s) Commentary:

The HAP bit flip is simply asking Intel to shut off the Management
Engine. If you don’t trust Intel ME, why would you think kindly asking
them to please stop running their propriety, barely documented (and
certainly unsecure) kernel makes any sense?

Reference: (sadly this is “Only visible to members of groups: moderators, off-topic-moderators, trust_level_2, trust_level_3, trust_level_4”)

Nevertheless to repeat myself because it’s only visible to members of groups: moderators, off-topic-moderators, trust_level_2, trust_level_3, trust_level_4:

“To paraphrase a wise (former?) qubes user, Your threat model is not
my threat model, but your threat model is OK.”

ME/PSP, FSP, EC, propriety blobs, etc etc likely undermine Qubes
fantastically secure software. Still software is unlikely to be able to
protect users from firmware, never mind hardware bugs and design flaws.

I believe @Sven 's work on Laptops/desktops that work well with Qubes OS
is extremely laudable and important work. I hope the qubes community
will continue to support this effort while still being honest about
hardware security issues

Just my two cents… Best regards.

P.S. Not everyone can afford hardware expenditures every couple years.
Security IMHO should not only be available to the rich!

1 Like
42

Yes, indeed.

But my motivation is to determine which system to buy, and I am still not clear on how important neutering is?

The threat model is “nsa + co” remotely compromising my privacy.

I guess no one knows for sure, but I am still trying to determine which option give the most hope.

1 Like