coreboot November 2016

coreboot@coreboot.org

66 participants
187 discussions

More experiments with disabling the ME
by Nicola Corna 21 Nov '16

21 Nov '16

Hi everybody, Me and Federico Amedeo Izzo (federico.izzo42(a)gmail.com) started looking into our Intel ME firmwares after reading the thread "Experiments with disabling the ME on Sandy Bridge x230" started by Trammell Hudson. We have two Thinkpad X220 (Sandy Bridge) and a X201 (Nehalem), and we obtained the following results: * Sandy Bridge accepts an Intel ME firmware with just the FTPR partition, both with and without a valid FPT (the partition table of the Intel ME image). The system doesn't power off after 30 minutes, and the ME reports a successful initialization (see attached cbmem). To be extra safe we wrote a small Python script that removes all the non-fundamental partitions and creates a new FPT with a single partition entry (following the structure in [1] and some hints from Igor Skochinsky). * Sandy Bridge boots successfully without a good FPT (but with a valid FTPR), so it probably has a "backup" on-chip FPT. The system boots fine and doesn't power itself off after 30 minutes, even if the cbmem entry "ME: FW Partition Table" has the value "BAD" (that, we suppose, means: "I found a broken partition table, I'm using the fallback one"). * According to Trammell Hudson's tests, this behaviour is the same in Ivy Bridge (the thread's subject says "Sandy Bridge" but his cbmem confirms that his device is actually an Ivy Bridge) * Nehalem (on our X201) seems to lack a "backup" on-chip FPT, as removing the FPT partition bricks the device. Moreover using an ME image with just FPT and FTPR results in a brick, Nehalem probably needs more parts of the blob than just FPT and FTPR. Unfortunately our X201 is in a bad state and its flash is about to die, so we can't test further on Nehalem. * We couldn't remove in any way the FTPR partition on Sandy Bridge: setting the entries number to 0, the UMA size to 0 MB, creating an invalid FPT with a bad checksum or creating a "fake" FTPR entry which points to an empty region leads to a bricked device. Apparently, no matter which trick is used, if ME can't find the FTPR partition it refuses to boot. We didn't try with a 0-sized partition, but the result is probably the same. * Probably the UMA size can be reduced from the "stock" 16 MB or 32 MB to few MB, we'll investigate on this. * Shrinking the "reduced" ME partition in IFD to the minimum size allowed (FTPR offset + FTPR size + 4 kB alignment) bricks the device too (but we're not sure about this, maybe we made a mistake during the image creation). * Relocating the FTPR image doesn't work, even if the FPT entry points to the new location. * We haven't understood yet how to remove the unneeded modules from the FTPR partition, any help is appreciated. * The cbmem's ME entries * ME: Current Working State : Normal / Recovery * ME: Bringup Loader Failure : YES / NO * ME: Progress Phase : ROM Phase / BUP Phase seem to be interesting, and should be studied further. Attached you can find the script we used to "clean" the ME images, the cbmem log of an untouched ME image (the 2.1 MB firmware extracted from a Acer Chromebook C710) and the cbmem log of the same image after executing the script on it (therefore with just the FPT with a single entry and the FTPR). Some help testing the further options would be nice, in particular on the Nehalem architecture. Be careful: messing with ME may cause a hard brick, without the 30 minutes window, requiring an external programmer to unbrick your PC. Nicola Corna Federico Amedeo Izzo [1] http://me.bios.io/ME_blob_format

8 12

Re: [coreboot] native video init question
by Peter Stuge 21 Nov '16

21 Nov '16

Excellent advice from Ron. ron minnich wrote: > The timing is extremely tricky sometimes. Just to clarify - I think Ron also refers to the timing for software (coreboot) interacting with hardware (GPU registers) above, and not so much to timing for how GPU hardware interacts with the panel. The latter must obviously be correct. The point is that the former must *also* be correct, and that it is not at all obvious when such requirements exist, nor are they very well documented. //Peter

1 0

Re: [coreboot] DMA protection? [AMD-Vi]
by ron minnich 21 Nov '16

21 Nov '16

