On 1/2/20 2:51 PM, Thierry Laurion wrote:
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 <tas...@posteo.net
> <mailto:tas...@posteo.net>> 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
<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
<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
<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 PSPnot 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.
TheG505S 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
IMO, this is one of the logical fallacies that has reinforced Intel
dominance. In the case of side-channel attacks, most of them are
grounded in a basic theory of what could be exploited in poorly
engineered systems.. e.g. they are applicable across different
architectures with relatively little adjustment. What really underscores
this is that AMD x86 is the _same_ arch as Intel and researchers woke up
to the necessity to test both brands.
Also note that AMD has been forthcoming with information about
vulnerabilities while Intel has used tactics to prevent disclosure.
And look at the subsequent reactions from major integrators: Apple,
Google and Amazon. They all announced plans to get Intel-branded CPUs
out of their systems!
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 agree that's important, too. Open firmware is becoming more of a
long-term goal that we can acheive alongside open hardware. Clearly its
not working out too well with closed hardware, and the closed firmware
might as well be considered a part of the hardware, IMO.
But that doesn't mean stopgaps can't be applied to x86 processors to
assuage fears about ME/PSP's main issue: attack surface. I can imagine
that even Intel and AMD might accommodate a request to open source the
specific code that activates/deactivates management functions.
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, tas...@posteo.net
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 qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/qubes-users/e9743ada-46ae-791f-a87b-2f30858b4522%40posteo.net.
