coreboot April 2017

coreboot@coreboot.org

65 participants
143 discussions

How to disassembly the coreboot.rom file
by Maxim Gusev 13 Apr '17

13 Apr '17

Hello, friends I have a couple of questions. When I run the coreboot on my motherboard it doesn't work. I have some IPs of instructions which I received by JTAG. So I want to see the instructions that are plased in the final object file. How to disassembly the coreboot.rom file? As I know it has the filesystem CBFS. So it is not the object file. I can to disasembler the object files placed in ./build/* that have the *.o format but I don't know in which of them there are corresponding instructions. Thanks. Regards, Maxim

1 0

Re: [coreboot] INTEL VBT (Video BIOS Table)
by Zoran Stojsavljevic 13 Apr '17

13 Apr '17

As I see/experience, no complains/"shooting" me so far. Thus I removed draft sign, and let Michiel Duvenkot know, so he can remove draft sign. Once again, feel free to criticize, add, change, or comment on the content. All You! Please, also note, that I did gladly agree on Igor Skochinsky's suggestions, and add section: https://en.wikipedia. org/wiki/Draft:Coreboot/VBT#INTEL_GPU_Tools , as self contained/stand alone Source Code, which does make for me the "decompiler" tool (no need to install Debian/RHEL updates as INTEL GPU Tools .rpm packages). In other words, somebody can enhance it to Igor's proposal: *1) make a "decompiler" that would convert VBT from the option ROM into a human/machinereadable text format (DONE)* *2) make a "compiler" that would take that text format and create abinary VBT from it (TO DO)3) put the binary VBT into the ACPI IGD OpRegion table ([1], [2]), orwherever the graphics driver can find it. (TO DO)* Thank you, Zoran _______ On Sun, Apr 9, 2017 at 7:18 AM, Zoran Stojsavljevic < zoran.stojsavljevic(a)gmail.com> wrote: > Here: > > [image: Inline image 1] > > https://en.wikipedia.org/wiki/Draft:Coreboot/VBT > > Zoran > > On Sun, Apr 9, 2017 at 6:45 AM, Naveed Ghori <naveed.ghori(a)dti.com.au> > wrote: > >> Please check. Link not working for me. >> ------------------------------ >> *From:* coreboot [coreboot-bounces(a)coreboot.org] on behalf of Zoran >> Stojsavljevic [zoran.stojsavljevic(a)gmail.com] >> *Sent:* Saturday, 8 April 2017 9:48 PM >> *To:* coreboot >> *Subject:* [coreboot] INTEL VBT (Video BIOS Table) >> >> Here it is: https://en.wikipedia.org/wiki/Coreboot/VBT >> >> Feel absolutely free to review it, to add/modify/discuss/hit me with the >> baseball bat, yell/scream/sob at me... :-) >> >> Best Regards, >> Zoran >> >> >

1 0

Retrieving additional payload files from CBFS
by Trammell Hudson 12 Apr '17

12 Apr '17

Is there an easy way for a running payload to extract additional files from its CBFS image in ROM? I'd like to have a reproducible kernel and initrd as the primary payload, with user data (and keys) stored in a separate payload section of the CBFS. On the build host I can use cbfstool to add/extract them from the file, but I'm not seeing an easy way to do it on the running machine short of 'dd if=/dev/mem' at the correct address. -- Trammell

3 3

Re: [coreboot] RFC: Changing CBMEM console to run as a persistent ring-buffer
by Gerd Hoffmann 12 Apr '17

12 Apr '17

Hi, > Right, sorry, I confused something while writing the explanation > there. Nevertheless, the SeaBIOS code will require a small adjustment > (same as the libpayload driver in the patch I linked) to continue > appending correctly after the log has rolled over, and I'll provide > that patch. Is it possible to figure whenever the cbmem buffer supports rollover or not, so a updated seabios version can work correctly with both old and new coreboot? cheers, Gerd

2 1

Re: [coreboot] Design discussions on gerrit
by Zoran Stojsavljevic 12 Apr '17