man. Most of these BME things revolve around intel. Not surprising, but not good. Does anyone care about the realtek 8168? And why on earth does it need BME? Can it just be initialized but not have DMA enabled? I wonder if we should scan for anything with BME set, at each stage transition, and print a warning for each one found? On Sun, Nov 20, 2016 at 3:52 PM ron minnich <rminnich(a)gmail.com> wrote: > On Sun, Nov 20, 2016 at 3:49 PM Kyösti Mälkki <kyosti.malkki(a)gmail.com> > wrote: > > On Mon, Nov 21, 2016 at 1:36 AM, ron minnich <rminnich(a)gmail.com> wrote: > > The way coreboot has always enforced DMA protections is to not set bus > master enabling on IO devices. I trust that particular setting a lot more > than I trust trying to configure an IOMMU, given that such configuration > seems to require trying to parse ACPI DMAR tables. If you will now tell me > that some bad IO device might ignore BME, then I would want to know how to > disable PCI bus mastering in the root complex, but certainly not via the > IOMMU. > > > And just grepping for PCI_COMMAND_MASTER would suggest such enforcing has > completely been forgotten for some years. Like for the UART of > intel/skylake in bootblock already. > > <https://www.coreboot.org/mailman/listinfo/coreboot> > > > > That needs to be fixed it would seem :-) > > ron >

1 0

Re: [coreboot] DMA protection? [AMD-Vi]
by ron minnich 21 Nov '16

21 Nov '16

On Sun, Nov 20, 2016 at 3:49 PM Kyösti Mälkki <kyosti.malkki(a)gmail.com> wrote: > On Mon, Nov 21, 2016 at 1:36 AM, ron minnich <rminnich(a)gmail.com> wrote: > > The way coreboot has always enforced DMA protections is to not set bus > master enabling on IO devices. I trust that particular setting a lot more > than I trust trying to configure an IOMMU, given that such configuration > seems to require trying to parse ACPI DMAR tables. If you will now tell me > that some bad IO device might ignore BME, then I would want to know how to > disable PCI bus mastering in the root complex, but certainly not via the > IOMMU. > > > And just grepping for PCI_COMMAND_MASTER would suggest such enforcing has > completely been forgotten for some years. Like for the UART of > intel/skylake in bootblock already. > > <https://www.coreboot.org/mailman/listinfo/coreboot> > > That needs to be fixed it would seem :-) ron

1 0

Re: [coreboot] DMA protection? [AMD-Vi]
by Kyösti Mälkki 21 Nov '16

21 Nov '16

On Mon, Nov 21, 2016 at 1:36 AM, ron minnich <rminnich(a)gmail.com> wrote: > The way coreboot has always enforced DMA protections is to not set bus > master enabling on IO devices. I trust that particular setting a lot more > than I trust trying to configure an IOMMU, given that such configuration > seems to require trying to parse ACPI DMAR tables. If you will now tell me > that some bad IO device might ignore BME, then I would want to know how to > disable PCI bus mastering in the root complex, but certainly not via the > IOMMU. > > And just grepping for PCI_COMMAND_MASTER would suggest such enforcing has completely been forgotten for some years. Like for the UART of intel/skylake in bootblock already. Kyösti > coreboot has always attempted to do absolutely minimal platform > configuration, just enough so a payload can run. This includes enabling as > little of the hardware as possible, including IO devices. Every time you > add in new capabilities such as IOMMU you take the risk of getting it wrong > and making the system less secure. > > Off the type of my head, messing about with the IOMMU in coreboot seems a > very bad idea. > > -- > coreboot mailing list: coreboot(a)coreboot.org > https://www.coreboot.org/mailman/listinfo/coreboot >

1 0

Re: [coreboot] using overlayfs to have several coreboot dev envs
by ron minnich 20 Nov '16

20 Nov '16

yes, in linuxbios v2 we actually had a way to specify the creation of fallback and normal and build the merged coreboot.rom with one make command. This kind of fell by the wayside as the fallback/normal approach was mainly used by linux networx and Los Alamos. Good suggestion! On Sun, Nov 20, 2016 at 1:43 PM Charlotte Plusplus < pluspluscharlotte(a)gmail.com> wrote: > If you refactor that code, could you make it easier to add the fallback? > One of the main reason I use overlayfs is to keep a separate fallback > > Overlayfs may remain a good option when working on separate source trees, > but when the differences are just in the .config. it would be nice to > specify the .config-fallback, the .config-normal, run make and get a > coreboot.rom without having to manually give the file that needs to be > updated. I wrote scripts to do just that. > > On Sun, Nov 20, 2016 at 4:36 PM, ron minnich <rminnich(a)gmail.com> wrote: > > > > On Sun, Nov 20, 2016 at 1:00 PM Matt DeVillier <matt.devillier(a)gmail.com> > wrote: > > On Sun, Nov 20, 2016 at 2:51 PM, ron minnich <rminnich(a)gmail.com> wrote: > > I had the same thought even while writing that note. So option 2 for the > config file is to create it at the top level: config.${MAINBOARD) or > somewhere else. Would that work? > > > using top level for config files would really clutter the root dir when > building for a large # of boards (I have ~25 I'm building for currently); > perhaps a 'configs' subdir would make sense? > > > > yes, and the configs would go well in a .gitignore ... > > -- > coreboot mailing list: coreboot(a)coreboot.org > https://www.coreboot.org/mailman/listinfo/coreboot > >

