Who informed you of that? Because I doubt it, unless someone made a mistake or misunderstood the question. The ME is neutralized on the Librem 13 v1 hardware only, but the ME is not neutralized on the L13v2 or L15v3 and all online related pages do mention that it’s a work in progress for the newer iteration of the hardware.
Alright, thanks for that, I’ll give it a go and report back.
@kakaroto, Goran told me that around beginning of July, “Coreboot will be pre-loaded and ME will be neutralized.”
@mpc, I’m really sorry for misinformation. I didn’t realize at that time that ME is only neutralized on Librem 13 v1, I thought it was done on other models, too.
Just to clarify the clarification… are you referring to the 13v2 and 15v3 here or are you referring to later versions of the L13 and L15?
Referring to L13v2 and L15v3
Who informed you of that?
It’s right here on your site in the “About the Purism Librem” section. Note that it says:
Librem laptops feature customized components designed to increase security and freedom for end-users, including coreboot, a neutralized Intel Management Engine, an Intel CPU shipped unfused in “manufacturing mode” and without vPro, Intel AMT avoidance, and many other features that make this partnership possible on a technical level.
That says “laptops,” not “Librem 13 v1 laptops only.” I would recommend updating this information until this is in fact the case, because I can say personally that I also believed I was getting an Intel ME neutralized device.
@kakaroto I do, nevertheless, greatly appreciate your incredible work and do plan to run your version of the me_cleaner once I practice flashing on a few other more disposable devices first. While initially very frustrated over the communication inconsistencies on this issue, its great to see the progress being made.
As for VT-x and VT-d, I don’t know if they have anything to do with the ME, but coreboot itself does not enable or disable them, this allows the software application itself to do it. I was researching that a couple of days ago, and you could maybe just enable it yourself by using the ‘wrmsr’ command if whatever VM application you’re using doesn’t do it on its own
@kakaroto Some further research indicates enabling VT-x and VT-d are two very different things. One can use msr-tools to read and write the VT-x settings.
To read the settings:
Where a return of 5 indicated VT-x has been enabled. More here.
Modifying this setting manually is discouraged and is often done by software such as KVM or Xen. Qubes appears to successfully enable it.
VT-d is a different story. For VT-d to work, it seems the DMAR tables might need to be be passed by coreboot. Note that the motherboard itself must also support VT-d. Perhaps someone from Purism can verify if their motherboards support VT-d.
Reading though the below threads, it seems some chips require VT-d to be initialized. This may be the case with Skylake although I have not dug through the Skylake reference documentation to see if this is answered. Coreboot has added VT-d initialization on several chipsets such as Sandybridge, however Im not sure if this is being worked on for Skylake currently. From everything I’ve read, it seems that unlike VT-x, VT-d likely needs some help from coreboot to work. The first thread here seems the most relevant, although its easy to get confused when looking into this as it seems many tend to mix up what required for VT-x vs VT-d. What seems clear is that VT-x is often enabled via software, but VT-d requires a BIOS to VT-d related ACPI table to expose the VT-d capability of the platform
@d_auth: That article is from April, which was before we were done with the coreboot port and before we tackled the intel ME on the librem 13v2 or librem 15v3. You can’t blame an article that doesn’t mention the specific case of the librem 13 v2 when that laptop was not even being sold yet. You might as well point to an article fro 2015 and claiming that the version of PureOS that it says it ships with doesn’t match the version that was preinstalled on your system.
That’s unacceptable, there is no malice and the marketing has not been disingenuous, or fostered distrust, and saying that you have been “deceived” is rather strong language for what I might consider a misunderstanding or even a hurdle in the path towards that freedom. I also never said that “this is it”, I said it’s a “work in progress”, so asking everyone to be a little patient is a far cry from being disingenuous and deceitful.
Humm… that being said, it looks like you edited your message, cause I suddenly can’t find this text that I just quoted… instead, i’ll answer the updated text :
We update specific related pages like the coreboot page (in which you can see it clearly mentioned as a disclaimer), but we don’t retroactively update old blog posts/articles.
Once we realized it cause the Wifi issue, as far as I know, all the related pages were updated.
And FYI, I’ve spent a lot of time trying to get this working and I’m really happy I got the wifi fixed, but I still have a lot of work to do in order to fix the problem with the shutdown. It might require a massive reverse engineering of the BUP module and MFS partition before we can understand what happens.
@d_auth: Concerning VT-d, thanks for that info, i’ll look at it on monday, I found the MSR stuff for VT-x but couldn’t find any information on VT-d. I was planning to test if enabling VT-x also enables VT-d (as in, they are linked together), but ran into some issues trying to test that. Either way, you seem to have answered the question and I’m sure the links you provided will be very helpful in figuring it out. Once I do, i’ll be happy to add support for it in coreboot for skylake.
@kakaroto I edited it because I realized that while I felt deceived, that does not equate to deliberate deception, only miscommunication/misunderstanding. I continue to be a vocal supporter of Purism and the work you are doing and thought twice about my statement as it counter-productive to the important work you are doing and its potential. Where the confusion lies here is where you state:
The ME is neutralized on the Librem 13 v1 hardware only
That to me reads that all Librem 15s do not have a neutralized ME. The person above stated they had a 15 and you responded saying only the 13v1 had it. So that suggests the 15 that was being sold in April of that post did not have it despite the post claiming so. Can you please clarify the Intel ME status of the 15v2?
@kakaroto My system for example states that VT-x is enabled but VT-d is disabled, with the result in Qubes that DMA remapping is disabled. I think the first question is whether or not Skylake require BIOS initialization of VT-d as some do and some dont. I’m afraid the lack of specific information on this issue suggests that this is all thoroughly explained in the NDA BIOS programming documents provided to hardware manufacturers. Leading from there, I would guess reverse-engineering an existing BIOS for the Skylake to determine the correct values to pass is might be needed. Hopefully thats not the case. Fortunately there seem to be several example implementations for other Intel chipsets in coreboot. I have a KVM based VM setup on a different laptop with VT-d functional, so I might just swap drives to see whether the VT-d support follows it or not. If it does, then clearly there is a software solution missing on my setup. If not, then its likely a difference with coreboot.
Ok, so passing intel_iommu=on via kernel parameters using my KVM system (Fedora 26) booted from the Librem I get
dmesg | grep -e IOMMU -e DMAR
[ 0.000000] DMAR: IOMMU enabled
Without it there is no entry in dmesg.
The same HD booted from my Dell Precision m4800 with VT-d turned on in the BIOS gives:
# dmesg | grep -e IOMMU -e DMAR
[ 0.000000] ACPI: DMAR 0x00000000C8FE6CD8 0000B8 (v01 INTEL HSW 00000001 INTL 00000001)
[ 0.000000] DMAR: IOMMU enabled
[ 0.025070] DMAR: Host address width 39
[ 0.025071] DMAR: DRHD base: 0x000000fed90000 flags: 0x0
[ 0.025077] DMAR: dmar0: reg_base_addr fed90000 ver 1:0 cap c0000020660462 ecap f0101a
[ 0.025078] DMAR: DRHD base: 0x000000fed91000 flags: 0x1
[ 0.025080] DMAR: dmar1: reg_base_addr fed91000 ver 1:0 cap d2008020660462 ecap f010da
[ 0.025081] DMAR: RMRR base: 0x000000c7f19000 end: 0x000000c7f27fff
[ 0.025082] DMAR: RMRR base: 0x000000cd000000 end: 0x000000cf1fffff
[ 0.025084] DMAR-IR: IOAPIC id 8 under DRHD base 0xfed91000 IOMMU 1
[ 0.025084] DMAR-IR: HPET id 0 under DRHD base 0xfed91000
[ 0.025085] DMAR-IR: Queued invalidation will be enabled to support x2apic and Intr-remapping.
[ 0.025341] DMAR-IR: Enabled IRQ remapping in x2apic mode
[ 0.825499] DMAR: No ATSR found
[ 0.826031] DMAR: dmar0: Using Queued invalidation
[ 0.826037] DMAR: dmar1: Using Queued invalidation
[ 0.826082] DMAR: Setting RMRR:
[ 0.826122] DMAR: Setting identity map for device 0000:00:02.0 [0xcd000000 - 0xcf1fffff]
[ 0.826350] DMAR: Setting identity map for device 0000:00:14.0 [0xc7f19000 - 0xc7f27fff]
[ 0.826395] DMAR: Setting identity map for device 0000:00:1a.0 [0xc7f19000 - 0xc7f27fff]
[ 0.826438] DMAR: Setting identity map for device 0000:00:1d.0 [0xc7f19000 - 0xc7f27fff]
[ 0.826460] DMAR: Prepare 0-16MiB unity mapping for LPC
[ 0.826492] DMAR: Setting identity map for device 0000:00:1f.0 [0x0 - 0xffffff]
[ 0.826623] DMAR: Intel® Virtualization Technology for Directed I/O
[ 2.641605] [drm] DMAR active, disabling use of stolen memory
So it seems that for VT-d, simply turning it on is not enough to enable the system to use its features. For VT-x features, so long as the motherboard, chip, and software support it (and its not explicitly disabled via BIOS, which coreboot does not do) VT-x works.
However, the latest coreboot release changelog lists some additional updates for Skylake ACPI, so there it may be that someone is already working on it, or at perhaps at least had a more actionable answer.
Yeah, I figured you edited because you realized your message was accusatory for no reason, and I appreciate it. No worries.
Humm… I sometimes forget about the Librem 15 v2 itself. You’re right, the previous iteration of the L15 was still being sold in April (although actually, there were no laptops being shipped at that time so it was neither L15 v2 nor v3) and that one hasn’t been ported to coreboot yet, and doesn’t have the ME neutralized yet either. And to be frank, even the L13 v1 machines don’t come with a neutralized ME, they were all shipped with AMI BIOS and ME, it’s just that the coreboot port for those machines is available and neutralization of the ME is available as well. That being said, while I haven’t tested this yet, I’m pretty sure that if you run me_cleaner on the Librem 15 v2 BIOS (even if it’s the AMI BIOS, and not coreboot), would effectively neutralize its ME without any issues.
So… basically, yes, both broadwell machines (L13 v1 and L15 v2) would have a neutralized ME if the user does it (we have a script to install coreboot and neutralize the ME for the L13 v1 available in the pureos repo), but no, it didn’t come with the machines when they shipped, and while we do have neutralized ME for the skylake machines too (L13 v2 and L15 v3), it had side effects, like I explained (internal wifi card is not recognized anymore OR auto-shutdown fails). Some have decided they prefer a neutralized ME (and use a USB wifi dongle) and asked about it I’ve sent them a script to do that. But obviously those “side effects” are not acceptable for shipping the ME neutralized in factory for everyone else.
I’ll read/answer the rest Monday, I don’t even know why I’m reading the forums (this counts as work) on a Saturday!
Tests today and yesterday gave me a working L13v2 with neutralized ME and with no side effects… I don’t know why but the poweroff issue only seems to happen on one of the prototype machines I have (Which is what I often use when messing with coreboot).
It seems that I might just have a working neutralized ME for the librems… more tests needed, but I’m hopeful
@d_auth: oh and yeah, thanks for the links, a lot of info there, and a lot of interesting stuff, it looks like it should be easy to add VT-d support in coreboot for skylake and I will take care of that (hopefully soon).
I wish I had the background to do it myself. Just curious, how does one learn BIOS/firmware programming I know there is a book on linux device driver programming from O’Reilly, but I imagine a good working knowledge (beyond basic college architecture courses) of computer architecture as well as solid Assembly,reverse engineering, and C programming is a minimum. BIOS programming guides seem to be pretty NDA and dont seem to make the rounds online. How’d you get into it? I’d love to pick it up as a hobby, but it seems rather intense.
@d_auth: I didn’t know anything about BIOS/firmware programming until I started on this in last December… I don’t know much yet either since I didn’t write coreboot, but I worked on the existing code in coreboot (which means, I understand small parts of it, whenever there is something that I need to understand in order to advance). I didn’t read a book to understand, I don’t have the patience to do that, I usually go with trial and error. You can follow the entire progress/adventure by reading my detailed and regular blog posts here :
Look for ‘Youness’ to see my blog posts listed in the left hand side of that page, then click on them to read the blog posts.
@kakaroto : Any ability to give a timeframe estimate for me_cleaner on the 15v3?
@mpc: oh, didn’t realize I forgot to reply here once I finished my tests of the cleaned ME.
Yes, you can neutralize the ME now on 15v3. It’s part of my coreboot building script, so I suggest you use that. See this thread for more info :