coreboot August 2017

coreboot@coreboot.org

59 participants
132 discussions

Re: [coreboot] EHCI debug that supports both Linux and Windows as a host PC
by Andrey Korolyov 04 Aug '17

04 Aug '17

On Fri, Aug 4, 2017 at 4:21 PM, Аладышев Константин <aladyshev(a)nicevt.ru> wrote: > Does a windows driver (for host PC where I want to see coreboot log) exist for this solution with BeagleBone? If you are asking about bbb connectivity, there is a 'real' ethernet PHY on chip opposed to RPI where dwc2 breaks usb-connected ethernet when enabled, for these cases I may recommend to either set up cdc-ether (available on Windows as well), use UART on board with SLIP or just use UART with tty. Non-wireless RPI Zero, for example, may suffer from lack of available ports being set up as dongle but still usable as remote log viewers. For debugging purposes involving gdb something like bbb with separate ethernet PHY is strongly preferred.

1 0

EHCI debug that supports both Linux and Windows as a host PC
by Аладышев Константин 04 Aug '17

04 Aug '17

What is the easiest and most stable way to do debug through EHCI USB port instead of COM port? Is there any EHCI dongles on market that supports both Linux and Windows as a host PC?

2 1

Support for AMD family f17h in coreboot
by Alexandre Desnoyers 04 Aug '17

04 Aug '17

Hi, I don't know if you're talking about the EPYC 7000 Series Naples Embedded SOC, or a generic Ryzen/ZEN based desktop (both f17h) According to the Processor Initialization package (PI = AGESA) available under NDA for the Embedded EPYC, the new AGESA software architecture is 100% based on EDK-II TianoCore (UEFI). I don't know how much work would be needed to hook Coreboot into a TianoCore based source code tree.... which is *very* different from the old AGESA "Arch2008" that we've seen in the past. I don't know for a fact, but I haven't seen the possibility of building an AGESA blob from the latest AGESA either. License wise, it's pretty much impossible to merge Coreboot code with proprietary AGESA code without a binary "blob". And then someone has to get the authorization from AMD to release that blob and associated include files.... I cannot offer detailed thoughts from AMD regarding Coreboot, except that they don't want to support it themselves anymore.... And that too many US-based lawyers are involved.... Regards, Alexandre Desnoyers Electronic Design Engineer Qtechnology A/S coreboot-request(a)coreboot.org wrote: > Message: 2 > Date: Thu, 3 Aug 2017 18:00:49 +0300 > From: ???????? ??????????<aladyshev(a)nicevt.ru> > To:<coreboot(a)coreboot.org> > Subject: [coreboot] Support for AMD family f17h in coreboot > Message-ID:<00fb01d30c69$4b3cede0$e1b6c9a0$(a)nicevt.ru> > Content-Type: text/plain; charset="koi8-r" > > Hello! > > Is there any plans to support AMD family f17h processors in coreboot any > time soon? Or it can be possible only if AMD will decide to provide AGESA > code for this new cpu family and nobody here knows what will AMD do? > > Does AMD still support coreboot in any way? What are chances that f17h > processors will be supported by coreboot?

1 0

Coreboot serial output on a pci-e card - how to do it?
by Taiidan＠gmx.com 03 Aug '17

03 Aug '17

Hey guys, I am curious as to how to get coreboot serial output on a pci-e or expresscard intead of the onboard port. Is it possible? - Thanks

2 1

Re: [coreboot] [Broadwell-U]How the eDP, DDI1, DDI2 are enabled?
by Zheng Bao 03 Aug '17

03 Aug '17

I need to clarify my question. For Broadwell-U, are there internal 3 display ports? Is the first one set statically as eDP? How can these ports be set as other type like VGA, HDMI? Can all these 3 ports be enabled at same time? Zheng ________________________________ From: coreboot <coreboot-bounces(a)coreboot.org> on behalf of Zheng Bao <fishbaoz(a)hotmail.com> Sent: Wednesday, August 2, 2017 6:35 AM To: coreboot(a)coreboot.org Subject: [coreboot] [Broadwell-U]How the eDP, DDI1, DDI2 are enabled? --------------------------------- # Enable eDP Hotplug with 6ms pulse register "gpu_dp_d_hotplug" = "0x06" # Enable DDI1 Hotplug with 6ms pulse register "gpu_dp_b_hotplug" = "0x06" # Enable DDI2 Hotplug with 6ms pulse register "gpu_dp_c_hotplug" = "0x06" # Set backlight PWM values for eDP register "gpu_cpu_backlight" = "0x00000200" register "gpu_pch_backlight" = "0x04000200" # Enable Panel and configure power delays register "gpu_panel_port_select" = "1" # eDP register "gpu_panel_power_cycle_delay" = "6" # 500ms register "gpu_panel_power_up_delay" = "2000" # 200ms register "gpu_panel_power_down_delay" = "500" # 50ms register "gpu_panel_power_backlight_on_delay" = "2000" # 200ms register "gpu_panel_power_backlight_off_delay" = "2000" # 200ms --------------------------------------- I assume SOC has 3 display port, called eDP, DDI1 and DDI2. The code above enable eDP only. How are the DDI1 and DDI2 enabled? Zheng