1 0

Re: [coreboot] using overlayfs to have several coreboot dev envs
by Charlotte Plusplus 20 Nov '16

20 Nov '16

If you refactor that code, could you make it easier to add the fallback? One of the main reason I use overlayfs is to keep a separate fallback Overlayfs may remain a good option when working on separate source trees, but when the differences are just in the .config. it would be nice to specify the .config-fallback, the .config-normal, run make and get a coreboot.rom without having to manually give the file that needs to be updated. I wrote scripts to do just that. On Sun, Nov 20, 2016 at 4:36 PM, ron minnich <rminnich(a)gmail.com> wrote: > > > On Sun, Nov 20, 2016 at 1:00 PM Matt DeVillier <matt.devillier(a)gmail.com> > wrote: > >> On Sun, Nov 20, 2016 at 2:51 PM, ron minnich <rminnich(a)gmail.com> wrote: >> >> I had the same thought even while writing that note. So option 2 for the >> config file is to create it at the top level: config.${MAINBOARD) or >> somewhere else. Would that work? >> >> >> using top level for config files would really clutter the root dir when >> building for a large # of boards (I have ~25 I'm building for currently); >> perhaps a 'configs' subdir would make sense? >> > > > yes, and the configs would go well in a .gitignore ... > > -- > coreboot mailing list: coreboot(a)coreboot.org > https://www.coreboot.org/mailman/listinfo/coreboot >

1 0

Re: [coreboot] using overlayfs to have several coreboot dev envs
by ron minnich 20 Nov '16

20 Nov '16

On Sun, Nov 20, 2016 at 1:00 PM Matt DeVillier <matt.devillier(a)gmail.com> wrote: > On Sun, Nov 20, 2016 at 2:51 PM, ron minnich <rminnich(a)gmail.com> wrote: > > I had the same thought even while writing that note. So option 2 for the > config file is to create it at the top level: config.${MAINBOARD) or > somewhere else. Would that work? > > > using top level for config files would really clutter the root dir when > building for a large # of boards (I have ~25 I'm building for currently); > perhaps a 'configs' subdir would make sense? > yes, and the configs would go well in a .gitignore ...

1 0

Re: [coreboot] using overlayfs to have several coreboot dev envs
by Matt DeVillier 20 Nov '16

20 Nov '16

On Sun, Nov 20, 2016 at 2:51 PM, ron minnich <rminnich(a)gmail.com> wrote: > I had the same thought even while writing that note. So option 2 for the >> config file is to create it at the top level: config.${MAINBOARD) or >> somewhere else. Would that work? > > using top level for config files would really clutter the root dir when building for a large # of boards (I have ~25 I'm building for currently); perhaps a 'configs' subdir would make sense?

1 0

Re: [coreboot] using overlayfs to have several coreboot dev envs
by Trammell Hudson 20 Nov '16

20 Nov '16

On Sun, Nov 20, 2016 at 08:20:51PM +0000, ron minnich wrote: > [...] > There's also no fundamental reason for using the name .config other than > tradition. We could, for example, create > build/vendor/mainboard/config and use that. One minor concern with that placement is that I enjoy the ability to nuke a partial or corrupted builds my doing 'rm -rf coreboot/x230', so having the config file stored in a generated directory would be problematic. However, it would be nice to remember the $(obj) and $(DOTCONFIG) variables when oldconfig is run in an external build. kbuild generates a Makefile in the external directory with its equivilant of those variables preset so that you can run 'make' in the output directory and have it do the right thing. -- Trammell

2 1

← Newer
1
...
5
6
7
8
9
10
11
...
19
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot November 2016