Le dim. 25 mars 2018 14:08, Taiidan@gmx.com Taiidan@gmx.com a écrit :
On 03/25/2018 11:12 AM, thierry.laurion@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@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot