coreboot November 2016

coreboot@coreboot.org

66 participants
187 discussions

Searching for datasheets concerning AMD SB950 southbridge chipset
by Marty Plummer 22 Nov '16

22 Nov '16

Greetings, In response to a bit of utter stupidity with the vendor UEFI firmware on my motherboard I've decided to have a go at porting coreboot to it. I've already gathered datasheets for most components on my motherboard, but I have yet to locate the various datasheets and guides regarding the SB950 southbridge chipset from AMD. As such, I'd like to ask every subscriber on this mailing list if they have these datasheets and would be able to share with me. Thank you, Marty P.

6 5

Request on AGESA testing
by Kyösti Mälkki 22 Nov '16

22 Nov '16

Hello folks I am about to flip AGESA boards to have MMCONF_SUPPORT_DEFAULT=y. If you don't know what that means, just ignore it. Nevertheless, now would be a good time to do a fresh build of your board and have it recorded in our supported boards database. Also, I would be interested in runs with COLLECT_TIMESTAMPS=y and CONSOLE_SERIAL=n to see how/if my follow-up changes will affect the boottime performance. Thanks, Kyösti

1 0

Re: [coreboot] DMA protection? [AMD-Vi]
by Zoran Stojsavljevic 22 Nov '16

22 Nov '16

Interesting thread. I would like to thank you to all for very/extremely interesting read. And this thread forced me to start thinking/focusing about these problems you have outlined here. I have no idea how things are handled in Coreboot regarding VT-x and VT-d. I do know how these two HW extensions are handled in UEFI/legacy BIOS. You either enable/disable them, independently, or not. So, if you, for example, do not set VT-x, you are not able to bring any kind of HYP/VMMs, doing true MMU xlation. The same applies for VT-d. If not set, not able to do any IOMMU xlation. I tried to find in Coreboot 4.4 (from August 2016) both VT-x and VT-d settings, but was not able to find any switches in .config. My question here is: *how HW extensions for INTEL/AMD VT-x and VT-d are handled - enabled/disabled in Coreboot?* Let me now switch to another part of this thread, main part: BME (Bus Master Enable). This is a different topic, but related to VTs. I would agree with Ron (Minnic) on his comment that minimum of the HW should be configured in Coreboot, so my take on this is that BME should be NOT enabled anyhow, anywhere, and left to actual OS to do this. Since Coreboot is true Linux oriented, I would say that kernel should properly go over PCIe discovery algorithm/PCIe tree discovered and set properly bridges with BME (by configuring kernel .config). In this lieu, I would like to propose two addendums: one already proposed by several people (Ron): to have added BME algorithm to ram-stage of Coreboot, which will print warnings for any bridge which has BME bit set, and other one: to create critical Bugzilla against Linus's (Torvalds) crew ( kernel.org) to add proper handling of BMEs in kernel.org: https://bugzilla.kernel.org/ . About security aspects... It is to be taken into the account *AFTER* proposed changes (logical steps), since we divide and conquer, don't we? Thank you, Zoran On Mon, Nov 21, 2016 at 10:15 PM, ron minnich <rminnich(a)gmail.com> wrote: > > > On Mon, Nov 21, 2016 at 10:54 AM Rudolf Marek <r.marek(a)assembler.cz> > wrote: > >> >> >> BME is ignored by Intel integrated graphics - the DMA runs even if the >> BME is >> clear (this happens on core i7 chipsets for example) Thus thatswhy it >> needs RMRR >> IOMMU range for VGA... >> >> > > wow. It's amazing how many of the PCI violations I've dealt with over the > years have been for intel chips :-) > > -- > coreboot mailing list: coreboot(a)coreboot.org > https://www.coreboot.org/mailman/listinfo/coreboot >

1 0

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

21 Nov '16

Hi all, Let me jump in. From the OS point of view the BME should be set for: 1) PCI bridges 2) for PCI class of IOAPIC devices (otherwise OS will not get any interrupt!) This PCI IOAPIC is for example on more high-end Xeons 3) sometimes it needs to be set on internal chipset devices. I remember that if 440BX had clear special cycle cleared it would refuse to poweroff - hard to debug! I guess per chipset it must be checked if it works with BME off... 4) the rest of the devices should have BME off Side note: BME is ignored by Intel integrated graphics - the DMA runs even if the BME is clear (this happens on core i7 chipsets for example) Thus thatswhy it needs RMRR IOMMU range for VGA... Thanks Rudolf

