Le jeudi 2 janvier 2020 00:10:09 UTC-5, Chris Laprise a écrit : > > On 1/1/20 8:28 PM, Thierry Laurion wrote: > > > > > > On Wed, Jan 1, 2020 at 4:12 PM Chris Laprise <[email protected] > <javascript:> > > <mailto:[email protected] <javascript:>>> wrote: > > > > On 1/1/20 1:36 PM, Thierry Laurion wrote: > > > > > > > > > Le mercredi 1 janvier 2020 13:32:00 UTC-5, Chris Laprise a > écrit : > > > > > > On 1/1/20 5:43 AM, Lorenzo Lamas wrote: > > > > Hello Thierry, > > > > > > > > Thanks for all that you are doing for the community. Do > > you see a > > > > possibility of a Qubes Certified Laptop with an AMD CPU? > > > > Intel is affected a lot more than AMD by the sidechannel > > > vulnerabilities > > > > in the last years. The Privacy Beast has a 3rd gen Intel > > CPU, Intel > > > > stopped providing uCode updates for 1st gen in 2019, so > > this year is > > > > probably the last year they will support 3rd gen. More CPU > > > > vulnerabilities will most certainly be discovered in the > > coming > > > years, > > > > so there is a need for an AMD based certified laptop, or > > at least a > > > > newer generation Intel based laptop, even though that may > > mean we're > > > > stuck with PSP or ME. > > > > > > As much as I like the Insurgo/Purism/System76 offerings, this > > issue has > > > weighed on me to reconsider. > > > > > > The massive amount of side-channel vulnerabilities have shown > > Intel's > > > engineering is reckless, and it gets worse. They're still > pushing > > > fraudulent compiler code – detecting and de-optimizing AMD – > > almost a > > > decade after it was reported in the press. And they outright > > refuse to > > > pay government fines relating to their misconduct – which > > also included > > > threatening PC vendors with retaliation if they sell "too > > many" AMD > > > units. > > > > > > Historically, when a behemoth like Intel goes renegade its > > because they > > > know their products are superior and the public will accept > the > > > situation as a trade-off. But the only thing that's > > "superior" about > > > Intel is their attitude and their ill-gotten revenue. > > > > > > The biggest problem I see is peoples' willingness to go along > > with what > > > is becoming a tradition of anti-competition. Whatever logical > > fallacies > > > are put forward to make it seem palatable with CPUs will also > > undermine > > > user motivations in other areas. > > > > > > Completely agreeing. This is why this > > > > > < > https://github.com/QubesOS/qubes-issues/issues/4318#issuecomment-549986749> > > > > > > needs collaboration to have real solutions in the future. > > > > The relative ease of using another x86 brand with better > implementation > > and ethics such as AMD makes it a clear choice in the meantime, > while > > the much more difficult and lengthy task of adopting open hardware > is > > pursued. > > > > People can wait 18-36 months for a Qubes port to POWER > architecture... > > That is 18-36 months of being subject to maximum side-channel (and > > probably other) risks and signalling a tacit acceptance of Intel's > > engineering. And at the end of that period, we still won't have > laptops. > > > > Only holding out for the perfect appears to be the enemy of good in > > this > > case; it is the wrong mindset for adding alternatives. Under these > > circumstances, there should be absolutely no hint that a robust x86 > > alternative is somehow passe... but that appears to be the message > > coming from vendors. > > > > I am not aware of any AMD model to recommend on my end which would have > > the good mix of QubesOS well supported components to fit requirements > > and warned compatibility issues. > > > > If you have such model in mind to recommend, be part of the solution and > > let us know. > > > > Meanwhile, models that fitted the bill for workstation/server got > > dropped by coreboot by lack of interest from the community (KGPE-D16 > > <https://github.com/osresearch/heads/issues/134#issuecomment-368922440>). > It > > might be brought back under grant work (TBD), but AFAIK, there is not > > such trust altogether from the community torward AMD, not really more > > trust torward their PSP (ME equivalent) and not so much known right now > > from attempts reversing <https://github.com/PSPReverse/PSPTool> it. > > Yes, this has as much to do with community attitudes as anything else. I > would still expect some vendor to be able to put 2+2 together and market > AMD-based systems based on their history and current strengths. > > If there is public mistrust bc of PSP, then there should be some > engagement from Coreboot and Libreboot to demonstrate that deactivation > is plausible.
The same point being made toward newer Intel ME is made torward PSP: It is now part of the main CPU bringup, making PSP not completely removable <https://doc.coreboot.org/soc/amd/family17h.html>. AGESA binary blobs are required for hardware initialization (coreboot shimboot), while the same situation applies to newer Intel hardware, requiring FSP (coreboot shimboot) <https://doc.coreboot.org/soc/intel/fsp/index.html> on newer hardware. From a firmware development perspective (hardware firmware developers, please jump in) this requires NDA to access documentation, which complicates the process and increase costs, limiting the actual firmware development to a limited, resourceful, number of organizations. This reduces community collaboration proportionally. As for Intel HAP bit that was discovered <https://github.com/corna/me_cleaner/wiki/HAP-AltMeDisable-bit>, as pointed out in this thread before, the binary blobs now required (not being trimmable) have increased since Sandy/Ivy bridge and now requires a signed kernel and syslibs block to be present <https://github.com/corna/me_cleaner/wiki/How-does-it-work>, while Intel ME is asked gently to be deactivated, which permits to vendors to claim that ME is Neutered+Deactivated, without end users to really understand the binary blobs differences and what is still there. The only point there that should make it obvious for everyone is that the FSF refuses to RYF certify neither newer AMD or Intel based platforms since the X200 for Intel, and the KGPE-D16 for AMD even though me_cleaner does its job, while Talos II obtained RYF certification <https://twitter.com/RaptorCompSys/status/1192579979613212673>in November 2019. OTOH, since Coreboot seems stuck in c.2012 with Intel Ivy > Bridge processors, that could make the issue moot bc AMD units requiring > no such deactivation (containing no PSP) are available that are also a > year newer. > > Regarding new hardware, which is important, I would rather take my > chances with AMD PSP firmware properly deactivating (when told to) than > with the equivalent Intel ME function. Agreed, but would need some interest, reversing, and porting to coreboot. This is not my field, unfortunately. coreboot people: HP ENVY 15z-j100? (but then Radeon graphics?) Yet again, PSP will NOT be completely deactivated, per design, as post GM-45 (x200, libreboot, RYFed) It would be interesting to > compare errata between the two brands on this point. > Absolutely! Who jumps in <https://freundschafter.com/cybersecurity-cpu-and-system-alternatives-without-intel-me-iamt-and-amd-psp-secure-technology/>? > > > > So what model would you suggest in the meantime for which firmware can > > be replaced by Open Source Firmware? > > Given that c.2012 machines are being discussed, I think its worth > mentioning the Lenovo G505s as a workable candidate. But I don't hang > out in Coreboot forums as much as I'd like, so I'd just assume ask you > the same question about what AMD models work? Is this something Insurgo > has looked into? > There are two AMD laptops models supported by coreboot as of now from what I gathered from yesterday homeworks: Lenovo G505s and the HP M6-1035DX. The G505S is, as said previously in this thread, not really interesting for firmware integrity attestation perspective (Heads), not having a TPM and not having enough SPI flash space to do anything trustworthy. <https://github.com/osresearch/heads/issues/453> So yeah, you can have a AMD corebooted system. But you can't verify that the rom you booted is the one you think it is, but if you externally backup it and compare it to its original image. > > Complicating the issue is that Coreboot's documentation is 100% geared > to developers; the only guidance for users are links to OEMs. However, > the MrChromebox site lists AMD Stoneyridge c.2017 as Coreboot supported, > which makes models like Lenovo 14E chromebook and HP 15-BW077AX > candidates for testing and porting. > All of which are based on UEFI <https://mrchromebox.tech/#bootmodes> and their binary blobs. Additionally "This UEFI firmware does have a few limitations however: among other things, it lacks the ability to boot in Legacy Mode (often referred to as UEFI-CSM; this will likely never be implemented). It currently does not support TPM management or UEFI Secure Boot. The UI is also not as polished as other UEFI implementations, but that's open source for you :)" Which is linuxboot <https://trmm.net/LinuxBoot_34c3> like, without coreboot native initialization, replacing PEI part of UEFI <https://en.wikipedia.org/wiki/LinuxBoot>. This tendency of accepting more blobs everywhere for better performance, let it be in ARM, AMD or Intel, doesn't fit any trustworthyness by openness and actually encourages the whole industry in going that way, not just Intel engineering like you pointed at. It's "Open Source" as long as the code relies on closed source APIs. I disagree with that direction, personally. > > TBH, I'm not exactly sure why, from a consumer standpoint, open firmware > must be a prerequisite when the hardware itself is closed. Because the firmware controls the hardware until open source hardware exists altogether. Back to Sandy bridge once again, there is no FSP. There is native initialization, even the SMM is deactivate as early as possible by coreboot. Measurements of modules is done from the romstage under Heads. That is the state for the X230 as of now with Heads <https://trmm.net/Heads_33c3>. Having a PEI replacement makes you trust UEFI a bit less, while relying on its initialization that was made prior of payload runtime. And that is exactly my point trying to gather interest, development and funds toward supporting real alternatives for the future, without accepting ME nor its alternatives. Without accepting FSP and its alternatives. Relying to the lowest to none closed source firmwares present in the hardware. As said previously in this thread, we had that with the KGPE-D16. And for the moment, support is dropped since most codepaths were incompatible with AGESA ones, and it drifted until support got dropped in last release <https://www.phoronix.com/forums/forum/hardware/motherboards-chipsets/1140203-coreboot-4-11-brings-many-intel-improvements-new-support-for-supermicro-lenovo-boards?p=1140576#post1140576> . Meanwhile, I encourage you to discuss QubesOS certification requirements <https://www.qubes-os.org/doc/certified-hardware/> with QubesOS peers: "Another important requirement is that Qubes-certified hardware should run only open-source boot firmware (aka “the BIOS”), such as coreboot. The only exception is the use of (properly authenticated) CPU-vendor-provided blobs for silicon and memory initialization (see Intel FSP) as well as other internal operations (see Intel ME). However, we specifically require all code used for and dealing with the System Management Mode (SMM) to be open-source. While we recognize the potential problems that proprietary CPU-vendor code can cause, we are also pragmatic enough to realize that we need to take smaller steps first, before we can implement even stronger countermeasures such as a stateless laptop. A switch to open source boot firmware is one such important step. To be compatible with Qubes OS, the BIOS must properly expose all the VT-x, VT-d, and SLAT functionality that the underlying hardware offers (and which we require). Among other things, this implies proper DMAR ACPI table construction." And the question that arises is: What is Open Source Firmware nowadays? And QubesOS being historically mainly if not exclusively supporting Intel hardware. Chicken and egg problem everywhere. Perhaps its > more important than correctly functioning CPU hardware, but perhaps not. > To clarify the situation, I would also invite you to look at the optimizations on which side channels attacks relies. Some of which only targeting more recent silicons. Some targeting all silicon manufacturers. This is not so clear cut as: AMD is better, maybe less targeted. I am not against AMD and would gladly join forces in supporting a model that fits the bill for privacy/confidentiality conscious people caring for their data at rest to be more secured while the transition is made. First by researchers, developers, integrators, offering alternatives to customers. As far as I see myself, I don't have the ressources to assemble a laptop as of now. The ones that have those resources to create new offers have to step up. The best would still be, IMOHO, to be able to have CPU microcode updates for the lifetime of a CPU, and that again, means a required shift of how things are done from the industry. Its not just choosing parts to assemble to build hardware, but having silicon creators deciding to go open and actually doing it. Not creating Open Source certification, or doing Reddit AMA then nothing, but keeping promises and actually contributing in the Open Source ecosystem, reducing blobs, not augmenting their numbers and closeness. I think the perceived need that many have for it is rooted in reports > that some Intel ME versions don't deactivate properly, as deactivating > ME gained the Coreboot project a great deal of visibility. > Agreed. Which is why oreboot is alive and refuses to play with x86, altogether. > -- > > Chris Laprise, [email protected] <javascript:> > https://github.com/tasket > https://twitter.com/ttaskett > PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886 > -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/ff71cf1f-551a-4a08-a5f5-363e98a5a188%40googlegroups.com.
