[coreboot] Locking coreboot against internal flashing
On Thu, Feb 14, 2019 at 12:21:36PM -0500, Matt B wrote: For Coreboot afaik the only two methods available are to flash with a programmer or to flash internally from linux with iomem=relaxed. On another mailing list, someone commented "I would never use Coreboot, because it would let malware flash your bios from within Linux." (paraphrased) I'm reasonably sure that this is not true and security-conscious users can disable internal flashing, but I haven't been able to find any mention of such a setting in the documentation. How can users disable internal flashing? ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] if your G505S does NOT have a discrete GPU (= LA-A092P board), please test this coreboot build
I almost completed refining the HJK's dGPU patches and discrete GPU is still working at my G505S after these changes, but before submitting the patches I would like to make sure that they are not breaking the things for G505S without a discrete GPU. So if you have some free time and ready to "unbrick" by the hardware flashing - although I hope the things would go well ! - please help me by testing this coreboot build at your G505S: https://github.com/informer2016/shared_devfiles/blob/master/coreboot.rom SHA256 sum of this image = ab173394ba3ed57a73d1455a02f7d903a5f5c55a0ab5ba43b4c445e4ad20 Download this image, run sha256sum ./Downloads/coreboot.rom , and if it is correct - please flash it by executing sudo ./flashrom -p internal:laptop=force_I_want_a_brick,amd_imc_force=yes -w ./coreboot.rom - according to http://dangerousprototypes.com/docs/Lenovo_G505S_hacking instructions - then shutdown and try turning it on. It could take up to minute for G505S to boot because of high debug level and USB debug enabled, so wait patiently. After it reaches the SeaBIOS screen, press ESC and choose your Linux USB or HDD to boot from - otherwise the first-in-the-list floppy OS (MichalOS, btw it has a cool PLAYER .APP -> Piano) will be booted by default. If it could boot to Linux, clone the coreboot repository (if you haven't already) and get the logs: cd ./coreboot/util/cbmem make sudo ./cbmem -c > ./console.log and also sudo dmesg > ./kernel.log Remove the private information from these logs (such as your MAC addresses from kernel.log or USB model from console.log) and share these logs with me - I would like to take a look to see that there aren't any new angry messages. Also try S3 suspend (aka "hibernation"), see if it could resume successfully to Linux and report the results. If it could not boot to Linux and you don't have a FT232H or another debug dongle to capture the logs by USB, just tell me it didn't work and unbrick by following the hardware flashing instructions. Then I'll try to add more precautions... ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: if your G505S does NOT have a discrete GPU (= LA-A092P board), please test this coreboot build
Hello, On Sat, Feb 16, 2019, 14:49 Mike Banon https://github.com/informer2016/shared_devfiles/blob/master/coreboot.rom How can one build a coreboot.rom like this one with the patches you mentioned? Best regards, Angel Pons ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: if your G505S does NOT have a discrete GPU (= LA-A092P board), please test this coreboot build
On Sat, Feb 16, 2019 at 3:49 PM Mike Banon wrote: > I almost completed refining the HJK's dGPU patches and discrete GPU is > still working at my G505S after these changes, but before submitting > the patches I would like to make sure that they are not breaking the > things for G505S without a discrete GPU. Just go ahead and submit your patches for gerrit review. You can set WIP flags or I can tag them with -2 until we feel happy about them getting merged. I won't be testing any random pre-built binary, need to build one myself. Kyösti ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Locking coreboot against internal flashing
To make a real write protection on your spi flash you may go two ways after setting region protection and configuration bits in your flash 1) Write a SMM handler, that will prevent software to set high level on SPI #WP/WE pin (that can be done it it connected to chipset) absolute chipset-specific, also possibly this will be a mainboard specific task. Or 2) After flashing coreboot with setted up protection bits you can disconnect #WP/WE pin from mainboard and hardwire it to ground. Second way is a bit simple, but you may lost hibernation/S3 on amd and lost memory training data on intel FSP based boards. The final decision is yours. сб, 16 февр. 2019 г., 15:31 Frank Beuth secli...@boxdan.com: > On Thu, Feb 14, 2019 at 12:21:36PM -0500, Matt B wrote: > >For Coreboot afaik the only two methods available are to flash with a > >programmer or to flash internally from linux with iomem=relaxed. > > On another mailing list, someone commented "I would never use Coreboot, > because > it would let malware flash your bios from within Linux." (paraphrased) > > I'm reasonably sure that this is not true and security-conscious users can > disable internal flashing, but I haven't been able to find any mention of > such > a setting in the documentation. > > How can users disable internal flashing? > ___ > coreboot mailing list -- coreboot@coreboot.org > To unsubscribe send an email to coreboot-le...@coreboot.org > ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Locking coreboot against internal flashing
On Sat, Feb 16, 2019 at 05:23:40PM +0300, Sergej Ivanov wrote: To make a real write protection on your spi flash you may go two ways after setting region protection and configuration bits in your flash Where are the write protection bits for the flash set, in which menu / config file? That is my question. ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Locking coreboot against internal flashing
On 16.02.19 16:08, Frank Beuth wrote: > On Sat, Feb 16, 2019 at 05:23:40PM +0300, Sergej Ivanov wrote: >> To make a real write protection on your spi flash you may go two ways >> after >> setting region protection and configuration bits in your flash > > Where are the write protection bits for the flash set, in which menu / > config file? That is my question. What Sergej suggested would have to be done out of band and not by coreboot. You can configure your flash chip to protect itself, which is unlike most firmware does it. Generally, what locking options you have depend much on your hardware. Hence, there is no generic solution in coreboot. Plus, coreboot is more a firmware framework than a firmware. It can only "boot" programs from flash and not your OS from disk. So you need a coreboot "payload" to do the latter and sometimes it's up to that payload to do such locking. So if somebody tells you that coreboot doesn't have an option to lock the flash chip, that might actually be true for their combination of coreboot + payload and hardware. The only option in coreboot itself that I know is the LOCK_SPI_FLASH_RO Kconfig. It should be available for all boards that use one of the fol- lowing Intel PCHs and a directly attached SPI flash: o Ibex Peak, o Cougar Point, o Panther Point, o Lynx Point, o Lynx Point-LP (integrated into a Haswell SoC). This can easily be extended to support any newer Intel chipset. Beside that, I know there are locking options in the FILO payload. And I suspect HEADS to do something about it, too. Google uses the block pro- tection of the flash chip on their ChromeBooks/Boxes. They have the WP pin controllable with a screw/switch/security chip. So if you got one of these, it would be wise to make use of that. Nico ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] VBIOS/VBT in Coreboot
In my Coreboot build I provide both VBIOS and VBT blobs via appropriate configuration items. The VBIOS blob contains expected signature at the top and VBT is valid as confirmed by running intelvbttool against it. The platform is slightly modified kblrvp (RVP3). During the build I can see cbfstool reporting that both blobs were placed in the image: To see the image's read-only sections as well, rerun with the -w option. CBFSPRINT coreboot.rom Name Offset Type Size Comp cbfs master header 0x0 cbfs header 32 none fallback/romstage 0x80 stage 41372 none cpu_microcode_blob.bin 0xa280 microcode 98304 none fallback/ramstage 0x22300 stage 90199 none config 0x383c0 raw 1302 none revision 0x38940 raw 612 none spd.bin 0x38c00 spd 2048 none --> vbt.bin 0x39440 raw 1168 LZMA (4608 decompressed) cmos_layout.bin 0x39940 cmos_layout 904 none (empty) 0x39d00 null 664 none fspm.bin 0x39fc0 fsp 401408 none (empty) 0x9c000 null 3992 none fsps.bin 0x9cfc0 fsp 188416 none --> pci8086,591e.rom 0xcb000 optionrom 65536 none fallback/postcar 0xdb080 stage 16512 none fallback/dsdt.aml 0xdf140 raw 19077 none fallback/payload 0xe3c40 simple elf 1166029 none (empty) 0x200780 null 997400 none bootblock 0x2f3fc0 bootblock 49152 none However, once the system boots, the VBIOS is not found at address 0xc and VBT cannot be located either. I need VBT to be accessible in order to specify the DP connector configuration for eDP. Suggestions are appreciated ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Locking coreboot against internal flashing
On Sat, Feb 16, 2019 at 4:31 AM Frank Beuth wrote: > On another mailing list, someone commented "I would never use Coreboot, > because > it would let malware flash your bios from within Linux." (paraphrased) well, send them here, and we can try to explain the world as it is. But this particular FUD has been bouncing around for 20 years so I don't hold much hope out for changing minds. ron ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: VBIOS/VBT in Coreboot
Hello Alex, On 16.02.19 18:39, Alex Feinman wrote: > In my Coreboot build I provide both VBIOS and VBT blobs via appropriate > configuration items. The VBIOS blob contains expected signature at the > top and VBT is valid as confirmed by running intelvbttool against it. > The platform is slightly modified kblrvp (RVP3). AIUI, you only need the VBT. If you are not going to run the VBIOS, you don't need that one. > > During the build I can see cbfstool reporting that both blobs were > placed in the image: To see the image's read-only sections as well, > rerun with the -w option. > > However, once the system boots, the VBIOS is not found at address > 0xc You'd have to tell coreboot or a payload to load the VBIOS. AFAIK, coreboot only does it when you also tell it to use it for gfx init (`VGA_ROM_RUN`). > and VBT cannot be located either. I need VBT to be accessible > in order to specify the DP connector configuration for eDP. Suggestions > are appreciated Maybe check the coreboot console for clues. For instance there should be a line "ACPI: * IGD OpRegion" telling us that an OpRegion is set up that points to the VBT. If that doesn't happen, one possible cause is that your processors SKU isn't listed here: `src/soc/intel/common/block/graphics/graphics.c:108`. There is no reliable public source for these IDs. So it's hard to tell if the list is comprehensive. In any case, please report back. If you can't find a solution, please point to the exact code you are using and attach your `.config` file. Nico ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: if your G505S does NOT have a discrete GPU (= LA-A092P board), please test this coreboot build
Out of curiosity, is there a config to disable the dGPU to save power if one is present? Thanks, -Matt On Sat, Feb 16, 2019 at 9:12 AM Kyösti Mälkki wrote: > > > On Sat, Feb 16, 2019 at 3:49 PM Mike Banon wrote: > >> I almost completed refining the HJK's dGPU patches and discrete GPU is >> still working at my G505S after these changes, but before submitting >> the patches I would like to make sure that they are not breaking the >> things for G505S without a discrete GPU. > > > Just go ahead and submit your patches for gerrit review. You can set WIP > flags or I can tag them with -2 until we feel happy about them getting > merged. > > I won't be testing any random pre-built binary, need to build one myself. > > Kyösti > > ___ > coreboot mailing list -- coreboot@coreboot.org > To unsubscribe send an email to coreboot-le...@coreboot.org > ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: AMDFlaws
This fairly interesting stuff. With the fairly wide range of attacks (arbitrary code execution and faking signatures for modules) maybe some sort of runtime "psp-cleaner" might be possible, but it would probably be a crushingly difficult undertaking. It's somewhat unclear form the slides, but it looks like these target the 17h (ryzen) psp. Do the same exploits also affect earlier versions? As for the patching, afaik AMD has released patches for all of these, but I haven't seen any patches for my 16h systems. Maybe if it's ryzen there has been more enthusiasm to provide patches? -Matt On Sat, Feb 9, 2019 at 4:53 PM Ivan Ivanov wrote: > Hi Shawn, thank you for the message! Luckily almost all the > coreboot-supported AMD boards don't contain the PSP inside their CPUs > - maybe because PSP got added to AMD much later than ME got added to > Intel. Only a few AMD boards, starting with "late 16h" architecture > (early 16h is fine) have the PSP inside. "With PSP + > coreboot-supported" : could remember only some of newer PC Engines > boards. Some examples: I have Lenovo G505S laptop - it has powerful > quadcore CPU and supports 16GB RAM, but it is AMD 15h architecture, so > no PSP there. ASUS KGPE-D16 powerful server with two AMD opterons (up > to 16 cores each) - also no PSP. So, as you see, this "PSP problem" is > not critical yet for AMD coreboot users. But of course it is important > and thank you for raising the awareness and sharing this interesting > presentation. Although maybe it'd have been better if such > presentations were released later by their authors, because now AMD > could patch these PSP flaws to make it stronger and harder to > jailbreak :P > > чт, 7 февр. 2019 г. в 09:13, Shawn : > > > > > https://storage.googleapis.com/wzukusers/user-28822230/documents/5c5b3fd28b669cTWPzwo/AMDFlaws%20Lecture%20Slides.pdf > > > > PSP is so powerful just like ME/SPS on Intel chipset. AMD user might > > need a similar tool like me_cleaner? psp_cleaner? > > > > -- > > GNU powered it... > > GPL protect it... > > God blessing it... > > > > regards > > Shawn > > ___ > > coreboot mailing list -- coreboot@coreboot.org > > To unsubscribe send an email to coreboot-le...@coreboot.org > ___ > coreboot mailing list -- coreboot@coreboot.org > To unsubscribe send an email to coreboot-le...@coreboot.org > ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: Locking coreboot against internal flashing
On Sat, Feb 16, 2019 at 06:00:26PM +0100, Nico Huber wrote: Generally, what locking options you have depend much on your hardware. Hence, there is no generic solution in coreboot. Plus, coreboot is more a firmware framework than a firmware. It can only "boot" programs from flash and not your OS from disk. So you need a coreboot "payload" to do the latter and sometimes it's up to that payload to do such locking. I see, so this question would be more properly directed at the SeaBIOS list? So if somebody tells you that coreboot doesn't have an option to lock the flash chip, that might actually be true for their combination of coreboot + payload and hardware. The only option in coreboot itself that I know is the LOCK_SPI_FLASH_RO Kconfig. It should be available for all boards that use one of the fol- lowing Intel PCHs and a directly attached SPI flash: o Ibex Peak, o Cougar Point, o Panther Point, o Lynx Point, o Lynx Point-LP (integrated into a Haswell SoC). This can easily be extended to support any newer Intel chipset. Beside that, I know there are locking options in the FILO payload. And I suspect HEADS to do something about it, too. Google uses the block pro- tection of the flash chip on their ChromeBooks/Boxes. They have the WP pin controllable with a screw/switch/security chip. So if you got one of these, it would be wise to make use of that. Nico ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: AMDFlaws
Hi, On Sun, Feb 17, 2019 at 12:18 AM Matt B wrote: > > It's somewhat unclear form the slides, but it looks like these target the 17h > (ryzen) psp. Do the same exploits also affect earlier versions? > I think these attacks are possible because of the general flaws at PSP architecture, so yes they should also affect e.g. the late 16h systems (Puma). Early 16h systems (Jaguar) are safe because they don't have a PSP, so my ASUS AM1I-A with Athlon 5370 is safe - although maybe not yet, because I'm too busy with G505S and still haven't flashed a coreboot there! Just collecting the dust at the moment... :P > On Sun, Feb 17, 2019 at 12:18 AM Matt B wrote: > > As for the patching, afaik AMD has released patches for all of these, but I > haven't seen any patches for my 16h systems. > Almost all the coreboot-supported AMD 16h boards are AMD _early_ 16h (so no PSP). Please tell what 16h systems do you have, maybe they don't have a PSP at all? Best regards, Mike Banon ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
[coreboot] Re: if your G505S does NOT have a discrete GPU (= LA-A092P board), please test this coreboot build
Hi friends, On Sat, Feb 16, 2019 at 11:56 PM Matt B wrote: > > Is there a config to disable the dGPU to save power if one is present? > I haven't checked if "disabled" (not initialized) dGPU consumes less power than "enabled" (initialized) but not used dGPU. But I think such a config is needed - also because if MULTIPLE_VGA_ADAPTERS is enabled I have to load a discrete GPU VBIOS to ACPI VFCT instead of integrated to make a dGPU working, because if I try to load them both it doesn't end well (discrete GPU not working and maybe the other problems). But if a person does not have a discrete GPU, his ACPI VFCT tables wouldn't be filled with anything at all, because I haven't figured out how to - if MULTIPLE_VGA_ADAPTERS is enabled for all the G505S (with/without dGPU) - how to check if one has a physical GPU attached to that "device pci 2.0" PCI bus. Maybe we should find a way to create a single ACPI VFCT table for two VBIOSes, however I don't know anything about it and everything seems to work without that, so guess it could wait. Meanwhile it works fine if I do VFCT only for discrete in case of "with-dGPU G505S". I hope to submit these modified HJK patches today after some final cuts. Luckily they are working without any SeaBIOS changes Best regards, Mike Banon ___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