2 1

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

21 Nov '16

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11/21/2016 11:26 AM, ron minnich wrote: > > > On Mon, Nov 21, 2016 at 9:21 AM Timothy Pearson > <tpearson(a)raptorengineering.com <mailto:tpearson@raptorengineering.com>> > wrote: > > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 11/21/2016 10:43 AM, ron minnich wrote: > > Talidan, just be aware, you can spend the money on enabling IOMMU in > > coreboot, but you should not just assumed that it gets upstreamed. > > That's why I was suggesting we discuss mitigating DMA attacks instead of > going after the IOMMU directly. > > > > Got it, thanks. So, in a more general case, what can we do to remediate > such attacks across all the systems we have? And, further, what PCI > support can we contemplate removing now that kernels are smarter, so as > to help ensure that we don't accidentally make such attacks possible in > the future? > > And, in the age of FSP blobs, what should we check to make sure FSP has > not accidentally enabled such attacks? The first thing I would suggest (per your initial idea) is modifying the PCI tree walking function in ramstage to read the bus mastering status of every device, then thrown an alert to the console for each device that has BM enabled. That will let us know just how extensive the problem is, and scary warnings might call greater attention to the problem. In general, if you have binary blobs in the system such as the FSP, all bets are off. Such platforms cannot be trusted in ways that extend far beyond a DMA attack -- the FSP could, for instance, work in tandem with an Intel network peripheral and no one would really know about it outside of Intel. - -- Timothy Pearson Raptor Engineering +1 (415) 727-8645 (direct line) +1 (512) 690-0200 (switchboard) https://www.raptorengineering.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJYMy/RAAoJEK+E3vEXDOFbc5oIAJdLhhyxus9UZK9315H+xohn 8r5yKcI6Wf0vxocbLdAIVrWoyGwQp8bTyLi6rsEecoPbeIUk1g69swq6feZwRqnA j1caI8r3P839A4QsFBWlBqzspR0+Xr7nTB4o4B/G+GlI4XAEzJ+Y7MPt5Ppks3+C TSd+n86sVMgQelvc41KzVRsANNzPjqIyUBoW2qs8n2if+1QKsSPmrtVqgdm9x7/N WyDbzBvwCnDzX5HTXb4bFtHrpkjhFDdSBHPNETpXbvM4NF7fg8SPNVcEkyWnFKph z9I0R0PVbyY4FSwvoGtFdVnlyAMOXHrmAeyyE9I4WebVd66hyDxqzT5f/ohWrGw= =3iBo -----END PGP SIGNATURE-----

1 0

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

21 Nov '16

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11/21/2016 10:43 AM, ron minnich wrote: > Talidan, just be aware, you can spend the money on enabling IOMMU in > coreboot, but you should not just assumed that it gets upstreamed. That's why I was suggesting we discuss mitigating DMA attacks instead of going after the IOMMU directly. We have the AMD platform documentation and should be able to properly configure the hardware to reject DMA attacks, even without the IOMMU active, unless AMD inserted a backdoor into the relevant hardware as they have been known to do. At least they have been kind enough to document said backdoors when they are present! - -- Timothy Pearson Raptor Engineering +1 (415) 727-8645 (direct line) +1 (512) 690-0200 (switchboard) https://www.raptorengineering.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJYMy0OAAoJEK+E3vEXDOFbbvEIAKDEtFhTpvrpZxZmtKh5Rczk 47CXy+rnhBaLQYNFPtqlWqPGgEfvSOZqoUInAuWacO+idJvoGO30qrRpPlssUfAw pT2NskcqKD8wMZoSrqdm/rwvG/x4ezJIylGAdhRNrcKNKXK9JkJ+Hx3Tp1VfALa6 gPLR99d9hGjEI9KOKSnyPY2KtjTUihEcCUb9St2eL+LUtjPif7pZwBsyOfkKWslv r6rsznl/ydGECa8U7fUhaCWfJhr99wKEXQb3kSlkKPOaV9nQ2KQFI/abgMIKrcvG aMN8duKTQyNmVM3/s3ctjzDZUZCnRPbRqDed2isaGamYsKUbSy2QcdAtR0bYoGY= =2WO8 -----END PGP SIGNATURE-----

2 1

Re: [coreboot] DMA protection? [AMD-Vi]
by Taiidan＠gmx.com 21 Nov '16

21 Nov '16

