[coreboot] Server systems shipped with coreboot

[Thierry Laurion]

Le dim. 25 mars 2018 14:08, Taiidan at gmx.com <Taiidan at gmx.com> a écrit :

> On 03/25/2018 11:12 AM, thierry.laurion at gmail.com wrote:
>
> > For the KGPE-D16, an integration effort was made in Heads to support
> > such board.
> >
> > https://github.com/osresearch/heads/issues/134
> >
> >   * OpenBMC support merged into coreboot so the server can boot
> >   * Flashrom support to flash OpenBMC directly from within Heads
> >   * Flashrom support to reflash Heads internally
> >   * Multiboot support, QubesOS support
> >
> > Thanks Timothy for all the great work that was accomplished on that
> > board in the past years.
> >
> >
> > TPM2 integration is still missing though. Don't hesitate to collaborate
> > onto  heads to integrate VBOOT changes. 16Mb of SPI flash is more then
> > enough to support it.
> >
> > Talos II cannot actually fulfill most of the threat models that the
> > KGPE-D16 can with Heads + QubesOS combined.
> The TALOS 2 has libre firmware, POWER-KVM, POWER-IOMMU and *it isn't a
> dead platform* - it is definitely worth a purchase.
> There isn't a POWER-qubes or a POWER-heads because no one has POWER
> computers and because there aren't those and "you can just get a *some
> x86 machine*" then not many will buy one and it will be the end of
> freedom computing...


> The facts are that x86_64 is a dead platform and there will never again
> be another owner controlled x86_64 device. - people need to understand
> that

True. Reluctance to change is another terrain reality though.

> and realize that things like qubes for POWER is a catch-22
> situation that will never be solved unless people have POWER machines
> and use them for their other virtualization needs until then.
>
That's a geeky path and unfortunately not accessible for a lot of use cases
and threat models. Even Qubes is still geeky for the masses. Getting easier
to use, true. But teaching to whom needs it the most is already a big
challenge in itself.

What I mean here is that cooperation should be the path taken. The
virtualization abstraction layer in Qubes is there, thanks to libvirt.
Helper scripts are missing though. If there is a response from early
programmers adopters out there, willing to contribute to Qubes (Timothy's
friends and partners?) that could really ease adoption. People want it.

 There is a need to have an alternative to x86, i think everyone
knowledgeable agrees to that. The thing is to easy that move. Xen won't do
thee move until pushed a little. KVM could be used for HVM in Qubes. I'm
pretty sure that if a couple of Talos II were borrowed to Qubes enhousiast
developers, the helper scripts would be written pretty quickly.

Meanwhile, I'll encourage willing customers who desires private cloud
solutions in their organization to buy Talos II. But it won't fulfill the
threat models of others until easier compartmentalization is available.

>
> Btw whats better about TPM2 vs TPM1? (Is there anything useful? AFAIK
> the only difference is the addition of more microsoft sponsored
> non-owner controlled features that could be potentially used for DRM)
>
Mostly true. But TPM2 comes now in all recent hardware for different
sockets and can be used for measured boot/trusted boot. Its support got
included in Grub and vboot. Linux kernel integrated a scheduler recently to
properly deal with concurrent requests.
Watch this talk.
https://fosdem.org/2018/schedule/event/tpm/

KGPE-D16 has a 19 pin header. I'm not aware of any TPMv1 that fits that
connector. Is there any? For measured boot and user ownability of hardware,
there is no specific need for TPMv2 but largest and stronger algorithms
including curves. Other then that, it was just pushed by DRM needs, I
believe.

I always thought a useful TPM feature to prevent it from being used for
> DRM is to have a fuse one can set to enable a "secure" mode otherwise
> one is able to freely read back anything on the chip.
>
Can be used two times. Once in the BIOS and then reused in the OS for other
means. No, the secrets kept in there are useful for a lot of uses from a
user perspective. You should watch the talk linked above.

>
> --
> coreboot mailing list: coreboot at coreboot.org
> https://mail.coreboot.org/mailman/listinfo/coreboot
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.coreboot.org/pipermail/coreboot/attachments/20180326/91486e92/attachment.html>