coreboot August 2017

coreboot@coreboot.org

59 participants
132 discussions

how effective is neutralizing Intel ME/AMT/vPro?
by Daniel Pocock 02 Aug '17

02 Aug '17

I've seen various web sites about ME_Cleaner[1] and also the strategies[2] used by Purism to avoid Intel ME/AMT/vPro I understand that with LibreBoot and one of their supported laptops it is possible to completely eliminate the risk by removing 100% of proprietary/hidden code. However, for people who choose Coreboot, ME_Cleaner, a Purism laptop or some other compromise, leaving in place around 90kb of the Intel code, is there a concise way to explain the attack vectors that they eliminate and the attack vectors that remain? For example, I've read that Purism doesn't use vPro-compatible wifi hardware, so my impression is they eliminate random attacks coming in through the network and spontaneously activating Intel ME, but if malicious code does get into Intel ME by some other means (such as a malicious email attachment) it may still be able to hide there indefinitely and use any network device on the machine to call home? Regards, Daniel 1. https://github.com/corna/me_cleaner 2. https://puri.sm/learn/avoiding-intel-amt/

2 1

Re: [coreboot] About Paging, Realmode and what is going on
by Aaron Durbin 02 Aug '17

02 Aug '17

On Wed, Aug 2, 2017 at 1:36 PM, ron minnich <rminnich(a)gmail.com> wrote: > > > On Wed, Aug 2, 2017 at 12:08 PM Zoran Stojsavljevic > <zoran.stojsavljevic(a)gmail.com> wrote: >> >> >> >> So, turning on the Virtual Mode (paging ON), you'll also imply that >> Coreboot will initialize and use MMU, don't you? > > > sure. > >> >> >> Am I correct, or you can use paging without MMU?! > > > MMU must be on. > >> >> I doubt that, perhaps. So, then, I would like to see this code in Coreboot >> where MMU is initialized. And how it is initialized (maybe there is a some >> over-simplified mode of operation using 2MB pages). > > > yep. > >> >> >> And my question is: what for? Or I did not get the idea... Who really >> needs to use paging in boot-loaders? Even INTEL, which (on purpose) makes >> things way over-dimensioned and over-complicated, does NOT use paging in >> UEFI BIOSes, so far??? >> > > it's trivial to turn on paging. In harvey I've got it down to 160 lines, > including comments and white space. I made it much more compact in my CL > from 1/2014. > > If you turn on paging you can capture null pointer derefs, and all other out > of range address references. And relocatable modules are much easier.. > > My question is, why not do it? I don't see any harm. All the other platforms > in coreboot use paging. What's so special about x86 that it should not use > paging? You can't use it for CAR so that sorta throws out romstage and before. It's up to the implementation of how CAR works within the hierarchy, but with hardware page walkers that pull things through the cache things can go badly. So then you could enable paging for ramstage. Need to locate storage for the page tables, but that's not an impossible thing either. > > ron > > -- > coreboot mailing list: coreboot(a)coreboot.org > https://mail.coreboot.org/mailman/listinfo/coreboot

1 0

Re: [coreboot] About Paging, Realmode and what is going on
by ron minnich 02 Aug '17

02 Aug '17

On Wed, Aug 2, 2017 at 12:08 PM Zoran Stojsavljevic < zoran.stojsavljevic(a)gmail.com> wrote: > > > So, turning on the Virtual Mode (paging ON), you'll also imply that > Coreboot will initialize and use MMU, don't you? > sure. > > Am I correct, or you can use paging without MMU?! > MMU must be on. > I doubt that, perhaps. So, then, I would like to see this code in Coreboot > where MMU is initialized. And how it is initialized (maybe there is a some > over-simplified mode of operation using 2MB pages). > yep. > > And my question is: what for? Or I did not get the idea... Who really > needs to use paging in boot-loaders? Even INTEL, which (on purpose) makes > things way over-dimensioned and over-complicated, does NOT use paging in > UEFI BIOSes, so far??? > > it's trivial to turn on paging. In harvey I've got it down to 160 lines, including comments and white space. I made it much more compact in my CL from 1/2014. If you turn on paging you can capture null pointer derefs, and all other out of range address references. And relocatable modules are much easier.. My question is, why not do it? I don't see any harm. All the other platforms in coreboot use paging. What's so special about x86 that it should not use paging? ron