1 0

Re: [coreboot] Bay Trail uCode headers out of date
by Martin Roth 03 Aug '17

03 Aug '17

You can also find the microcode in the older FSP packages: https://downloadmirror.intel.com/25063/eng/Baytrail_FSP_Gold4.tgz M013067222D, M0130673321, M0130678815, M0130679901 Unfortunately, these files didn't make the transition into the new github site. The debug version of the FSP that's available in the FSP package also isn't available on the github site. Martin On Mon, Jul 31, 2017 at 10:59 PM, David Hendricks <david.hendricks(a)gmail.com > wrote: > Hello, > I have a Minnowboard Turbot (dual core E3826) and was only able to get it > up and running after finding microcode M0130679901 from patch 30679 ( > https://www.intel.com/content/www/us/en/embedded/ > products/bay-trail/software-and-drivers.html). > > I was wondering if someone from Intel would mind adding this along with > other potentially useful microcode to 3rdparty/blobs/soc/intel/baytrail/ . > > > -- > 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 Zoran Stojsavljevic 03 Aug '17

03 Aug '17

OK Ron, I needed some time to reconcile my thoughts. So,as Aaron pointed, it is impossible to do any long mode paging in ROM stage. And here we come to the Mystery of CB Organism (hmmmm... It is very close to some other term). ;-) Now, here is how it will play for you and Coreboot, after ROM stage (I'll call it RON stage, since it is RAM stage, divided in two sections). Why RON? Ready Or Not, that is the question! So RON stage = RAM1 stage + RAM2 stage. RAM1 stage: Since some RAM Physical mapping (AFTER CRB) MUST be done at the beginning of the RAM stage, lookalike BIOS one (in PEI phase, I assume), CB will proceed with the usual activities, set in Protected Mode. And, as we know so far how it works, it'll finish this phase, looking for Payload. Now, instead of payload stage, here we go with the RAM2 stage. Now the CB will switch to the Long Mode (flat x86_64), addressing at maximum of 48 bits of the physically available CPU address memory bus - 256 TB of DDRAM memory (I'll drop here 64 bit PAE extension (additional 4 bits of physical address space), for clarity). Here, you'll start initializing MMU, with 4 TLB tables: CR3 -> PML4 (512 entries) -> PDTP (512 entries) -> PDT (512 entries) -> PT (512 entries + last 12 bits freed for the MMU attributes). So, if your HW have in average 8GB of memory, you'll need ONLY 1 entry in PML4, 8 entries in PDTP -> and full tables for these 8 entries. I see that you'll do NOT a Virtualization, rather a logical address shift for the constant address offset. With proper init of the attributes in the PE tables, per 4KB page - your finest granularity). And, YES, you'll have your memory protection in full swing (just for the de-referencing the NULL pointers), since you do NOT have more that one process working, in linear mode (so the bus error will appear ONLY for NULL pointers). Now, after you've done this, what is the next step, somebody will ask? [A] Reverting to Protected Mode prior Payload stage? [B] Proceeding with the Long Mode passing thread of execution to payloads... Which need to operate in Long Mode!? Really??? [C] Reverting to Virtual x86 Mode??? [D] Reverting to Real Mode??? Seems that you will do scenario [A]. But if you choose to have payload as 64b Linux [B], then I see where you are pointing/going with this approach... To fast Server (?!) boot-ups, but you need to reconsider, since 64b Linux still will reconfigure MMU, doesn't it??? Or you would like to skip kernel MMU init while booting 64b kernel. Letting kernel to pick up (already) hot MMU, on fly? As far, it'll be: Boot stage + ROM stage + RON stage (RAM1 stage in Protected Mode, + RAM2 stage in 64b Long Mode) + 64b kernel payload. Solely out of FLASH (smells as DOD MIL RT applications, drones, unmanned planes, missiles)... Interesting scenario, anyway! (Mysteries of CB organisms) ;-) Zoran On Wed, Aug 2, 2017 at 9:45 PM, ron minnich <rminnich(a)gmail.com> wrote: > right, Aaron, you keep reminding me of that and I keep forgetting it :-) > > so, ok, ramstage it is for paging. The x86 is so darned annoying. We had > paging in the bootblock for PPC on linuxbios. > > On Wed, Aug 2, 2017 at 12:43 PM Aaron Durbin <adurbin(a)google.com> wrote: > >> 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 Philipp Stanner 02 Aug '17