You the man! Very informative >:D Was the card malicious or just horribly programmed? How much $$$$ would it run for you fellas to make DMA protection happen? On 11/15/2016 04:58 PM, Timothy Pearson wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > On 11/15/2016 03:35 PM,Taiidan(a)gmx.com wrote: >> I have KGPE-d16 with IOMMU/AMD-VI and I was wondering if it would be >> possible to designate in coreboot certain devices pass-through only to >> stop them from communicating with the host? If I have to launch a rescue >> CD or what not then a rogue infected device could do a DMA attack correct? >> >> On linux does iommu only isolate from the host devices assigned to a >> guest? assigned to pcistub? or is there always some level of mediation? >> My system says "dom0 mode - relaxed" right below the AMDVI messages, >> what does it mean? >> >> Thanks for any replies! >> >> > Coreboot does not currently configure the IOMMU to reject unauthorized > access; it waits for Linux to start and configure the IOMMU. By > default, Linux configures the IOMMU (if present) to only accept access > to authorised areas of memory*, therefore once Linux starts exploiting > the system via PCI becomes very difficult. If you have passed any > options to Linux regarding the IOMMU (e.g. iommu=soft or iommu=pt), the > system may have lost this protection, so be careful! > > It might be an interesting experiment to configure the IOMMU from within > coreboot in order to close the small window where a malicious PCI device > could attack the host. This is something we'd be willing to consider > under contract if there's interest. > > I hope this helps! > > * Both Raptor and other KGPE-D16 users have seen this in action with > rogue cards -- in particular, one USB 3 card with firmware blobs > attempted to scan host memory. When a peripheral misbehaves in this > manner, you will see messages similar to: > > "AMD-Vi: Event logged [IO_PAGE_FAULT device=00.00.0 domain=0x0000 > address=0x0000000000000000 flags=0x0000]" > > Each one of those is a peripheral access to main memory that has been > blocked by the IOMMU. If you see a lot of these, especially if they > continue to be generated after bootup, you probably have a buggy or > malicious PCI device installed. > > - -- > Timothy Pearson > Raptor Engineering > +1 (415) 727-8645 (direct line) > +1 (512) 690-0200 (switchboard) > https://www.raptorengineering.com > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1 > Comment: Using GnuPG with Mozilla -http://enigmail.mozdev.org/ > > iQEcBAEBAgAGBQJYK4TyAAoJEK+E3vEXDOFbJ9sH/3SEQ1eXRmdu9OU9DunssFLU > tzipT9K5VzJPr4YJr3gAJ7U+hcofWveFRxeK7hdsLJCn4BamhCtCOXVOTR6oG9z7 > dEAHg15k4nF0uent+FXMYjUDjFrpPTV+oJlfuvzhqHPmTQEJ02XuVssoEp5KA06r > Q0+0ya1Ea1rzXobgF25LVy4jkEMTmynDKsxAyQxPsNzUWH9GRn90h7syP5c7CFKS > Y2aGEvgnDyuuvH2FYspOkPtZM6tmTtMcwBOfiSTid7YhDWL/G1mTkbvild6M70yv > MWcG41Pnd6a+JuAoqtRBmh0S9ej8ltZRqGYKQTL1O8ZMTZLak4v95PLS6x4jCH4= > =Eohg > -----END PGP SIGNATURE-----

3 3

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