1 0

Re: [coreboot] About Paging, Realmode and what is going on
by Patrick Georgi 02 Aug '17

02 Aug '17

2017-08-02 21:08 GMT+02:00 Zoran Stojsavljevic <zoran.stojsavljevic(a)gmail.com>: > And my question is: what for? Or I did not get the idea... Who really needs > to use paging in boot-loaders? Even INTEL, which (on purpose) makes things > way over-dimensioned and over-complicated, does NOT use paging in UEFI > BIOSes, so far??? They must for X64 builds. Long Mode _requires_ page tables (even if it's a single 1TB page to create a 1:1 mapping). But fear not, UEFI also supported paging for a _really_ long time for Runtime Services, so everything DXE onward better prepares for being called by Runtime Services or SMM, even if the spec explicitly says that it shouldn't happen - it did. Apparently they just couldn't fully eschew the mantle of superfluous complexity. Patrick -- Google Germany GmbH, ABC-Str. 19, 20354 Hamburg Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg Geschäftsführer: Matthew Scott Sucherman, Paul Terence Manicle

1 0

Re: [coreboot] About Paging, Realmode and what is going on
by Zoran Stojsavljevic 02 Aug '17

02 Aug '17

Hey Ron, > You can't enter long mode (x86-64) mode without enabling paging. you need long mode if you need to operate on more than 2^36 bytes > of memory. That's coming everywhere. Hence,* the future of coreboot is unambiguously one in which paging is on and at least* *> in my case** I found it's possible to make that happen in the boot block *-- albeit a bigger boot block than we have today. So, turning on the Virtual Mode (paging ON), you'll also imply that Coreboot will initialize and use MMU, don't you? Am I correct, or you can use paging without MMU?! I doubt that, perhaps. So, then, I would like to see this code in Coreboot where MMU is initialized. And how it is initialized (maybe there is a some over-simplified mode of operation using 2MB pages). Since... You know, 32bit OSes use physical pages to map them via MMU to be virtual contiguous space (0-4GB space per process). And since CB is still 32bit creation... In other words, you would like to have ONLY one uninterruptible "process" in CB running all the time (no threading at all) to be virtualized??? And my question is: what for? Or I did not get the idea... Who really needs to use paging in boot-loaders? Even INTEL, which (on purpose) makes things way over-dimensioned and over-complicated, does NOT use paging in UEFI BIOSes, so far??? Zoran On Wed, Aug 2, 2017 at 7:15 PM, ron minnich <rminnich(a)gmail.com> wrote: > I'll try not to mess this explanation up too much, but it's partly from > the docs and partly what we've learned over the years. I am assuming that > you've at least looked at the coreboot boot block and read some of the x86 > docs, although from this note and previous notes you have written I'm still > not sure. Have you done some of your homework :-) > > The architecture definition of x86 is that power on reset starts up at > 0xffff0 in what looks to me like big real mode (a.k.a. "unreal mode" among > many other names). From using JTAG debuggers over the years it's been clear > to me anyway that it's not exactly classic x86 16-bit mode. Coreboot, like > most firmware, does a classic 16-bit longjmp with segment:offset to get to > the coreboot bootblock. This longjmp does flip us into classic x86 mode (as > is very apparent from JTAG debuggers). Coreboot in about 12 instructions > flips to 32-bit protected mode (no paging however). Then we go to C. > > FWIW, many vendors told us at the time it was impossible to write firmware > in C, as we did in 2000, so it was nice to show it could be done. > > As for paging: we've had several platforms, starting in 2000, that used > paging (which does not always imply page tables). Alpha comes to mind: we > had a basic PALCode that implemented 1:1 mapping. Most coreboot platforms > use paging. > > I note that some amount of paging is now in coreboot for x86 and maybe > someone can let us know where and when it's used. > > But as for real mode, no, starting from POR in protected mode has never > been an option intel was willing to support. We've asked ("we" not being > Google, but from my earlier life in HPC). There's no technical reason it > could not work (it's microcode, after all) but it would be a pretty big > change from the "party like it's 1978" model of the x86. > > Note that many CPUs, such PPC starting ca. 2008, can not run with paging > off; they start up with default entries in the TLB and paging is on from > power on reset. > > You can't enter long mode (x86-64) mode without enabling paging. you need > long mode if you need to operate on more than 2^36 bytes of memory. That's > coming everywhere. Hence, the future of coreboot is unambiguously one in > which paging is on and at least in my case I found it's possible to make > that happen in the boot block -- albeit a bigger boot block than we have > today. > > ron >

1 0

Re: [coreboot] Broadwell-U hangs at VGA init (update)
by Nico Huber 02 Aug '17

02 Aug '17

On 02.08.2017 15:18, Zheng Bao wrote: > i just replace the bios region with my coreboot and other parts of ibv > image untouched. is it a right way? Is that a fresh image from the IBV? or a backup from a working system? The ME firmware can store some state in its flash region and it doesn't always succeed if you restore a backup. Best option is to flash a fresh image, make sure everything works (e.g. using the original firmware and run some tool like intelmetool) and then never flash the ME region again during coreboot development (if you use flashrom use a layout). > what kinds of issue do you mean? Um, to quote yourself: >> It seems that the ME is not 100% right. and your log had this somewhere in romstage: >> ERROR: ME failed to respond Nico > > 2017年8月2日 18:58于 Nico Huber <nico.huber(a)secunet.com>写道： > On 02.08.2017 04:23, Zheng Bao wrote: >> src/soc/intel/broadwell/lpc.c >> /* Initialize power management */ >> // pch_power_options(dev); >> // pch_pm_init(dev); >> printk(BIOS_INFO, "%s,%d.\n", __func__, __LINE__); >> // pch_cg_init(dev); >> printk(BIOS_INFO, "%s,%d.\n", __func__, __LINE__); >> >> // pch_set_acpi_mode(); >> >> >> I need to skip all these 4 functions to run through, otherwise it hangs. >> What causes this? or what setting is not right? > > Did you fix your ME issue yet? it might be futile to make assumptions > about the hardware if the ME is no running correctly. > > If you are sure your ME is doing well and all four functions above fail > individually, there may be multiple issues. I'd start by diving deeper > into those function and find the first hardware access that makes it > hang. > > The first function enables SMIs based on devicetree settings. Make sure > these settings match your hardware (or set them to zero if in doubt, to > rule them out). > > Nico > >> >> >> Zheng >> >> >> ________________________________ >> From: coreboot <coreboot-bounces(a)coreboot.org> on behalf of Zheng Bao <fishbaoz(a)hotmail.com> >> Sent: Tuesday, August 1, 2017 1:51 PM >> To: Matt DeVillier >> Cc: Nico Huber; stefan.reinauer(a)coreboot.org; coreboot(a)coreboot.org >> Subject: Re: [coreboot] Broadwell-U hangs at VGA init (update) >> >> >> Refcode is added and VGA BIOS passes. >> hangs at "Set power off after power failure. " >> >> It seems that the ME is not 100% right. >> >> >> Zheng >> >>

1 0

About Paging, Realmode and what is going on
by ingegneriaforense＠alice.it 02 Aug '17

02 Aug '17

Hello everybody, following the mailing list about the questions posed by Philipp Stanner I read: "Why does every modern CPU still start in RM? Many industries run on DOS. Many system developers have created in-house BIOS extensions. x86 will never fully lose its 16-bit legacy." I'm agree with this answer, and I also understand that some legacy MUST be maintained for the backward HW compatibility, as Zoran explains. However i wonder if is there the possibility that Coreboot boots directly and exclusively in protected mode. Is it configurable this behaviour in coreboot ? That is: is it possible avoid the x86 boots in Real Mode, "forgotting" to be compatible with old hardware ? Best Regards. Vincenzo. Forensic Consultant Tribunale di Lecce Studio: Strada di Garibaldi - Contrada Paradisi 73010 Lequile (LE) cell: 339.7968555 skype: vincenzo.di_salvo

2 1

Re: [coreboot] Broadwell-U hangs at VGA init (update)
by Zheng Bao 02 Aug '17

02 Aug '17

i just replace the bios region with my coreboot and other parts of ibv image untouched. is it a right way?what kinds of issue do you mean? 2017年8月2日 18:58于 Nico Huber <nico.huber(a)secunet.com>写道： On 02.08.2017 04:23, Zheng Bao wrote: > src/soc/intel/broadwell/lpc.c > /* Initialize power management */ > // pch_power_options(dev); > // pch_pm_init(dev); > printk(BIOS_INFO, "%s,%d.\n", __func__, __LINE__); > // pch_cg_init(dev); > printk(BIOS_INFO, "%s,%d.\n", __func__, __LINE__); > > // pch_set_acpi_mode(); > > > I need to skip all these 4 functions to run through, otherwise it hangs. What causes this? or what setting is not right? Did you fix your ME issue yet? it might be futile to make assumptions about the hardware if the ME is no running correctly. If you are sure your ME is doing well and all four functions above fail individually, there may be multiple issues. I'd start by diving deeper into those function and find the first hardware access that makes it hang. The first function enables SMIs based on devicetree settings. Make sure these settings match your hardware (or set them to zero if in doubt, to rule them out). Nico > > > Zheng > > > ________________________________ > From: coreboot <coreboot-bounces(a)coreboot.org> on behalf of Zheng Bao <fishbaoz(a)hotmail.com> > Sent: Tuesday, August 1, 2017 1:51 PM > To: Matt DeVillier > Cc: Nico Huber; stefan.reinauer(a)coreboot.org; coreboot(a)coreboot.org > Subject: Re: [coreboot] Broadwell-U hangs at VGA init (update) > > > Refcode is added and VGA BIOS passes. > hangs at "Set power off after power failure. " > > It seems that the ME is not 100% right. > > > Zheng

1 0

Re: [coreboot] Broadwell-U hangs at VGA init (update)
by Nico Huber 02 Aug '17

02 Aug '17

On 02.08.2017 04:23, Zheng Bao wrote: > src/soc/intel/broadwell/lpc.c > /* Initialize power management */ > // pch_power_options(dev); > // pch_pm_init(dev); > printk(BIOS_INFO, "%s,%d.\n", __func__, __LINE__); > // pch_cg_init(dev); > printk(BIOS_INFO, "%s,%d.\n", __func__, __LINE__); > > // pch_set_acpi_mode(); > > > I need to skip all these 4 functions to run through, otherwise it hangs. What causes this? or what setting is not right? Did you fix your ME issue yet? it might be futile to make assumptions about the hardware if the ME is no running correctly. If you are sure your ME is doing well and all four functions above fail individually, there may be multiple issues. I'd start by diving deeper into those function and find the first hardware access that makes it hang. The first function enables SMIs based on devicetree settings. Make sure these settings match your hardware (or set them to zero if in doubt, to rule them out). Nico > > > Zheng > > > ________________________________ > From: coreboot <coreboot-bounces(a)coreboot.org> on behalf of Zheng Bao <fishbaoz(a)hotmail.com> > Sent: Tuesday, August 1, 2017 1:51 PM > To: Matt DeVillier > Cc: Nico Huber; stefan.reinauer(a)coreboot.org; coreboot(a)coreboot.org > Subject: Re: [coreboot] Broadwell-U hangs at VGA init (update) > > > Refcode is added and VGA BIOS passes. > hangs at "Set power off after power failure. " > > It seems that the ME is not 100% right. > > > Zheng

1 0

[RFC] How to deal with unchanged images in board status repository?
by Paul Menzel 01 Aug '17

01 Aug '17

Dear coreboot folks, Thanks to Nico’s introduction of “timeless”/“comparable” builds in commit 566dd357 (Add option for "timeless" builds) [1], it’s for example possible to find out, if a commit changed something for a certain board. > Builds with BUILD_TIMELESS=1 shall always give a bit identical output > for stable inputs. This should help verifying that resulting rom files > stay the same across commits that shouldn't change the outcome. I started to build my Lenovo X60t with `make BUILD_TIMELESS=1`, and flashrom now thankfully notifies me, if the resulting image has not changed. (Of course the configuration, the payloads, and the toolchain are unchanged here too.) ``` Warning: Chip content is identical to the requested image. ``` So how can we deal with this for our board status repository? Should I just do the an upload, and git storage model will make sure that this only takes up little space? On the other hand the coreboot and for example Linux messages will probably be a little different due to timing differences. Another option is to create a symbolic link, and commit that? Do you have other suggestions? What do you think? If we agree upon something, the build test systems out there could also be adapted, and a lot of the REACTS uploads would be just symbolic links. Thanks, Paul [1] https://review.coreboot.org/13412

1 0

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 August 2017