I would have preferred to keep this thread focused on the HCL and not get too derailed off-topic. I'll try to keep this brief and apologies to the moderators for continuing the off-topic thread. I'll give a reply and then leave it.
As someone who's working inside the org every day earnestly to try to improve everyone's security and freedom, I guess I don't get all the animosity, as I don't know of too many other organizations who are trying as we are to advance the cause of liberating these closed modules. I don't agree with the "all or nothing" approach some people are touting--having a motherboard without AMT at all, and with an ME that is reflashed to have most of its code removed is, to me, a much better situation than what you can get off the shelf. Is it 100% there? Of course not, but we are truly working to get it there. Other replies inline: On Sat, Nov 10, 2018 at 06:33:05PM +0000, 'casiu' via qubes-users wrote: > > "We have four ME modules remaining to liberate (and anyone with access to our > BIOS ROM or our BIOS build script > can confirm those claims)." > > Last time i checked Intel still did not hand you over their signing-keys ? > Im happy to change my mind, please educate me.:) Is the ME completely shut > off BEFORE the kernel boots up? > If not, im sure you know a few me modules more ore less is completely > irrelevant from a security point of view. > As part of reflashing the BIOS we reflash the ME so when the system boots it is running from the remaining four modules (kernel, supporting kernel libraries) in the ME that initialize the hardware. The high level info is here: https://puri.sm/learn/intel-me/ And the more detailed technical information is here: https://puri.sm/posts/deep-dive-into-intel-me-disablement/ > Also, i wasnt able to find a statement of Purism about the fact that, in the > beginning, they claimed the ME was "completely disabled and removed". I mean, > that was obviously not true right? I can only comment on the current state of things and what we have tried to be open about on our site. I don't recall them using words like "completely" but I also wasn't working there at the time. > > From what i see, despite Purism claims they will liberate it probably > sometime , purism-bios still only initializes proprietary blobs, which also > defeats the purpose. Im not one for great conspiracy theories, and also at > least for now willing to accept the term "opensource-hardware" for something > with one or two small irrelevant blobs because they cant be avoided, > but advertising hardware which runs almost entirely on closed source software > (certainly, all the important parts do), that just sound highly dishonest in > my ears. > We may have to agree to disagree here, as I wouldn't characterize loading an open source coreboot BIOS that includes Intel FSP binary blobs and the remaining few percent of the closed ME code that we haven't freed yet, and then boots into a completely free software OS as "almost entirely on closed source software." It sounds like you are assigning much more importance and weight into the FSP than I am when thinking about the whole system. > Last one: Would you honestly recommend people buying your products to > improve their security RIGHT NOW, not someday in the future when and if your > products will be completely open source. If so, wy? I would. For one, we are one of the few companies who are actively working to improve the current situation with respect to closed firmware and software on regular laptops. Not everyone has the ability to reflash firmware themselves to apply an open source BIOS and erase most of the ME and so we provide hardware that has that already applied. There are still binary blobs remaining but we are working to remove those as well. A lot of the arguments seem to center on some belief that we aren't genuine in our beliefs because we've set big goals, some of which are long term, and therefore haven't achieved all of those goals yet. For what it's worth, we have gone to the extra effort to codify our ethical stance into our corporate Social Purpose Corporation (SPC) charter and mean what we say. I personally am working to include Heads as a default tamper-detecting BIOS option for more security-minded people who order our hardware. Our hardware runs Qubes 4.0 out of the box and it is the primary OS on both my personal and work laptops (both Librems). We are actively working to integrate our Librem Key USB security token with Heads (my PR was just merged this past week) to provide a simple way to detect tampering in the BIOS and kernel/initrd/grub config. Is there still more work to do? Sure. But then I've always liked to be busy and hated being bored at work. Security is like golf. You try to get closer to the hole with every stroke. If you just try to get a hole in one every time you will lose. -Kyle > > If you could provide me an answer to those Questions, i would be very > grateful. I read this post twice , and i hope nobody finds it offensive in > any way, im actually trying to get a productive discussion here. > Please dont let this go emotional, rather provide people with actual, > verifiable TECHNICAL FACTS. > > Happy to learn something new, Casiu. > > > Sent with ProtonMail Secure Email. > > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ > On Saturday, November 10, 2018 5:24 PM, Kyle Rankin <[email protected]> > wrote: > > > It's a shame this thread got hijacked by people slandering the company. > > Could someone who is responsible for the HCL please update it with the data > > I've provided in this thread? This would update the HCL with a version of > > the Librem 13v2 that provides a TPM for people who are considering running > > Qubes 4.0 with AEM. > > > > -Kyle > > > > PS. For what it's worth we continue to work earnestly behind the scenes to > > liberate the remaining binary blobs (FSP and what remains of the ME after > > we disable and delete the majority of the modules) because we want to > > provide people with modern hardware that runs blob-free. For the ME, we > > have already documented what we have done to attempt to both disable (HAP) > > and neuter (zero out modules) the ME. We have four ME modules remaining to > > liberate (and anyone with access to our BIOS ROM or our BIOS build script > > can confirm those claims). Those of you who work in this space are aware of > > the challenges behind all of this and if anyone wants to help us in > > liberating the FSP and the remaining four ME modules that are present we > > would certainly welcome the help. > > > > On Fri, Sep 14, 2018 at 11:10:59AM -0700, Kyle Rankin wrote: > > > > > Install works out of the box with no warnings. I haven't run into any > > > issues with hardware compatibility--hardware in general works (video, > > > audio, all ports, Fn keys). Hardware Kill Switches work as expected within > > > Qubes. Suspend/resume works. > > > By default it works with the standard included coreboot BIOS but I've also > > > tested it with Heads using the TPM and that works as well. > > > -- > > > You received this message because you are subscribed to the Google Groups > > > "qubes-users" group. > > > To unsubscribe from this group and stop receiving emails from it, send an > > > email to [email protected]. > > > To post to this group, send email to [email protected]. > > > To view this discussion on the web visit > > > https://groups.google.com/d/msgid/qubes-users/20180914181059.fkt3blxd3heez54s%40work. > > > For more options, visit https://groups.google.com/d/optout. > > > > > layout: > > > 'hcl' > > > type: > > > 'laptop' > > > hvm: > > > 'yes' > > > iommu: > > > 'yes' > > > slat: > > > 'yes' > > > tpm: > > > '' > > > remap: > > > 'yes' > > > brand: | > > > Purism > > > model: | > > > Librem 13 v2 > > > bios: | > > > 4.7-Purism-4-heads > > > cpu: | > > > Intel(R) Core(TM) i7-6500U CPU @ 2.50GHz > > > cpu-short: | > > > FIXME > > > chipset: | > > > Intel Corporation Xeon E3-1200 v5/E3-1500 v5/6th Gen Core Processor Host > > > Bridge/DRAM Registers [8086:1904] (rev 08) > > > chipset-short: | > > > FIXME > > > gpu: | > > > Intel Corporation HD Graphics 520 [8086:1916] (rev 07) (prog-if 00 [VGA > > > controller]) > > > Intel Corporation Device [8086:9d24] (rev 21) > > > gpu-short: | > > > FIXME > > > network: | > > > Qualcomm Atheros AR9462 Wireless Network Adapter (rev 01) > > > memory: | > > > 16298 > > > scsi: | > > > Samsung SSD 850 Rev: 2B6Q > > > Samsung SSD 850 Rev: 1B6Q > > > usb: | > > > 1 > > > versions: > > > > > > - works: > > > 'FIXME:yes|no|partial' > > > qubes: | > > > R4.0 > > > xen: | > > > 4.8.4 > > > kernel: | > > > 4.14.57-2 > > > remark: | > > > FIXME > > > credit: | > > > FIXAUTHOR > > > link: | > > > FIXLINK > > > > > > > -- > > > > You received this message because you are subscribed to the Google Groups > > "qubes-users" group. > > To unsubscribe from this group and stop receiving emails from it, send an > > email to [email protected]. > > To post to this group, send email to [email protected]. > > To view this discussion on the web visit > > https://groups.google.com/d/msgid/qubes-users/20181110172439.GD29964%40greenfly.net. > > For more options, visit https://groups.google.com/d/optout. > > > -- > You received this message because you are subscribed to the Google Groups > "qubes-users" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > To view this discussion on the web visit > https://groups.google.com/d/msgid/qubes-users/a-3kTi0BmbRkYMaUfcC7C_cZKCwdoER0eNlTYNchZbzMtTdSPKtm7GR4ZtyomvAkErjJ-mdJ1d2wVv7vacMCescUzPcBRrNiGyWL20LDT44%3D%40protonmail.com. > For more options, visit https://groups.google.com/d/optout. > -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20181110193348.GE29964%40greenfly.net. For more options, visit https://groups.google.com/d/optout.