21 Nov '16

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11/21/2016 10:16 AM, ron minnich wrote: > > > On Mon, Nov 21, 2016 at 7:53 AM Timothy Pearson > <tpearson(a)raptorengineering.com <mailto:tpearson@raptorengineering.com>> > wrote: > > > > A quick check through the source seems to indicate that the generic > pci_set_resource function will enable bus mastering on any PCI bridges. > From that point on, if I'm not mistaken, any malicious device that > exposed a bridge interface could enable mastering for any logical > devices behind the bridge and attack the host. Am I missing something? > > > probably not. Back in the early days this kind of thing was not an issue. I hear you on this. Now, with many peripherals running a complex on-card operating system and on-card bridges being the norm, this has become a significant security hole that we should work toward mitigating. > We've always had to adjust for limits in the kernels we support. We have > a PCI subsystem mainly because, in 2000, linux could not handle an > unconfigured PCI bus -- it interpreted a "0 bar" as meaning "device > disabled by BIOS" -- really! Not surprised by this. Unfortunately, from what we've seen, Linux hasn't gotten much better at configuring bridges. > I suspect the BME enable on bridges was done because Linux or other > guests didn't know how to configure bridges correctly. But Linux and > other kernels are a lot better now than they were; I wonder if we should > stop enabling BME on bridges. It's worth a try. I suspect Linux won't re-enable BM on bridges that were otherwise configured, but I haven't looked over that part of the code in a while either. > In any event, however, if we make this change it should be done in small > steps, and I think a good first small step is to start with things that > *look* obvious, like the aforementioned NIC. I am going to submit a CL > today to remove BME from that and see how much upset it causes :-) Sounds good. - -- Timothy Pearson Raptor Engineering +1 (415) 727-8645 (direct line) +1 (512) 690-0200 (switchboard) https://www.raptorengineering.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJYMyCfAAoJEK+E3vEXDOFbTHAH/2Q2qp1wiDL3eVTrmuYk0IuR bAYW3Ldl/lXwKBPVd4FRjuzhr0uUqkpCNln58qlE3xmktRkOoRJ07LqZj3Ex8KKi XEdQ2YDT+hGbGd6aQPX5nK8dUCkIpBuZrPpd4S5GNLzmINRmoVh1KhilwkaeNWn2 5Qnp9IHq1jhrCRhUQl9/Q/1AphCcV15ebjCGOuRxpw0qenSJeefEzX/UZVbdXPjX myshFFdzuGoMFVJcbI0PnzyoIcMyXJHVwaMch7a8IIbTCz6zT711K8teACRATyps b4fic19O4KzyU9Zxegl6iEZn3+U2r+buQuhWOGElAEP3n9Gjy8GnJ4hNEOfAfus= =YSkm -----END PGP SIGNATURE-----

1 0

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

21 Nov '16

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 11/20/2016 05:56 PM, ron minnich wrote: > 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? A quick check through the source seems to indicate that the generic pci_set_resource function will enable bus mastering on any PCI bridges. From that point on, if I'm not mistaken, any malicious device that exposed a bridge interface could enable mastering for any logical devices behind the bridge and attack the host. Am I missing something? Thanks! - -- Timothy Pearson Raptor Engineering +1 (415) 727-8645 (direct line) +1 (512) 690-0200 (switchboard) https://www.raptorengineering.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJYMxh/AAoJEK+E3vEXDOFbu7IIAKMYJplqgN/XRy1yPnlwC4N6 h33fAgnQs74HI0uMQU3vT1mTTqFNsJtpCJisdFmIRyDsOMHxNSdlV4JkHUE4gQPu Hj8U2VxIumBBMaezKF+mR5mwLrDBNaR23OJT9ONskssggaasGu6CYj8iJe9/ap3J sAZ/j0wM8QoGBB4A1mCMJWWQtjzfTkyKql71nRevhC59qqyqWgoME5+dcVPU350v XGZZXuPoGwQzoAVwY0Hel5Havun+68r5k++lHqUKGVcKcAOMN2s9hdHUr5f8IU4w kLEMdTFeAX+AFdtIyYiWh5Gc9XMHTBnODgUQzbahIRvpXU8X4VPm3eQ3kCYAV/Y= =mUO9 -----END PGP SIGNATURE-----

2 1

Re: [coreboot] using overlayfs to have several coreboot dev envs
by Martin Roth 21 Nov '16

21 Nov '16

I've been working on adding configs (miniconfigs) for abuild as well. The plan is to have a coreboot/configs directory with all of the configs there. Two alternatives that were discussed were coreboot/configs/VENDOR/MAINBOARD and just putting the configs in the existing src/mainboards/VENDOR/MAINBOARD directories. The reason behind the current plan was that storing all of the miniconfigs in one location would be the easiest way to maintain them. If we do redo the build, I'd like it to be optional to put the builds under the build/VENDOR/MAINBOARD directory instead of forcing that directory structure as the only way to build. Just a different target should be fine. I don't care much which one is the default, as long as there's still an option to build in the current fashion. make all = build/VENDOR/MAINBOARD/coreboot.rom make single = build/coreboot.rom Right now, for any board that's built, we know exactly where all of the files will be without having to look up what mainboard was just built. For example, if we put things under build/VENDOR/MAINBOARD, it's going to make things difficult for my flash scripts. Martin On Sun, Nov 20, 2016 at 2:52 PM, ron minnich <rminnich(a)gmail.com> wrote: > 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 > > > -- > coreboot mailing list: coreboot(a)coreboot.org > https://www.coreboot.org/mailman/listinfo/coreboot

1 0

← Newer
1
...
4
5
6
7
8
9
10
...
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