02 Aug '17

Dear Patrick, dear Zoran & List, thank you, this was *very* helpful. I had some misunderstandings regarding function and features of the CPU-modes. Let me sum it up again and feel free to correct further mistakes. * 16-Bit-Real Mode: No virtual memory, no segmentation. 2^20 addresses of memory. * Protected Mode (flat mode?): CPU is in Protected Mode, Paging is off. The primary difference to Real Mode is that 2^32 Bytes of memory are available. Coreboot + Payloads use this mode, because they need >1MiB of memory due to various reasons * Virtual Mode: Paging is on, the MMU is on. Memory can only be accessed by using virtual addresses. Details are specified in the GDT. * Long Mode: Paged virtual 64-Bit mode. Standard mode of modern operating systems (while I presume Protected Virtual Mode is the Standard for any OS on i386) Am 02.08.2017 um 18:20 schrieb Zoran Stojsavljevic: > > > [4] Once the OS boot loader takes over (Like GRUB), it'll start OS, > which will switch from the Protected to the Virtual Mode (using MMU), > Then paging will take places, and each process will have its own set > of tables, and its own initial value for CR3 (when process context > switches). I warmly suggest to you to inspect (bit by bit) CR1 > register, since this one is crucial/essential for introducing these modes. Thanks, I will do that. I intend to play around with QEMU and maybe have a closer look to Intel's Programmer Manuals. But I hope at least one assumption is right: Once coreboot jumped into the payload no coreboot-code will be executed anymore. And once the payload jumped into Linux no payload-code will be executed anymore? Meaning the payload takes complete control over RAM and CPU. Traditional BIOS (so I very much expect SeaBIOS to do the same) stays somewhere within the 16-bit-address-space, even when Windows or Linux are running, with it's Interrupt Service Rutines ready to do stuff. Greetings P.

2 1

Re: [coreboot] how effective is neutralizing Intel ME/AMT/vPro?
by Daniel Pocock 02 Aug '17

02 Aug '17

On 02/08/17 20:43, ron minnich wrote: > > > On Wed, Aug 2, 2017 at 11:48 AM Daniel Pocock <daniel(a)pocock.pro > <mailto:daniel@pocock.pro>> wrote: > > 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. > > > I'm glad they did this but ... you need to understand that the laptop > in that case is 10 years old (or is there a newer one I missed?). > There is a core set of functionality the ME provides on newer chipsets > that as far as we know, can not be removed :-( > > For some purposes, a 10 year old laptop is quite OK If you want a secure environment to manage your PGP master keys, for example, that may be a good choice (see the PGP/PKI clean room Debian Live image) > > 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? > > > well, as purism has pointed out, due to a bug, they only check signing > on 1/4 of that ME code (IIRC). So, if you want, you could embed your > exploits in the other 3/4. That's about 65K. > > What could you do? I am guessing a lot. > > And, further, if such exploits can be done, and have been possible for > at least 10 years, it's reasonably to assume they HAVE been done and > are out there now. Bummer. Just as it is never too late to give up smoking, it is never too late to escape from mass surveillance. As a Linux user I get away with using a laptop until it is quite old but many other people have become well and truly dependent on newer hardware and software that has this massive backdoor in it. > > > > 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? > > > Can it get in via malicious email attachment? What's the path for > that? Seems hard but I'm willing to believe anything nowadays after > reading about all these sideband attacks. > I assume some email attachment may be a stepping stone for a privilege escalation attack that eventually gets into the BIOS or HDD firmware. There is also the QR-code of death. It is like the ping of death but it is designed for the firmware of the built-in webcam in your laptop. Regards, Daniel

1 0

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

02 Aug '17

right, Aaron, you keep reminding me of that and I keep forgetting it :-) so, ok, ramstage it is for paging. The x86 is so darned annoying. We had paging in the bootblock for PPC on linuxbios. On Wed, Aug 2, 2017 at 12:43 PM Aaron Durbin <adurbin(a)google.com> wrote: > 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

← Newer
1
...
8
9
10
11
12
13
14
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 August 2017