12 Apr '17

Interesting discussion... Thank you Patrick for making me aware of some "things". ;-) Here is what read from my search about this topic from/on the net: Processor switches to System Management Mode (SMM) from protected or real-address mode upon receiving System Management Interrupt (SMI) from various internal or external devices or generated by software. In response to SMI it executes special SMI handler located in System Management RAM (SMRAM) region reserved by the BIOS from Operating System for various SMI handlers. SMRAM is consisting of several regions contiguous in physical memory: compatibility segment (CSEG) fixed to addresses 0xA0000 - 0xBFFFF below 1MB or top segment (TSEG) that can reside anywhere in the physical memory. *If CPU accesses CSEG while not in SMM mode (regular protected mode code), memory controller forwards the access to video memory instead of DRAM. Similarly, non-SMM access to TSEG memory is not allowed by the hardware. Consequently, access to SMRAM regions is allowed only while processor is executing code in SMM mode. At boot time, system BIOS firmware initializes SMRAM, decompresses SMI handlers stored in BIOS ROM and copies them to SMRAM. BIOS firmware then should "lock" SMRAM to enable its protection guaranteed by chipset so that SMI handlers cannot be modified by the OS or any other code from this point on.* Upon receiving SMI CPU starts fetching SMI handler instructions from SMRAM in big real mode with predefined CPU state. *Shortly after that, SMI code in modern systems initializes and loads Global Descriptor Table (GDT) and transitions CPU to protected mode without paging. SMI handlers can access 4GB of physical memory.* Operating System execution is suspended for the entire time SMI handler is executing till it resumes to protected mode and restarts OS execution from the point it was interrupted by SMI. Default treatment of SMI and SMM code by the processor that supports virtual machine extensions (for example, Intel VMX) is to leave virtual machine mode upon receiving SMI for the entire time SMI handler is executing [intel_man]. Nothing can cause CPU to exit to virtual machine root (host) mode when in SMM, meaning that Virtual Machine Monitor (VMM) does not control/virtualize SMI handlers. Quite obviously that SMM represents an isolated and "privileged" environment and is a target for malware/rootkits. Once malicious code is injected into SMRAM, no OS kernel or VMM based anti-virus software can protect the system nor can they remove it from SMRAM. It should be noted that the first study of SMM based rootkits was provided in the paper [smm] followed by [phrack_smm] and a proof of concept implementation of SMM based keylogger and network backdoor in [smm_rkt]. Very interesting... Never analyzed in my entire life SMM mode (too lazy and too ignorant, I admit), but, after reading of this thread, I started searching, much more important, I started finally thinking (mozgi krutit6)! And few questions actually popped in my mind. It is obvious, that there are dedicated HW extensions in x86 CPU/PCH architecture which are enabling CPU SMM mode upon SMI int. Then, the whole show is done automatically by HW. The 0xA0000 to 0xBFFFF legacy space got swapped by 128KB of DXE creation (UEFI stage where SMRAM memory (in the first 4GB of DDRAM) is defined and initialized, then populated/decompressed from BIOS SPI as SMI handler), and then this 128KB of SMRAM is locked and shadowed by real 0xA0000 - 0xBFFFF video memory Real 16bit Mode. And, questions... marked by [#]! [1] Why BIOS flash should not be read and SMI handler decompressed outside the executable environment? OK, I do get it, BIOS flash is normally locked. [2] So, to program 2MB/4MB of Coreboot on the top of BIOS, the BIOS flash should be unlocked, correct? Or signed? OK, even then, let say, I overlooked something... Now, I see. Since it is impossible to access 128KB of SMI handler (shadowed by HW), YES, it accesses somewhere in its code PCIe function: uint32_t pci_read_config32[d](pci_devfn_t dev, *unsigned int where*), and *where* can be easily changed in other modes. Weak point for rootkit/malicious attack! The new question here is: [3] Why SMI handler should access this f-n? For exploring/testing ACPI with platform PCIe devices? Or something else??? Since I see that SMI handler is actually putting the whole HW/platform in Protected NON paged mode (making/enforcing its own GTD), to have (?) enough memory for data required (it can access all TOLUD, up to 4GB, or I am mistaken)??? And, anyway: [4] How much of very complex logic could be put in SMI (text segment) handler, in total of 128KB of code? A lot, if the whole logic is written in x86 asm, which, I assume, it is truly?! Or I overlooked something!? Thank you, Zoran _______ On Wed, Apr 12, 2017 at 7:17 AM, ron minnich <rminnich(a)gmail.com> wrote: > > > On Tue, Apr 11, 2017 at 7:18 PM Taiidan(a)gmx.com <Taiidan(a)gmx.com> wrote: > >> >> I was under the impression that coreboots native init boards disabled >> SMM post-init and that this issue only applies to intel's FSP blobbed >> stuff, am I incorrect? >> >> > we held the line on smm until about 2006, but the i945 pushed us over the > edge. I personally don't like it but what can you do? > > -- > coreboot mailing list: coreboot(a)coreboot.org > https://mail.coreboot.org/mailman/listinfo/coreboot >

1 0

Re: [coreboot] Design discussions on gerrit
by Taiidan＠gmx.com 12 Apr '17

12 Apr '17

On 04/11/2017 11:31 AM, Patrick Georgi via coreboot wrote: > Hi, > > I just pushed https://review.coreboot.org/19242, which adds a document > discussing mitigations for the ReBAR SMM attack Intel Security > presented in January. I think we had a couple of people bringing it up > on IRC and on the list, but these were relatively unstructured and > nothing happened from there. > > I'd just use this opportunity to try out Gerrit as design discussion > tool, so if you're interested in that topic, feel free to comment. > > > Thanks, > Patrick I was under the impression that coreboots native init boards disabled SMM post-init and that this issue only applies to intel's FSP blobbed stuff, am I incorrect?

3 2

Reminder: The North American coreboot conference is June 5 - 7, 2017
by Martin Roth 11 Apr '17

11 Apr '17

https://www.coreboot.org/Denver2017 The North American coreboot conference is in Denver Colorado, USA this year on June 5 - 6, with an extra day on the 7th for hacking and to work on upstream coreboot. That's just under two months from now. Registration ------------------- The prices are: - Students Attendees: $25 - Individual Attendees: $100 - Corporate Attendees: $250 Prices go up on May 5, so register soon. You will not be billed when you sign up; we are still working out payment details with the SFC. The Google form to register is here: - https://goo.gl/o2j4gX If you're averse to google forms, email me at martin(a)coreboot.org, and I'll add you directly to the registration spreadsheet. More information is available on the wiki: - https://www.coreboot.org/Denver2017 Presentations -------------------------- We still have spots for talks available, so if you'd like to give a presentation, please let us know. Talks from 15 minutes to 1 hour can be accommodated. We will also have some time for lightning talks if you just have something small to present. Please plan these for 3 - 5 minutes. Europe 2017 ---------------------- If you can’t attend the coreboot conference in Denver, the 2017 European coreboot conference is October 26 - October 29 in Bochum Germany. Information and tickets for the European conference are available here: https://ecc2017.coreboot.org/ Thanks from the Denver conference committee Martinr, Marcj, Marshall, and Chris

1 0

Re: [coreboot] RFC: Changing CBMEM console to run as a persistent ring-buffer
by Haleigh Novak 11 Apr '17

11 Apr '17

Hello, Will the ability to change the 'Room allocated for console output in CBMEM' size still be available (and functional) for those need to view the full console output due to the addition of debugging/tracing lines? HN ________________________________ From: coreboot <coreboot-bounces(a)coreboot.org> on behalf of Julius Werner via coreboot <coreboot(a)coreboot.org> Sent: Monday, April 10, 2017 3:50 PM To: Coreboot; seabios(a)seabios.org Subject: [coreboot] RFC: Changing CBMEM console to run as a persistent ring-buffer Hi folks, I'm planning to make some changes to coreboot's CBMEM console with https://review.coreboot.org/#/c/18301 that should make it easier to debug problems spanning multiple reboots. I'm trying my best to avoid breaking previous behavior and keeping it compatible with older code, but there'll be some edge cases so Aaron suggested I announce it here. The basic idea is to turn the console into a persistent ring buffer. If coreboot finds an already initialized console in memory during boot, it will just continue appending to it rather than begin writing from the start of the buffer again. This means that if you run cbmem -c, the most recent boot will always be at the bottom of the output, and you can scroll further up to see logs from the boot before that (assuming you didn't lose DRAM power or something). It may also give some runtime firmware components (like we have on ARM64) a good place to log stuff and persist crash dumps in the future. The console buffer will fill up eventually with enough reboots, so when that happens we will start discarding the oldest lines from the log. This means the behavior if the log buffer is too small for even a single full boot will become slightly different: we'll only keep the latest lines, whereas previously we would only keep the earliest lines and a counter of dropped characters. I don't think this should be an issue though, since we normally should have enough buffer to fit a whole boot anyway (the default is currently 128KB which ought to be enough for any board). The change may also cause some hiccups if you're using a newer version of coreboot with an older version of cbmem (or SeaBIOS or whatever else reads the console): it will not crash and it will still print the whole log, but if the log has rolled over (into "ring buffer mode") it will print lines out of order. This is unfortunately the best I can do with the way current readers are implemented. I'm of course also updating the code for cbmem so as soon as you deploy the new version it will be able to display buffers from both old and new coreboot versions correctly. (I'll send patches to align SeaBIOS and the Linux memconsole driver in the same manner as soon as the coreboot patch is approved.) Let me know if you have any concerns about this.

2 1

Design discussions on gerrit
by Patrick Georgi 11 Apr '17

11 Apr '17

Hi, I just pushed https://review.coreboot.org/19242, which adds a document discussing mitigations for the ReBAR SMM attack Intel Security presented in January. I think we had a couple of people bringing it up on IRC and on the list, but these were relatively unstructured and nothing happened from there. I'd just use this opportunity to try out Gerrit as design discussion tool, so if you're interested in that topic, feel free to comment. Thanks, 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

New Defects reported by Coverity Scan for coreboot
by scan-admin＠coverity.com 11 Apr '17

11 Apr '17

Hi, Please find the latest report on new defect(s) introduced to coreboot found with Coverity Scan. 1 new defect(s) introduced to coreboot found with Coverity Scan. New defect(s) Reported-by: Coverity Scan Showing 1 of 1 defect(s) ** CID 1374242: Code maintainability issues (UNUSED_VALUE) /src/soc/intel/skylake/smihandler.c: 472 in southbridge_smi_monitor() ________________________________________________________________________________________________________ *** CID 1374242: Code maintainability issues (UNUSED_VALUE) /src/soc/intel/skylake/smihandler.c: 472 in southbridge_smi_monitor() 466 /* IOTRAP(0) SMIC */ 467 if (IOTRAP(0)) { 468 if (!(trap_cycle & (1 << 24))) { /* It's a write */ 469 printk(BIOS_DEBUG, "SMI1 command\n"); 470 /* Trapped write data */ 471 data = pcr_read32(PID_PSTH, PCR_PSTH_TRPD); >>> CID 1374242: Code maintainability issues (UNUSED_VALUE) >>> Assigning value from "data & mask" to "data" here, but that stored value is overwritten before it can be used. 472 data &= mask; 473 } 474 } 475 476 printk(BIOS_DEBUG, " trapped io address = 0x%x\n", 477 trap_cycle & 0xfffc); ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V0… To manage Coverity Scan email notifications for "coreboot(a)coreboot.org", click https://u2389337.ct.sendgrid.net/wf/click?upn=08onrYu34A-2BWcWUl-2F-2BfV0V0…

1 0

← Newer
1
...
6
7
8
9
10
11
12
...
15
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 April 2017