What's good about the AtomBIOS ROMs: you can use AtomDis tool ( [1] / [2] ) to get some idea - about what's inside them and what they're doing. Run "make" to compile it and then use a command like ./atomdis pci1002,990b.rom F > pci1002,990b.rom.dis . I'm sharing my disassemblies as .dis files at [3] repository and you're welcome to take a look at them.
Although I don't think they could do anything malicious, as an additional security measure you could consider the YABEL options explained at the end of this message. E.g. " [to prevent] the Option ROMs from doing dirty tricks with the CPU (such as installing SMM modules or hypervisors) " . Personally I have the following combination inside my .config shared at [4] , and haven't experienced any GPU problems from them. Maybe a slightly stricter set of these options would work perfectly as well, I haven't checked. PCI_OPTION_ROM_RUN_YABEL [=y] Secure mode YABEL_DIRECTHW [=y] Direct hardware access YABEL_PCI_ACCESS_OTHER_DEVICES [=y] Allow Option ROMs to access other devices YABEL_PCI_FAKE_WRITING_OTHER_DEVICES_CONFIG [=n] Fake success on writing other device's config space YABEL_VIRTMEM_LOCATION [=0x1000000] ( that was a default address, unchanged ) If you don't want to rely on someone else's AtomBIOS ROMs, you could extract them by yourself while a proprietary UEFI is still flashed. 1) to get the integrated GPU AtomBIOS ROM, can use the "Retrieval via Linux kernel" method: [5] 2) to get the discrete GPU AtomBIOS ROM, use (a bit time consuming!) instructions provided here: [6] Then you'll be able to compare them with what I have submitted. Extra check is always good, e.g. because Matt's self-extracted AtomBIOS ROM for iGPU turned out a bit different because of some minor hardware differences (perhaps a slightly different LCD panel) - read a discussion [7] . Soon I'm going to test his iGPU ROM version on my PC, as well as maybe he would test my ROM version at his, to make sure they are crosscompatible and that I don't have to provide the multiple iGPU ROM versions inside my [8] patch. [1] - https://cgit.freedesktop.org/~mhopf/AtomDis/ [2] - https://github.com/mikebdp2/AtomDis [3] - https://github.com/mikebdp2/atombioses [4] - https://review.coreboot.org/c/coreboot/+/32352 [5] - https://www.coreboot.org/VGA_support#Retrieval_via_Linux_kernel [6] - https://mail.coreboot.org/pipermail/coreboot/2017-July/084660.html [7] - https://mail.coreboot.org/hyperkitty/list/coreboot@coreboot.org/thread/LKB4VKBFQ26ACC6D2D5I6FAKJY3WNAJB/ [8] - https://review.coreboot.org/c/coreboot/+/31944 => YABEL configuration options: ( use / key at make menuconfig menu to find out their menu path ) CONFIG_PCI_OPTION_ROM_RUN_YABEL: If you select this option, the x86emu CPU emulator will be used to execute PCI Option ROMs. This option prevents Option ROMs from doing dirty tricks with the system (such as installing SMM modules or hypervisors), but it is also significantly slower than the native Option ROM initialization method. CONFIG_YABEL_PCI_ACCESS_OTHER_DEVICES: Per default, YABEL only allows Option ROMs to access the PCI device that they are associated with. However, this causes trouble for some onboard graphics chips whose Option ROM needs to reconfigure the north bridge. CONFIG_YABEL_PCI_FAKE_WRITING_OTHER_DEVICES_CONFIG: By default, YABEL aborts when the Option ROM tries to write to other devices' config spaces. With this option enabled, the write doesn't follow through, but the Option ROM is allowed to go on. This can create issues such as hanging Option ROMs (if it depends on that other register changing to the written value), so test for impact before using this option. CONFIG_YABEL_VIRTMEM_LOCATION: YABEL requires 1MB memory for its CPU emulation. This memory is normally located at 16MB. CONFIG_YABEL_DIRECTHW: YABEL consists of two parts: It uses x86emu for the CPU emulation and additionally provides a PC system emulation that filters bad device and memory access (such as PCI config space access to other devices than the initialized one). When choosing this option, x86emu will pass through all hardware accesses to memory and I/O devices to the underlying memory and I/O addresses. While this option prevents Option ROMs from doing dirty tricks with the CPU (such as installing SMM modules or hypervisors), they can still access all devices in the system. Enable this option for a good compromise between security and speed. Best regards, Mike Banon On Tue, May 21, 2019 at 10:31 PM Chris Laprise <tas...@posteo.net> wrote: > > On 5/20/19 12:02 PM, Mike Banon wrote: > > Huge Thanks to Martin Roth, finally we got a permission from AMD to > > merge the new microcode patches - and Martin has just merged them ! > > ;-) So the things became slightly easier and luckily now you could > > disregard some microcode-related parts of my last message. And we need > > to walk the same path for the AtomBIOS ROMs - should be successful > > there as well, although perhaps would take another year or so :P > > That is good news about the patches. However, it will require the > inclusion of AtomBIOS to be usable in most cases, including my own. > > Thanks for going over the patch+blob options. It does appear we are now > stuck on just the AtomBIOS verification, assuming the AMD microcode > patches make it into coreboot 4.10. Unfortunately, system firmware is > now being targeted via remote attacks and I'm not sure how many > different AMD APU systems I'd have to scan to be reasonably sure I don't > have an exploited copy. If I use a copy from gerrit or github, then I'm > relying strictly on https security; this is true whether or not hashes > are posted since they are not good assurance unless they are signed. > > If there is any appeal you can make to AMD about AtomBIOS, I think it > could be of great benefit for anyone looking to AMD and coreboot as more > secure alternatives (and not just for older CPUs). > > -- > > Chris Laprise, tas...@posteo.net > https://github.com/tasket > https://twitter.com/ttaskett > PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886 _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
