[coreboot] subscribe
subscribe WBR, Igor mailto:skochin...@mail.ru___ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-le...@coreboot.org
Re: [coreboot] Intel Reference Board doesn't work after inserting INT 15h/86h into Flat32.asm
Hello Toan, Wednesday, March 14, 2018, 10:13:13 AM, you wrote: TLm> I'm so sorry if this question does not really relate to TLm> Coreboot. But I'm facing a serious problem and trying to get help TLm> from you who have excellent knowledge about BIOS and HW. I'll answer just this one time. Please use your Intel support options for non-coreboot related issues. TLm> I have an Intel Reference Board. I was trying to force BIOS to wait 1 second in SEC phase. TLm> I inserted these assemble code (BIOS wait function) into very TLm> first of ProtectedModeEntryPoint in Flat32.asm file: TLm> MOV CX, 0FH TLm> MOV DX, 4240H TLm> MOV AH, 86H TLm> INT 15H TLm> Then, the board stopped working. Status code showed "00". TLm> Even when I re-flashed its original BIOS, it's still not worked. TLm> Could anyone please help me to figure out what's happen here? TLm> I appreciate your helps. The SEC phase is the earliest stage of the firmware init. The CPU has been just reset; there are no BIOS services available and the interrupt table has not even been set up yet (no RAM either), so the CPU hangs when you try to invoke an interrupt with a non-existing handler. The best you can do in this situation is probably a counted loop (with a big counter because the modern CPUs are very fast), maybe with some "out" instructions to an unused port (or even 80h) to slow it down a little. I don't know why original BIOS did not work, maybe verify that you flashed the correct binary. -- WBR, Igormailto:skochin...@mail.ru -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Gigabyte Brix
Hello Konrad, Sunday, January 21, 2018, 9:29:35 PM, you wrote: KE> Hi Igor, I know your work and I want to give kudos to you. However without being KE> kritical (it is just like that) I want to note the tips you read i.e. at winraid.com KE> really make you just more confused - eather they are refering to programmes that KE> are unavailabe or are from different contexts of Bios versions etc, or require you KE> to handle weapongrade security bypasses. Welcome to the world of BIOS modding. This stuff is not something you can just pick up in a couple hours, I'm actually impressed you managed to achieve it over a weekend. KE> Now I spent a whole weekend trying to enable DCI on the Brix. I managed it KE> in the end using only Ru.efi. KE> Because maybe coreboot people without the money to buy a SystemStudio and XDP KE> hardware for $5000 might find it interesting ther is a writeup here: KE> https://gist.github.com/eiselekd/d235b52a1615c79d3c6b3912731ab9b2#file-enabledci-txt KE> I think this method is reasonably easy and the board is cheap ($400). Nice writeup, thanks! Now you can start porting coreboot to it :) -- WBR, Igormailto:skochin...@mail.ru -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Gigabyte Brix
Hello Konrad, Sunday, January 21, 2018, 3:12:07 PM, you wrote: KE> You can probably set the DCI enable bit in the PCH softstraps in the KE> descriptor, no need to mess with the BIOS editing. It seems to be bit 17 KE> in strap 0, right next to the HAP bit: KE> value="0x1" offset="0x0" bitfield_high="17" bitfield_low="17" /> KE> offset="0x0" bitfield_high="16" bitfield_low="16" /> KE> (xml from the Intel Flash Image Tool). KE> Interesting. Where can I read about this xml definition of the KE> softstrap. Which tool can I use to modify the PCH softstrap KE> section? Do I need to Intel Flash Image Tool for that, and where can KE> I download that one? I guess there are crcs and I cannot KE> just poke around? XMLs are stored in compressed format (as Qt resource) inside the FIT binary. You can find one approach of extracting them in Positive Technologies blog: http://blog.ptsecurity.com/2017/04/intel-me-way-of-static-analysis.html You can indeed use FIT for setting the strap but you'll have to find it yourself :) Or you can just edit the descriptor directly - it's not protected by any checksums or signatures. Check e.g. how me_cleaner sets the HAP bit: print("Setting the HAP bit in PCHSTRP0 to disable Intel ME...") fdf.seek(fpsba) pchstrp0 = unpack(" I wonder weather DCI is left enabled when the BIOS start KE> initializing and probably I also need a softstrap bit for the KE> Debug Interface enable if I want to connect with DAL later? This depends on the specific BIOS implementation. I guess it's possible that they turn off DCI if it's not explicitly enabled in settings, but maybe you can intercept this with the debugger. KE> Why is this stuff so complicated? It's not complicated to firmware engineers who are familiar with low-level details of the platform and have access to the Intel docs/tools and support... If this is complicated for you, maybe you are looking at the wrong thing. -- WBR, Igormailto:skochin...@mail.ru -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Gigabyte Brix
Hello Konrad, Sunday, January 21, 2018, 9:02:30 AM, you wrote: KE> I would like to control the DCI and Debug bits in the boot process KE> and dont want to mess with the AMI bios patching. You can probably set the DCI enable bit in the PCH softstraps in the descriptor, no need to mess with the BIOS editing. It seems to be bit 17 in strap 0, right next to the HAP bit: (xml from the Intel Flash Image Tool). KE> I was wondering weather KE> there is a port that is near enough so that it might boot at lease long enough KE> so that I can hook up with the DCI cable... I think there are some Skylake-based boards in the tree (using Intel FSP), you could try to start with those if you want to go down that road. KE> 2018-01-20 23:56 GMT+00:00 taii...@gmx.com : KE> On 01/20/2018 06:38 PM, Konrad Eisele wrote: KE> Is there a chance to get coreboot running KE> on a GB-BKi5HA-7200 (i5-7200 Kabylake) or KE> a GB-BSi3-6100 (i3-6100 Skylake)? KE> You would have to do a port, which requires you have extensive KE> programming skills or a large amount of money to pay someone to do it. KE> What are you hoping to get out of coreboot? maybe there is an KE> already supported board that would suit you? -- WBR, Igormailto:skochin...@mail.ru -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] x86 validation suite
Hi Ron, Thursday, January 18, 2018, 6:54:49 PM, you wrote: rm> Anybody out there know of an x86 emulation validation suite? There's test-i386.c in QEMU which seems to be quite complete. I also found a paper "Design and Testing of a CPU Emulator" from MS Research[1]. The mentioned Giano emulator can be downloaded here (MSI installer): https://www.microsoft.com/en-us/download/details.aspx?id=52537 but I did not find the test suite from a quick look. [1] https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/techeport20cpu_test20v4.pdf -- WBR, Igormailto:skochin...@mail.ru -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Early debugging
Hi Gergely, >Понедельник, 4 декабря 2017, 13:45 +01:00 от Gergely Kiss >: > >Hi, > >I'm working on porting Coreboot to the ASUS AM1I-A motherboard and I'm a bit >stuck. > >I could successfully build Coreboot but after flashing the ROM, my board looks >to be bricked... > >Once powering on the board, the CPU fan spins up but then nothing happens, I >can't see any output on the serial console (the connection was tested prior to >flashing by running a getty on the COM port and it was working fine). > >The board is not fried as I can load back the vendor firmware and it boots up >absolutely fine. > >I'd like to find out why Coreboot would not start but don't know what tool >would be the most suitable for debugging. > >The chipset and the CPU is already supported by Coreboot but the SuperIO chip >is not. It looks to me the serial interfaces of ITE chips work the same for >all models so I believe using the common code for ITE SIO chips should work >but I'm unsure (no datasheet available). >Shall I use a PCIe serial interface card or rather try EHCI debugging? I'm >afraid in case the boot process halts at some early stage (like before >romstage) then I won't see any useful output using any of those. > >Using a POST card would be a better approach I think but my board has a single >PCIe 4x slot which seems to be unsupported by POST cards I could find on the >web (except one from a Chinese vendor but it costs about $1k which is way too >expensive) The 20-pin TPM connector on this board[1] looks really close to the legacy LPC one[2], so maybe try a POST card with LPC support? [1]: http://dlcdnet.asus.com/pub/ASUS/mb/SocketAM1/AM1I-A/E8963_AM1I-A.pdf [2]: https://www.usbid.com/datasheets/usbid/2000/2000-q1/lpc_mod_spec72.pdf > >Here's my WIP code for reference: > >https://github.com/kissg1988/coreboot/tree/master/src/mainboard/asus/am1i-a > >Any idea how to proceed? > >Thanks, >Gergely > >-- >coreboot mailing list: coreboot@coreboot.org >https://mail.coreboot.org/mailman/listinfo/coreboot WBR, Igor mailto:skochin...@mail.ru -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Is Goryachy's JTAG hack a chance for free firmware ?
Hello Enrico, Thursday, November 30, 2017, 6:54:50 PM, you wrote: EWmIc> Can we completely replace UEFI w/o any signatures ? Yes, unless your PC uses Boot Guard (so far it's been only enabled in a small percentage of enterprise laptops because it ties together CPU and PCH - you can't replace one without having to replace the other). Without Boot Guard active, the CPU will execute whatever you place in the flash, and it's up to you whether to implement signing checks or not. EWmIc> And what about ME ? I've read that the cpu itself verifies the EWmIc> signature of ME firmware, so we cant completely replace it. EWmIc> If it would be possible to read out the privkey or burn in another EWmIc> one, that blockade would be fallen. The private key does not exist anywhere in the firmware or in the chip, only somewhere in Intel's HSM (I assume). The firmware's manifest is signed with the private key at Intel[1], and the *public key* is placed next to the manifest. Only the public key is necessary for verifying the signature, and you can't patch the public key with your own because its hash is checked against a short list of accepted hashes in ME's boot ROM. So the only ways to make ME accept custom firmware would be: 1) factor the public key (RSA-1024) 2) find a pair of keys where the pubkey hash matches one of those accepted by the ME (the hash is SHA512 in the latest versions, was SHA-1 before). [1] http://info.meshcentral.com/downloads/ActivePlatformManagementDemystified/APMD-Chapter14.pdf -- WBR, Igormailto:rox...@skynet.be -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Verify option rom non-execution?
Hello Taiidan, Saturday, November 11, 2017, 12:11:56 AM, you wrote: Tgc> Hi! how can I verify the non-execution of option roms? I recently Tgc> noticed that I had somehow turned that on with one of my latest compiles Tgc> (without yabel secure mode either) You can't really prove a negative, so I can only imagine two options: - remove the possibility to execute oproms from your firmware - make a sentinel oprom which would print a warning/halt the system on execution -- WBR, Igormailto:rox...@skynet.be -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] New Subscriber
Hello Robert, Wednesday, November 8, 2017, 3:36:16 PM, you wrote: RW> 2) About proprietary BIOS RW> Is it possible to download a "full" BIOS (with descriptor, me, RW> ...), like it is stored on the mainboard flash chip?, because on RW> the lenovo support webpage I can only find BIOS-Updates, with an RW> empty offset for the descriptor, the intel me and the GbE followed RW> by the BIOS. And this .FL1 file is even biggen then 8 MiB, maybe RW> because it also includes the EC? Phoenix updates usually include a trailer with some platform-specific info (flash chip details or sometimes even a complete UEFI or win32 flash driver). If you see the bytes 42 43 D6 D6 00 31 31 00 at a "round" address, that's the trailer which can usually be cut off to get a plain BIOS binary (the result may be either a complete flash image or just the BIOS region which would have to be stitched back into the dump). Sometimes the FL1/FL2 may also be compressed with BPCVPD compression and/or have a special structure pointing to sub-regions (Bios, Me, Ec, Descriptor): https://github.com/theopolis/uefi-firmware-parser/issues/53 -- WBR, Igormailto:rox...@skynet.be -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Lenovo X220t variants with SMD-Flash-ROMs
Hello Nico, Monday, August 7, 2017, 2:16:05 PM, you wrote: NH> Hi Philipp, NH> On 05.08.2017 21:58, Philipp Stanner wrote: >> Do we have any idea what exactly they do to update the firmware internally? NH> Well, I don't. Though, the flash chip is usually only partially NH> protected (something like the upper 128KiB?). They probably only NH> update the unprotected part or put an UEFI capsule (or something NH> similar) into another part of the chip and update the protected NH> part from within the firmware on the next boot. AFAIK the capsule is not written to flash. It's usually put into RAM or may be alternatively written to the EFI system partition on disk[1] (though I don't think I've ever observed that). >> >> The wiki says once coreboot is flashed you can flash it internally. I >> suppose this means the blockade protecting the flash can be switched of >> somehow, as the vendor's have to do it to install firmware-updates. NH> The upper most part of the chip is protected by a Protected Range NH> Register (PRR). These PRRs are reset on each reboot. So the only NH> chance to write to the protected region is during early boot before NH> the firmware writes the PRR. NH> In case they do support updates to the protected region at all, it's NH> likely that the code therein writes the PRR. So it's the update mecha- NH> nism in the firmware that could be attacked (maybe it's just a check- NH> sum, who knows?). You probably can't flash a whole coreboot image this NH> way, but if you can make it write a modified firmware that doesn't set NH> the PRR (or locks it to all zero early), you'd have won. NH> But first things first, we'd have to find out when the PRR is written NH> and whether the protected region is updatable. You can use chipsec[2] to dump out the current configuration of the system and see if PRRs are indeed used (and how). [1]: http://www.uefi.org/sites/default/files/resources/UEFI_Summerfest_Insyde_2013_final.pdf [2]: https://github.com/chipsec/chipsec -- WBR, Igormailto:skochin...@mail.ru -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Lenovo X220t variants with SMD-Flash-ROMs
Hello Philipp, Saturday, August 5, 2017, 8:41:42 PM, you wrote: PS> Yes, you're probably right. PS> Though I wonder when and how they programmed the firmware. Before or PS> after soldering? Most likely before, unless they have some debug header exposed. From [1]: > When the hardware and software nears production readiness, it is > common practice to preprogram flash memory devices prior to > starting high-volume PCB manufacturing flows for two principal > reasons. First, firmware loaded onto the device can be used to > perform basic booting and testing of the PCB during manufacturing > to check system/module functionality. Second, loading the final > firmware, operating system (OS), and application code on the flash > device prior to manufacturing maintains a high-volume > manufacturing beat rate. To support these usage models, multiple > vendors provide systems for loading firmware and data into flash > memory devices prior to the PCB solder flow process. Modern flash chips don't have issues retaining programmed bits during reflow soldering as long as the correct temperature profile is observed [2]. [1]: http://www.electronicdesign.com/memory/understanding-onboard-flash-programming [2]: http://dataioinfo.com/LiveImages/26/20/DocumentURL.pdf -- WBR, Igormailto:rox...@skynet.be -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Lenovo X220t variants with SMD-Flash-ROMs
Hello Philipp, Saturday, August 5, 2017, 6:01:04 PM, you wrote: PS> PS: Rantmode: Why the hell don't they just solder a socket? It's not PS> that unrealistic that someone bricks the BIOS while updating the PS> firmware from time to time. Being able to replace the ROM with a fresh PS> one is a huge plus. A socket would add some cost; not just of the part itself but also cost of the assembly process since flash chip could not be soldered together with the rest of the components now, and possibly other logistical issues (e.g. they would have to order DIP chips specifically for this model instead of SMD parts like for everything else). It would also increase the height of the board, and you know how everyone is obsessed with thin laptops nowadays. Just because it would be convenient for maybe ten people in the world doesn't make it an incentive for the manufacturers. Besides, 99.9% users are not expected to ever open their device, let alone mess with the chips. If they get a brick (which is a pretty rare thing nowadays AFAIK), they send it off for repairs. -- WBR, Igormailto:rox...@skynet.be -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] question on SMM
Hello ron, Friday, June 30, 2017, 6:25:06 AM, you wrote: rm> there's something I am certain I don't understand about SMM on intel chipsets. rm> The question is pretty simple. Consider a system with a recent rm> intel chipset and flash. Is there some special secret sauce that rm> disables writing to flash unless in SMM and if so, what is it? Originally there were two bits in BIOS_CNTL used to effectively enable this[1]: > When BIOS_CNTL.BLE is set to 1, attempts to write enable the BIOS by > setting BIOS_CNTL.BIOSWE to 1 will immediately generate a System > Management Interrupt (SMI). It is the job of this SMI to determine > whether or not it is permissible to write enable to the BIOS, and if > not, immediately set BIOS_CNTL.BIOSWE back to 0; the end result being > that the BIOS is not writable. As described in the link, this logic is vulnerable to race conditions, so Intel added yet another bit: > This issue is mitigated by setting the SMM_BWP bit in the BIOS > Control Register along with setting BIOS Lock Enable (BLE) and > clearing BIOS Write Enable (BIOSWE). The SMM_BWP bit requires the > processor to be in SMM in order to honor writes to the BIOS region > of SPI flash, thereby mitigating the issue. So in theory all recent BIOSes should set SMM_BWP. Whether they actually do it can be checked with Chipsec[4]. For more background see [2] and [3] [1] https://www.kb.cert.org/vuls/id/766164 [2] http://opensecuritytraining.info/IntroBIOS_files/Day2_03_Advanced%20x86%20-%20BIOS%20and%20SMM%20Internals%20-%20SPI%20Flash%20Protection%20Mechanisms.pdf [3] http://composter.com.ua/documents/Exploiting_Flash_Protection_Race_Condition.pdf [4] https://github.com/chipsec/chipsec/blob/master/chipsec/modules/common/bios_wp.py -- WBR, Igormailto:rox...@skynet.be -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] : AMT bug
Hello Trammell, Thursday, May 11, 2017, 5:42:38 PM, you wrote: TH> On Thu, May 11, 2017 at 10:30:48AM -0500, Allen Krell wrote: >> [...] There are multiple keys >> >> ME - public/private key pair - Fused in by Intel and checked by Intel >> silicon - Probably different across models It's a little simpler than that: the ME ROM has a hardcoded list of pubkey hashes and accepts ME manifests signed by any of them. I think (but haven't checked) that the keys change with each major ME version. TH> If an attacker can sign an ME binary, they can provide invalid fuses to TH> the CPU microcode so that it won't check the ACM key (or provide their TH> own bootguard key so that the TPM locality will be set for the IBB TH> measurement). I'm don't think this is possible. the OEM keys (or rather, their hashes) are set in the data area of ME and are copied to the PCH/MCH fuses on first boot. These fuses are one-time programmable so can't be overwritten (supposedly) even if you manage to get ME codeexec. TH> If the attacker can sign the ACM, they can ignore the bootguard key on TH> the IBB and provide invalid measurements to the CRTM. TH> And if they can sign an IBB they can implement their own policy (but TH> not avoid TPM measurement of the IBB by the ACM). This sounds correct (I did not look into BootGuard in much detail). >> So, back to AMT bug. I believe Boot Guard (by itself) doesn't help. An >> exploiter "may" be able to reflash only the ME region and enable AMT even >> if the OEM has disabled AMT and implemented Boot Guard. Not confirmed, >> just a educated hunch. TH> That might be possible, although ideally the startup ACM or IBB can TH> ensure that the ME region is included in its measurements and this would TH> cause key unsealing or remote attestation to fail. That's one of TH> the reasons that I recommend changing the flash descriptor to allow TH> the host CPU to read the ME region. In fact I think this is exactly the reason why flashing cleaned ME fails on BootGuard-protected systems - they check ME's hash (which ME provides in the PCI register space) and fail when it changes. Though that makes me wonder how they handle ME firmware updates... -- WBR, Igormailto:skochin...@mail.ru -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] coreboot Digest, Vol 147, Issue 17
Hi Allen, Thursday, May 11, 2017, 2:01:47 PM, you wrote: AK> One thing I am still confused about is the relationship between AK> Intel Boot Guard and the regions of flash. My understanding is AK> that Boot Guard only applies to the legacy BIOS region of flash, AK> not the ME/AMT region. Is that correct? So, if that is true, AK> then is it possible to flash the ME/AMT region of flash with any AK> ME code module that has been signed with the Intel signature? Well, in theory BootGuard indeed only protects the BIOS boot block (ME has its own protection via Intel-signed manifest), so changing ME region should not affect it but apparently in practice it does lead to problems at least on *some* platforms using BootGuard: https://github.com/corna/me_cleaner/issues/6 -- WBR, Igormailto:rox...@skynet.be -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Intel ME The Way of the Static Analysis
Hello Denis, Tuesday, May 2, 2017, 2:13:13 AM, you wrote: DGC> On Tue, 25 Apr 2017 22:38:15 +0800 DGC> Shawn wrote: >> slide: >> https://www.troopers.de/downloads/troopers17/TR17_ME11_Static.pdf >> >> video: >> https://www.youtube.com/watch?v=2_aokrfcoUk >> DGC> Thanks a lot! This is very interesting. DGC> I probably missed something about the ROM bypass: Since you have flash DGC> images with ROM Bypass in use, what would prevent someone from: DGC> - Finding and buying hardware with ROM bypass enabled. Are there any DGC> business or consumers laptops/desktops/workstation with such feature? DGC> - Writing your own code in the ROM ME partition and executing it. ROM Bypass only works on pre-production hardware (e.g. reference boards used for initial development). On production hw it's ignored and mask ROM is always used. -- WBR, Igormailto:rox...@skynet.be -- coreboot mailing list: coreboot@coreboot.org https://mail.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] VGA and Graphics
Hello Zoran, Wednesday, April 5, 2017, 5:03:33 PM, you wrote: ZS> To Coreboot, ZS> http://www.uefi.org/sites/default/files/resources/UPFS11_P4_UEFI_GOP_AMD.pdf ZS> Please, read about GOP, and what GOP suppose to be. ZS> So, GOP actually need to replace vBIOS, VBT, legacy INT 10H, and ZS> complete VBE 3.0 standard. Why (I have no idea what INTEL does ZS> with GOP and how it implements it) it is not done in this ZS> fashion...?! At least this is my impression how this should be done. Well, yes, the GOP is used in UEFI for video output (e.g. in the UEFI shell or the BIOS setup screens) and in theory any OS can use it to access video after boot although I don't know any OS that does; at least both Linux and Windows use their own drivers which talk to the hardware directly (and those drivers seem to require VBT currently). Though I think the Windows bootloader (winload.efi) can use GOP to display the boot menu. Intel provides a binary-only GOP driver (IntelGopDriver.efi) to OEMs who embed it into their UEFI implementations. I don't know if it itself requires VBT. ZS> I'll continue to investigate. ZS> Thank you, ZS> Zoran ZS> On Wed, Apr 5, 2017 at 4:54 PM, Matt DeVillier ZS> wrote: ZS> On Tue, Apr 4, 2017 at 10:12 PM, Zoran Stojsavljevic ZS> wrote: ZS> Hello Matt, ZS> Pretty sure there is NO Option ROM, vBIOS and INT10H. Why INTEL ZS> for GOP uses VBT is point of debate. Probably just reduced ZS> functionality up to 1280x1024. So they have VBT to support BIOS phase GOP GFX. Only! ZS> From what I can tell, it's mainly used to provide the output ZS> connector types/mapping to the GOP driver, as well as level shifting etc. ZS> ZS> But I am also 100% sure neither GOP, neither VBT survives post ZS> BIOS phase. It is out of mind to use VBT for WUXGA, or 1080p, or ZS> 4K displays, don't you agree? The detected GFX I/F are passed to ZS> Linux as Run Time info (via HOB). Then Linux brings from scratch ZS> GFX, using its own, modern I/Fs. And ports appropriate drivers to existing GFX info from HOB. ZS> The VBT data is used by both the Linux and Windows display ZS> drivers (via the OpRegion ACPI structure), and the latter will ZS> give you a nice black screen if your VBT is missing or incorrectly ZS> configured. As I noted above, it appears to be used more for ZS> output/pipe info than display modes (which are all generated from ZS> EDID, outside of standard VESA/CEA ones) ZS> On Tue, Apr 4, 2017 at 10:12 PM, Zoran Stojsavljevic ZS> wrote: ZS> Hello Matt, ZS> Pretty sure there is NO Option ROM, vBIOS and INT10H. Why INTEL ZS> for GOP uses VBT is point of debate. Probably just reduced ZS> functionality up to 1280x1024. So they have VBT to support BIOS phase GOP GFX. Only! ZS> But I am also 100% sure neither GOP, neither VBT survives post ZS> BIOS phase. It is out of mind to use VBT for WUXGA, or 1080p, or ZS> 4K displays, don't you agree? The detected GFX I/F are passed to ZS> Linux as Run Time info (via HOB). Then Linux brings from scratch ZS> GFX, using its own, modern I/Fs. And ports appropriate drivers to existing GFX info from HOB. ZS> Zoran ZS> On Tue, Apr 4, 2017 at 11:51 PM, Matt DeVillier ZS> wrote: ZS> On Tue, Apr 4, 2017 at 2:23 PM, Zoran Stojsavljevic ZS> wrote: ZS> Furthermore, let me tell you all that this is a mechanism to ZS> support ONLY The Legacy BIOS (UEFI works ONLY with GOP, but this ZS> is another dimension/discussion), and, to all of your knowledge ZS> (which I have no idea how deep it is, I doubt), VBT table survives ZS> postmortem BIOS. By Linux, it will be RELOCATED into much higher ZS> (over 1MB) 32bit protected mode memory (addresses recalculated), ZS> and still use INT10H, using vBIOS (Option ROM, my best guess) down there. ZS> no, the UEFI GOP driver needs the VBT to actually do anything. ZS> Look at any current PC UEFI firmware, or even x86 ChromeOS ZS> firmware, and you'll see they all use/contain a VBT still. -- WBR, Igormailto:skochin...@mail.ru -- coreboot mailing list: coreboot@coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] VGA and Graphics
Hello Patrick, Tuesday, April 4, 2017, 8:54:09 PM, you wrote: PR> VBT is documented by intel-gpu-tools. There's intel_vbt_decode PR> (former intel_bios_decode) available PR> https://cgit.freedesktop.org/xorg/app/intel-gpu-tools/tree/tools/intel_vbt_decode.c PR> that will print all tables in human readable form. Nice find! I did not realize this tool supports that many structures; for some reason I thought it just prints some general info without details. So now that we have a dumper the following should be possible: 1) make a "decompiler" that would convert VBT from the option ROM into a human/machine readable text format 2) make a "compiler" that would take that text format and create a binary VBT from it 3) put the binary VBT into the ACPI IGD OpRegion table ([1], [2]), or wherever the graphics driver can find it. So, basically, an approach similar to ich9gen for the flash descriptor/gbe. This should allow getting rid of the option ROM if real mode support is not required. [1] https://01.org/sites/default/files/documentation/acpi_igd_opregion_spec_0.pdf [2] https://lwn.net/Articles/429319/ PR> Am 4. April 2017 20:45:15 MESZ schrieb Nico Huber : PR> Hi Ron, PR> On 04.04.2017 19:46, ron minnich wrote: PR> Igor, if you are going to say things like "AFAIK there is no public PR> description of these tables' layout and contents, only Intel knows how to PR> build and parse them.", it's really a good idea to back it up with a PR> primary source, especially since you also use phrases like "I assume" and PR> "I guess". I am pretty sure you're wrong in this case. The V in VBT, as I PR> understand it, means VESA, and VESA has been a standard for about 30 years. PR> PR> Please, everyone, if you're going to move this conversation forward, you PR> need to cite primary sources at least, such as this one: PR> http://www.petesqbsite.com/sections/tutorials/tuts/vbe3.pdf. PR> now you got confused too. I'll try to clarify. PR> VBE means VESA (Video Electronics Standards Association) BIOS Extension. PR> It's a Video BIOS interface extension (i.e. specifying additional BIOS PR> calls). Don't know if it was public from the beginning (you often have PR> to be a VESA member to get access to their "standards"), but the inter- PR> face is used by many open source programs. It's vendor independent. Also PR> it's off-topic, nobody was discussing it here. PR> As Igor noted, VBE has absolutely nothing to do with VBT. PR> VBT means Video BIOS Table. It's a 100% Intel specific table of confi- PR> guration options for Intel's Video BIOS and Intel's graphics drivers. PR> There is no public documentation, but as it's used by the Linux driver, PR> at least the structure and some of the values are publicly "documented" PR> [1]. Developers of the i915 Linux driver stated that they are not wil- PR> ling to support systems without a VBT. Most features of the i915 driver PR> work without a VBT by chance. But anything board specific, like inte- PR> grated panels in laptops, will likely _not_ work. I'd also expect that PR> they won't count it as a regression if something breaks but would still PR> work with a VBT. (Windows won't even try to get things running without PR> VBT, AFAIK.) PR> An OEM should have access to Intel's binary configuration tool and the PR> specification file for the VBT of his processor's generation. It comes PR> along with the VBIOS, I suppose. PR> Nico PR> PS. Igor, Zoran please write text-only emails or at least make sure the PR> text version is readable and quotes are visible as quotes. PR> [1] PR> https://www.kernel.org/doc/html/latest/gpu/i915.html#video-bios-table-vbt -- WBR, Igor -- coreboot mailing list: coreboot@coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] VGA and Graphics
Hello ron, Wednesday, April 5, 2017, 5:16:33 PM, you wrote: rm> Zoran, given that we still see _MP_ and even $PIR tables in BIOS, rm> is it possible that VBT might always be there even if it's not strictly needed? rm> How do non-EFI kernels get information about video if not via the VBT? int 10h would be my guess, or possibly that PMInfoBlock VBE3 table. Or maybe they just load whatever driver matches the PCI ID and let it handle the details. rm> On Wed, Apr 5, 2017 at 8:03 AM Zoran Stojsavljevic rm> wrote: rm> To Coreboot, rm> http://www.uefi.org/sites/default/files/resources/UPFS11_P4_UEFI_GOP_AMD.pdf rm> Please, read about GOP, and what GOP suppose to be. rm> So, GOP actually need to replace vBIOS, VBT, legacy INT 10H, and rm> complete VBE 3.0 standard. Why (I have no idea what INTEL does rm> with GOP and how it implements it) it is not done in this rm> fashion...?! At least this is my impression how this should be done. rm> I'll continue to investigate. rm> Thank you, rm> Zoran rm> On Wed, Apr 5, 2017 at 4:54 PM, Matt DeVillier rm> wrote: rm> On Tue, Apr 4, 2017 at 10:12 PM, Zoran Stojsavljevic rm> wrote: rm> Hello Matt, rm> Pretty sure there is NO Option ROM, vBIOS and INT10H. Why INTEL rm> for GOP uses VBT is point of debate. Probably just reduced rm> functionality up to 1280x1024. So they have VBT to support BIOS phase GOP GFX. Only! rm> From what I can tell, it's mainly used to provide the output rm> connector types/mapping to the GOP driver, as well as level shifting etc. rm> rm> But I am also 100% sure neither GOP, neither VBT survives post rm> BIOS phase. It is out of mind to use VBT for WUXGA, or 1080p, or rm> 4K displays, don't you agree? The detected GFX I/F are passed to rm> Linux as Run Time info (via HOB). Then Linux brings from scratch rm> GFX, using its own, modern I/Fs. And ports appropriate drivers to existing GFX info from HOB. rm> The VBT data is used by both the Linux and Windows display rm> drivers (via the OpRegion ACPI structure), and the latter will rm> give you a nice black screen if your VBT is missing or incorrectly rm> configured. As I noted above, it appears to be used more for rm> output/pipe info than display modes (which are all generated from rm> EDID, outside of standard VESA/CEA ones) rm> On Tue, Apr 4, 2017 at 10:12 PM, Zoran Stojsavljevic rm> wrote: rm> Hello Matt, rm> Pretty sure there is NO Option ROM, vBIOS and INT10H. Why INTEL rm> for GOP uses VBT is point of debate. Probably just reduced rm> functionality up to 1280x1024. So they have VBT to support BIOS phase GOP GFX. Only! rm> But I am also 100% sure neither GOP, neither VBT survives post rm> BIOS phase. It is out of mind to use VBT for WUXGA, or 1080p, or rm> 4K displays, don't you agree? The detected GFX I/F are passed to rm> Linux as Run Time info (via HOB). Then Linux brings from scratch rm> GFX, using its own, modern I/Fs. And ports appropriate drivers to existing GFX info from HOB. rm> Zoran rm> On Tue, Apr 4, 2017 at 11:51 PM, Matt DeVillier rm> wrote: rm> On Tue, Apr 4, 2017 at 2:23 PM, Zoran Stojsavljevic rm> wrote: rm> Furthermore, let me tell you all that this is a mechanism to rm> support ONLY The Legacy BIOS (UEFI works ONLY with GOP, but this rm> is another dimension/discussion), and, to all of your knowledge rm> (which I have no idea how deep it is, I doubt), VBT table survives rm> postmortem BIOS. By Linux, it will be RELOCATED into much higher rm> (over 1MB) 32bit protected mode memory (addresses recalculated), rm> and still use INT10H, using vBIOS (Option ROM, my best guess) down there. rm> no, the UEFI GOP driver needs the VBT to actually do anything. rm> Look at any current PC UEFI firmware, or even x86 ChromeOS rm> firmware, and you'll see they all use/contain a VBT still. -- WBR, Igor -- coreboot mailing list: coreboot@coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] VGA and Graphics
Hello ron, Tuesday, April 4, 2017, 7:46:12 PM, you wrote: Igor, if you are going to say things like "AFAIK there is no public description of these tables' layout and contents, only Intel knows how to build and parse them.", it's really a good idea to back it up with a primary source, especially since you also use phrases like "I assume" and "I guess". I am pretty sure you're wrong in this case. The V in VBT, as I understand it, means VESA, and VESA has been a standard for about 30 years. Please, everyone, if you're going to move this conversation forward, you need to cite primary sources at least, such as this one: http://www.petesqbsite.com/sections/tutorials/tuts/vbe3.pdf. Thanks Ron and sorry for not providing any sources. However, VBT actually stands for "*Video* (not VESA) BIOS Table" , as mentioned e.g. in [2]: "The Video BIOS Table (VBT) is a block of customizable platform-specific data used by the Video BIOS and device drivers such as Flat Panel Timings, OEM definable Mode Timing, GPIO pins, Clock, and more.". VESA (formerly Video Electronics Standards Association) is not a standard but an organization; they do make standards however, such as the above-mentioned VBE but also DDC, EDID, DisplayPort and others [4]. As far as I can tell, VBE has no relation to VBT (at least I could not find any mention of VBT in that VBE PDF). And apparently I was wrong and there *is* some (high-level) description of what's in those tables. E.g. from [1] and [3] "The VBT consists of a VBT Header (defined as struct vbt_header), a BDB Header (struct bdb_header), and a number of BIOS Data Blocks (BDB) that contain the actual configuration information. The VBT Header, and thus the VBT, begins with “$VBT” signature. The VBT Header contains the offset of the BDB Header. The data blocks are concatenated after the BDB Header. The data blocks have a 1-byte Block ID, 2-byte Block Size, and Block Size bytes of data. (Block 53, the MIPI Sequence Block is an exception.)" However I was not able to find a full list and exact layout of those blocks. Possibly some could be recovered from the i915 (and others) Intel driver sources (maybe enough to support Linux). [1] (Intel) Linux GPU Driver Developer’s Guide » drm/i915 Intel GFX Driver - https://01.org/linuxgraphics/gfx-docs/drm/gpu/i915.html [2] Intel® Embedded Media and Graphics Driver User Guide - http://www.intel.com/content/dam/support/us/en/documents/boardsandkits/gfx_37.15.0.1073_usersguide.pdf [3] Display Hardware Handling. Chapter 4 drm/i915 Intel GFX Driver https://01.org/linuxgraphics/gfx-docs/drm/ch04s02.html [4] https://en.wikipedia.org/wiki/Video_Electronics_Standards_Association thanks ron On Tue, Apr 4, 2017 at 10:19 AM Igor Skochinsky via coreboot wrote: Hello Zoran, Monday, April 3, 2017, 8:58:43 PM, you wrote: VBT should fulfill this VBE standard, as my best understanding is, or not?! VBE only describes the int 10h BIOS interface extensions, VBT are tables used by Intel to provide info about how to control the GPU (I assume). AFAIK there is no public description of these tables' layout and contents, only Intel knows how to build and parse them. Both VBE(code) and VBT (data) may be present in the video card's option ROM, I guess that's the only common part. Zoran On Mon, Apr 3, 2017 at 7:36 PM, Igor Skochinsky via coreboot wrote: Hello Zoran, Monday, April 3, 2017, 9:24:41 AM, you wrote: > VBT is not code, it's a table -- that's what the T is -- and you can create > it any way you want. Not going to say more, anyway. Just to point to the standard: https://en.wikipedia.org/wiki/VESA_BIOS_Extensions Not sure why you posted this link. VBE is not VBT, it's a completely separate and different thing. To clever enough! ;-) Zoran On Mon, Apr 3, 2017 at 2:38 AM, ron minnich wrote: As for graphics startup, here's what I learned when I was doing this in 2012/2013: the kernel could start sandy and ivy with no vbios needed. However, I have been told that the veil of secrecy has started to draw a bit closer in subsequent chipsets, and that something like a VGA BIOS/GOP has to run or graphics will not work. I really don't know, I have not looked at this in over 3 years. Todd, just to make sure we're on the same page, VBT is not code, it's a table -- that's what the T is -- and you can create it any way you want. Also, as for numbers: the fastest graphics startup, by far, was when we had coreboot- based startup with configuration specialized to the chromeos laptop. How fast? At one point we had a pixel booting to chromeos prompt in 2.7 seconds, reduced from 7.7 seconds when linux did the graphics init. We've seen that the linux graphics init is highly concurrent and generalized, and that tends to mean slow. Of course this was all f
Re: [coreboot] VGA and Graphics
Hello Zoran, Monday, April 3, 2017, 8:58:43 PM, you wrote: VBT should fulfill this VBE standard, as my best understanding is, or not?! VBE only describes the int 10h BIOS interface extensions, VBT are tables used by Intel to provide info about how to control the GPU (I assume). AFAIK there is no public description of these tables' layout and contents, only Intel knows how to build and parse them. Both VBE(code) and VBT (data) may be present in the video card's option ROM, I guess that's the only common part. Zoran On Mon, Apr 3, 2017 at 7:36 PM, Igor Skochinsky via coreboot wrote: Hello Zoran, Monday, April 3, 2017, 9:24:41 AM, you wrote: > VBT is not code, it's a table -- that's what the T is -- and you can create > it any way you want. Not going to say more, anyway. Just to point to the standard: https://en.wikipedia.org/wiki/VESA_BIOS_Extensions Not sure why you posted this link. VBE is not VBT, it's a completely separate and different thing. To clever enough! ;-) Zoran On Mon, Apr 3, 2017 at 2:38 AM, ron minnich wrote: As for graphics startup, here's what I learned when I was doing this in 2012/2013: the kernel could start sandy and ivy with no vbios needed. However, I have been told that the veil of secrecy has started to draw a bit closer in subsequent chipsets, and that something like a VGA BIOS/GOP has to run or graphics will not work. I really don't know, I have not looked at this in over 3 years. Todd, just to make sure we're on the same page, VBT is not code, it's a table -- that's what the T is -- and you can create it any way you want. Also, as for numbers: the fastest graphics startup, by far, was when we had coreboot- based startup with configuration specialized to the chromeos laptop. How fast? At one point we had a pixel booting to chromeos prompt in 2.7 seconds, reduced from 7.7 seconds when linux did the graphics init. We've seen that the linux graphics init is highly concurrent and generalized, and that tends to mean slow. Of course this was all far faster than the 8086-mode vga BIOS supplied by "the vendor". But we were a bit surprised to see how much faster coreboot was than the linux kernel. I doubt this speed difference matters any more, since boot time only needs to be "fast enough" nowadays and 10 seconds seems to do it for most people -- plus, any 5-second advantage in boot time vanishes as soon as you go to your first web page. ron On Sun, Apr 2, 2017 at 5:31 PM ron minnich wrote: So, I'll mention go userland one last time, for a simple reason: I have it on good authority that at some places, saying you have a go userland instead of a c userland checks a check box on a security checklist. I think that's a sensible decision, having watched all the awful ways that C programs tend to go wrong :-) ron -- coreboot mailing list: coreboot@coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot -- WBR, Igor -- coreboot mailing list: coreboot@coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot -- WBR, Igor-- coreboot mailing list: coreboot@coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] VGA and Graphics
Hello Zoran, Monday, April 3, 2017, 9:24:41 AM, you wrote: > VBT is not code, it's a table -- that's what the T is -- and you can create > it any way you want. Not going to say more, anyway. Just to point to the standard: https://en.wikipedia.org/wiki/VESA_BIOS_Extensions Not sure why you posted this link. VBE is not VBT, it's a completely separate and different thing. To clever enough! ;-) Zoran On Mon, Apr 3, 2017 at 2:38 AM, ron minnich wrote: As for graphics startup, here's what I learned when I was doing this in 2012/2013: the kernel could start sandy and ivy with no vbios needed. However, I have been told that the veil of secrecy has started to draw a bit closer in subsequent chipsets, and that something like a VGA BIOS/GOP has to run or graphics will not work. I really don't know, I have not looked at this in over 3 years. Todd, just to make sure we're on the same page, VBT is not code, it's a table -- that's what the T is -- and you can create it any way you want. Also, as for numbers: the fastest graphics startup, by far, was when we had coreboot- based startup with configuration specialized to the chromeos laptop. How fast? At one point we had a pixel booting to chromeos prompt in 2.7 seconds, reduced from 7.7 seconds when linux did the graphics init. We've seen that the linux graphics init is highly concurrent and generalized, and that tends to mean slow. Of course this was all far faster than the 8086-mode vga BIOS supplied by "the vendor". But we were a bit surprised to see how much faster coreboot was than the linux kernel. I doubt this speed difference matters any more, since boot time only needs to be "fast enough" nowadays and 10 seconds seems to do it for most people -- plus, any 5-second advantage in boot time vanishes as soon as you go to your first web page. ron On Sun, Apr 2, 2017 at 5:31 PM ron minnich wrote: So, I'll mention go userland one last time, for a simple reason: I have it on good authority that at some places, saying you have a go userland instead of a c userland checks a check box on a security checklist. I think that's a sensible decision, having watched all the awful ways that C programs tend to go wrong :-) ron -- coreboot mailing list: coreboot@coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot -- WBR, Igor-- coreboot mailing list: coreboot@coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Where to get ME image/flash descriptors for the x220?
Hello Taiidan, Tuesday, March 7, 2017, 6:23:37 AM, you wrote: Tgc>Uhh thanks but that's kinda missing the point of this - that I Tgc>don't want binaries from random people on the internet. Alas, the 8duj28us.exe update and a few others I checked do not seem to contain the ME region or the descriptor. There is 8duj28us.exe with the ME update but it requires an already running ME to be applied. You could in theory extract the partitions from it and assemble into a valid ME region by constructing an FPT but that's not trivial. I would suggest you to just take the descriptor and ME region from "random people on the internet". The descriptor does not contain any code and the ME firmware is signed by Intel so it can't be backdoored by randos (there are much easier ways to hack people than stealing keys from Intel). Tgc>I need to know how to extract it from the bios update files, not the bios already on the EEPROM. Tgc>On 03/06/2017 11:35 PM, Matt DeVillier wrote: Tgc>>I have the IFD and ME from an x220 that I recently flashed with coreboot Tgc>>for a customer, extracted from their stock firmware, and verified working Tgc>>with the coreboot ROM I subsequently flashed. Can zip and send via email, Tgc>>or whatever you prefer Tgc>?On Mon, Mar 6, 2017 at 10:23 PM, taii...@gmx.com wrote: Tgc>?On 03/05/2017 05:20 AM, Arthur Heymans wrote: Tgc>?"taii...@gmx.com" writes: Tgc>?Well I managed to download the latest BIOS from the lenovo site, which Tgc>?includes an ME update now the issue is that I can't seem to figure out Tgc>?how to extract it from the .FL1 and .FL2 files. Tgc>?Those might have a length too long to fit a flash so you need to trim Tgc>?those down before using ifdtool on those (If they contain and ifd of Tgc>?course) Tgc>?so depending on size of rom Tgc>?dd if=FL1(or 2)file of=vendor_bios.rom bs=1 count=xM Tgc>?and then ifdtool -x vendor_bios.rom Tgc>?It didn't work after that still "no flash descriptor found in this Tgc>?image" Tgc>?These are the files and the flash chip on the board is 8M Tgc>?8523776 '$01CB000.FL1' Tgc>?8523776 '$01CB000.FL2' Tgc>?8523776 '$01CB100.FL2' Tgc>?All of them have different hashes, but I do not know what makes them Tgc>?different (maybe it is for various board revisions?) Tgc>?I would also like to know as to how I can re-flash the EC firmware if Tgc>?that could potentially cause problems, I of course do not know if it Tgc>?has DMA. Tgc>?Only existing tool to flash EC is using vendor tool. Tgc>?EC are only accessed trough port mapped IO (or on newer ones also via Tgc>?memory mapped IO). EC itself does not have DMA afaik. Tgc>?-- Tgc>?coreboot mailing list: coreboot@coreboot.org Tgc>?https://www.coreboot.org/mailman/listinfo/coreboot -- WBR, Igormailto:rox...@skynet.be -- coreboot mailing list: coreboot@coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Back to original BIOS
>Четверг, 9 февраля 2017, 12:16 +01:00 от Michal Widlok >: > >Hello, > >Igor - I've checked it again. Mac is really at addresses 0x5F6000, 0x5F7000 - >or my ghex editor does not work :-). The flash chip is 8MB (0x80), so fits >right in. I will try Yours procedure, but I'm concerned about cutting image at >0x40 - are You talking about 4MB flash? All my laptops has 8MB. Ah, looks like you should use the files from the 7UET94WW directory, which are 8MB for (unpacked) FL1 and 4MB for FL2 (you should use 20- 40 from it). > >Zoran - Michael is OK. In fact in polish Michal should end with special polish >letter "ł", so I'm not sure if "international" Michael is not better anyway. > >Best Regards, >Michal Widlok > > >On Thu, Feb 9, 2017 at 9:50 AM, Zoran Stojsavljevic < >zoran.stojsavlje...@gmail.com > wrote: >>Hello Igor, >> >>Interesting emails. I should admit. For sure worth exploration, especially >>GIT Hub application. :-) >> >>Michal (finally, I got your correct name, idiot me), >> >>I'll come back to this thread. I am last 3 days very busy. Very very busy, >>but, certainly, I'll get free time, and will explore this opportunity, since >>it makes my old, not so sharp anymore eyes very wide! >> >>Thank you all, >>Zoran >> >>On Wed, Feb 8, 2017 at 10:46 PM, Igor Skochinsky via coreboot < >>coreboot@coreboot.org > wrote: >>>P.S. >>> >>> >>>Hello Michal, >>> >>>The T400 BIOS is in a Pre-UEFI Phoenix FFV format. You can use >>>phoenix_extract.py[1] to extract modules from it. >>> >>>To go back to Lenovo BIOS you can try the following: >>> >>>1) download an update from lenovo (e.g. 7uuj49us.exe) >>>2) unpack it with innounp >>> >>>2b) apparently innoextract [2] can be used on non-Windows platforms >>> >>>[2]: http://constexpr.org/innoextract/ >>> >>> >>>3a) take the FL2 file (e.g. $01B8100.FL2), cut out from 0x20 to >>>0x40 and use the resulting image to replace coreboot in the BIOS region >>>(end of flash). >>>3b) take the FL1 file (e.g. $01B8100.FL1), unpack it with bcpvd from [1] >>>and flash the result (it's a complete flash image with descriptor and ME) >>>after cutting it at 0x40 >>>4) according to the descriptor in unpacked FL1 , the GbE region is at >>>001F6000 - 001F7FFF, so that's the most likely place for storing the MAC >>>address. I'm not sure why your desc.rom lists 5F6000 - 005F7FFF... I think >>>that's outside the flash chip. >>> >>>[1]: https://github.com/coreboot/bios_extract >>> >>>-- >>>WBR, >>> Igor mailto:rox...@skynet.be >>> >>> >>> >>>-- >>>WBR, >>> Igor mailto:skochin...@mail.ru >>>-- >>>coreboot mailing list: coreboot@coreboot.org >>>https://www.coreboot.org/mailman/listinfo/coreboot >> > >-- >coreboot mailing list: coreboot@coreboot.org >https://www.coreboot.org/mailman/listinfo/coreboot WBR, Igor mailto:skochin...@mail.ru -- coreboot mailing list: coreboot@coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Back to original BIOS
Title: Re: [coreboot] Back to original BIOS P.S. Hello Michal, The T400 BIOS is in a Pre-UEFI Phoenix FFV format. You can use phoenix_extract.py[1] to extract modules from it. To go back to Lenovo BIOS you can try the following: 1) download an update from lenovo (e.g. 7uuj49us.exe) 2) unpack it with innounp 2b) apparently innoextract [2] can be used on non-Windows platforms [2]: http://constexpr.org/innoextract/ 3a) take the FL2 file (e.g. $01B8100.FL2), cut out from 0x20 to 0x40 and use the resulting image to replace coreboot in the BIOS region (end of flash). 3b) take the FL1 file (e.g. $01B8100.FL1), unpack it with bcpvd from [1] and flash the result (it's a complete flash image with descriptor and ME) after cutting it at 0x40 4) according to the descriptor in unpacked FL1 , the GbE region is at 001F6000 - 001F7FFF, so that's the most likely place for storing the MAC address. I'm not sure why your desc.rom lists 5F6000 - 005F7FFF... I think that's outside the flash chip. [1]: https://github.com/coreboot/bios_extract -- WBR, Igor mailto:rox...@skynet.be -- WBR, Igor mailto:skochin...@mail.ru -- coreboot mailing list: coreboot@coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Back to original BIOS
Title: Re: [coreboot] Back to original BIOS Hello Michal, The T400 BIOS is in a Pre-UEFI Phoenix FFV format. You can use phoenix_extract.py[1] to extract modules from it. To go back to Lenovo BIOS you can try the following: 1) download an update from lenovo (e.g. 7uuj49us.exe) 2) unpack it with innounp 3a) take the FL2 file (e.g. $01B8100.FL2), cut out from 0x20 to 0x40 and use the resulting image to replace coreboot in the BIOS region (end of flash). 3b) take the FL1 file (e.g. $01B8100.FL1), unpack it with bcpvd from [1] and flash the result (it's a complete flash image with descriptor and ME) after cutting it at 0x40 4) according to the descriptor in unpacked FL1 , the GbE region is at 001F6000 - 001F7FFF, so that's the most likely place for storing the MAC address. I'm not sure why your desc.rom lists 5F6000 - 005F7FFF... I think that's outside the flash chip. [1]: https://github.com/coreboot/bios_extract -- WBR, Igor mailto:rox...@skynet.be -- coreboot mailing list: coreboot@coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Does the 62xx Series Opteron work *securely* without microcode?
Hello Timothy, Wednesday, January 25, 2017, 6:32:29 PM, you wrote: TP> -BEGIN PGP SIGNED MESSAGE- TP> Hash: SHA1 TP> On 01/25/2017 11:26 AM, Aaron Durbin wrote: >> On Wed, Jan 25, 2017 at 11:24 AM, Timothy Pearson >> wrote: >> On 01/24/2017 10:55 PM, taii...@gmx.com wrote: > I know the 63xx has a very fatal NMI exploit, but according to the > libreboot (oh no) website the 62xx works safely out of the box without > microcode however I would like to confirm if this is actually true. > > I looked at the errata .pdf from the AMD website but I didn't see > anything that seemed significant. > > >> >> As far as we have been able to determine it does, again with the caveat >> that this is without microcode _updates_, not without microcode. There >> is still the off chance that these CPUs ship with a backdoor inside the >> burnt microcode ROM that is patched out with an update. Unlike POWER >> and ARM we are solely dependent on the vendor being trustworthy enough >> to disclose issues in their errata document; outside of that, there is >> simply no feasible way to know for certain what bugs are lurking inside >> the CPU. >> >>> POWER and ARM parts can have microcode too. That's up to the >>> implementation. I'm not sure how you can distinguish the difference. >>> Because one posts an update vs others never indicating there is an >>> update? Even if parts have no microcode, there's a possibility of >>> backdoors baked into the silicon. In all situations one needs to trust >>> the vendor. TP> I am definitely aware of that; the difference is that with POWER the TP> microcode is open (though documentation is lacking), and most of the TP> mainstream ARM implementations lack microcode. ARM1 had microcode[1], are you sure the current cores don't? The TRMs do mention revision numbers after all. [1] http://www.righto.com/2016/02/reverse-engineering-arm1-processors.html -- WBR, Igormailto:rox...@skynet.be -- coreboot mailing list: coreboot@coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Intel ME Question
Hello bancfc, Friday, December 23, 2016, 9:13:16 PM, you wrote: boo> Hi, boo> Seeing that many of you know a lot about Intel's ME I wanted to ask a boo> couple of things if its ok. boo> * Is the ME network accessible on all Intel chips or only the vPro ones boo> with AMT? IIRC there were some mobile variants which had access to the wireless 3G chip (for Anti-Theft) but AFAIK this functionality has been dropped. >From what I've seen in the common firmwares, only the corporate/AMT (5MB) >firmwares include the networking stack. boo> * I saw an interesting take on this in the link below, instead of the boo> usual FUD surrounding this topic whenever its mentioned. What is your boo> take on what he says? boo> https://www.reddit.com/r/onions/comments/5i6qa3/can_the_nsafbi_use_intel_me_to_defeat_tor_on_95/ I call FUD on the "keys being traded underground". I highly doubt that even Intel is careless enough to expose the ME signing keys in the clear. Most likely they use a HSM for signing firmwares and the actual keys never leave it. What I *could* buy (but doubt it happened) is that they may have signed some specific firmwares "on special request". In any case, the NSA etc. do not need ME to achieve their goals - there are plenty of other low-hanging fruits starting with good old phishing/social engineering and multitude of OS/application bugs. -- WBR, Igormailto:rox...@skynet.be -- coreboot mailing list: coreboot@coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Disassembly of coreboot binaries
Title: Re: [coreboot] Disassembly of coreboot binaries Hello Himanshu, Wednesday, December 14, 2016, 10:11:57 AM, you wrote: Hi, I am working on a hypvervisor and am using coreboot + FILO as guest BIOS. While things were fine a while back, it has stopped working. I see that my hypervisor can't handle address 0xFC while coreboot's RIP is at 0xfff81e41. The exact register dump of guest is as follow: [guest0/uart0] (__handle_vm_exception:558) ERROR: No region mapped to guest physical: 0xfc GUEST guest0/vcpu0 dump state: RAX: 0x9fe80 RBX: 0xf8 RCX: 0x1b RDX: 0x53a11439 R08: 0x0 R09: 0x0 R10: 0x0 R11: 0x0 R12: 0x0 R13: 0x0 R14: 0x0 R15: 0x0 RSP: 0x9fe54 RBP: 0xa RDI: 0xfff801e4 RSI: 0x9fe80 RIP: 0xfff81e41 CR0: 0xe011 CR2: 0x0 CR3: 0xa23000 CR4: 0x0 CS : Sel: 0x0008 Limit: 0x Base: 0x (G: 1 DB: 1 L: 0 AVL: 0 P: 1 DPL: 0 S: 1 Type: 11) DS : Sel: 0x0010 Limit: 0x Base: 0x (G: 1 DB: 1 L: 0 AVL: 0 P: 1 DPL: 0 S: 1 Type: 3) ES : Sel: 0x0010 Limit: 0x Base: 0x (G: 1 DB: 1 L: 0 AVL: 0 P: 1 DPL: 0 S: 1 Type: 3) SS : Sel: 0x0010 Limit: 0x Base: 0x (G: 1 DB: 1 L: 0 AVL: 0 P: 1 DPL: 0 S: 1 Type: 3) FS : Sel: 0x0010 Limit: 0x Base: 0x (G: 1 DB: 1 L: 0 AVL: 0 P: 1 DPL: 0 S: 1 Type: 3) GS : Sel: 0x0010 Limit: 0x Base: 0x (G: 1 DB: 1 L: 0 AVL: 0 P: 1 DPL: 0 S: 1 Type: 3) GDT : Sel: 0x Limit: 0x001f Base: 0xfff80200 (G: 0 DB: 0 L: 0 AVL: 0 P: 0 DPL: 0 S: 0 Type: 0) LDT : Sel: 0x Limit: 0x Base: 0x (G: 0 DB: 0 L: 0 AVL: 0 P: 0 DPL: 0 S: 0 Type: 0) IDT : Sel: 0x Limit: 0x Base: 0x (G: 0 DB: 0 L: 0 AVL: 0 P: 0 DPL: 0 S: 0 Type: 0) TR : Sel: 0x Limit: 0x Base: 0x (G: 1 DB: 0 L: 1 AVL: 1 P: 0 DPL: 0 S: 0 Type: 0) RFLAGS: 0xa [ ] I want to know which binary file (.o) should I disassemble to look at the RIP? I was looking at objdump -D -mi386 -Maddr16,data16 generated/ramstage.o but this is prior to linking and thus only has offsets. -- Regards [Himanshu Chauhan] Check the CBFS map at the end of build and the .elf files (not .o) in the build directory. -- WBR, Igor mailto:skochin...@mail.ru -- coreboot mailing list: coreboot@coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Rettungsboot
Hello Nico, Saturday, November 26, 2016, 6:42:40 PM, you wrote: NH> Hey coreboot folks, NH> here's something that's bugging me for a long time: Our lack of an out- NH> of-the-box booting experience. NH> All our payloads that don't implement legacy boot facilities (i.e. BIOS, NH> UEFI), only work in the usual case, to boot an installed OS that's con- NH> figured to work with that payload. But they stink at booting in the un- NH> usual case, e.g. from installation, rescue or live boot media. NH> One could now point a finger at the developers of those media and say, NH> they only have an MBR / UEFI boot partition, no GRUB / FILO / whatever NH> configuration file. So it's their fault? Well, I say, it's our fault! NH> We never specified how a civilized, general booting process shall look NH> like. NH> My proposal: Let's specify a fallback boot mechanism for bootloaders for NH> the case they feel lost. This would include NH> o a configuration file format (to specify a binary to load along NH> with its parameters), NH> o a search scheme for the configuration file (e.g. search the first NH> partition of each disk for `/boot/rettungsboot`), NH> o a set of supported partition table formats, NH> o a set of supported file systems, NH> o a set of binary formats that one can expect the payload to support NH> (e.g. multiboot2, multiboot, bzImage). NH> The configuration file format should be most lean and simple. We might NH> want support for multiple options (i.e. a simple menu) though. Some- NH> thing like the legacy GRUB format maybe? NH> What do you think? https://xkcd.com/927/ comes to mind immediately. What would be the incentive for the boot media creators to support yet another booting format, supported by a tiny amount of systems? Why not instead consider including a minimal subset of SeaBIOS or Tianocore (enough for booting), or maybe do a survey and try to support the most common variations of grub/isolinux etc used on such CDs? -- WBR, Igormailto:skochin...@mail.ru -- coreboot mailing list: coreboot@coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] Intel Braswell FSP graphics init
Hi Andreas, Tuesday, November 8, 2016, 9:07:43 PM, you wrote: AG> On 08.11.2016 20:04, Aaron Durbin via coreboot wrote: >> You'll need a debug version of FSP so that you can see the serial >> messages it spits out as to why things are failing. Talk to Intel to >> get help as that's about the best you can do with FSP at this point. >> You are passing things in but not getting the result you desire. AG> I really doubt they will give this to me as a private person without AG> being affiliated to a company which buys stuff from them and signs NDAs. AG> I don't even have a contact point. I'm curious, how come you have "engineer of the board" but not a contact at Intel? -- WBR, Igormailto:skochin...@mail.ru -- coreboot mailing list: coreboot@coreboot.org https://www.coreboot.org/mailman/listinfo/coreboot
Re: [coreboot] More experiments with disabling the ME
Hi Nicola, Nice work! I would like to add some comments inline. Friday, November 4, 2016, 10:20:24 PM, you wrote: NC> * Sandy Bridge boots successfully without a good FPT (but with a valid FTPR), NC> so it probably has a "backup" on-chip FPT. The system boots fine and doesn't NC> power itself off after 30 minutes, even if the cbmem entry "ME: FW NC> Partition Table" has the value "BAD" (that, we suppose, means: "I found a NC> broken partition table, I'm using the fallback one"). AFAIK there is no "backup FPT", there is just the internal boot ROM which tries to load the main fimware from the ME region and fails if FPT is bad/missing. On failure, it does set the FW status registers which are visible on the host side in the PCI device config space, which is how you can see the "FPT bad" bit and the boot phase. I think it just happens that on this platform the boot rom does just enough hw initialization for the rest of the boot to work, even without the BUP and all other code. Incidentally, I believe that FTPR stands for "Factory partition (&recovery)" and contains the minimal modules required for the successful boot of the host and firmware update process (during firmware update, the FTPR is updated last, so that the system can still boot if the update fails at any earlier stage). NC> * According to Trammell Hudson's tests, this behaviour is the same in Ivy NC> Bridge (the thread's subject says "Sandy Bridge" but his cbmem confirms that NC> his device is actually an Ivy Bridge) NC> * Nehalem (on our X201) seems to lack a "backup" on-chip FPT, as removing the NC> FPT partition bricks the device. NC> Moreover using an ME image with just FPT and FTPR results in a brick, NC> Nehalem probably needs more parts of the blob than just FPT and FTPR. NC> Unfortunately our X201 is in a bad state and its flash is about to die, so NC> we can't test further on Nehalem. NC> * We couldn't remove in any way the FTPR partition on Sandy Bridge: setting the NC> entries number to 0, the UMA size to 0 MB, creating an invalid FPT with a NC> bad checksum or creating a "fake" FTPR entry which points to an empty region NC> leads to a bricked device. Apparently, no matter which trick is used, if ME NC> can't find the FTPR partition it refuses to boot. NC> We didn't try with a 0-sized partition, but the result is probably the same. NC> * Probably the UMA size can be reduced from the "stock" 16 MB or 32 MB to few NC> MB, we'll investigate on this. NC> NC> * Shrinking the "reduced" ME partition in IFD to the minimum size allowed (FTPR NC> offset + FTPR size + 4 kB alignment) bricks the device too (but we're not NC> sure about this, maybe we made a mistake during the image creation). You can try using Intel's Flash Image Tool to construct the flash image from the ME and BIOS regions and see if it makes a different IFD. NC> * Relocating the FTPR image doesn't work, even if the FPT entry points to the NC> new location. This is probably due to the Huffman-compressed modules, which use a table of offsets to compressed chunks and those offsets are from the start of the ME region. This table will need to be relocated too. For more info, see references to "LUT" in unhuffme[1] source code. NC> * We haven't understood yet how to remove the unneeded modules from the FTPR NC> partition, any help is appreciated. You can't do that as the whole partition header ("manifest") is protected by the RSA signature, including the module table. I've just uploaded to my github[2] a script (me_sigcheck.py) which allows to check the validity of the signature, so you can try various modifications yourself. NC> * The cbmem's ME entries NC> * ME: Current Working State : Normal / Recovery NC> * ME: Bringup Loader Failure : YES / NO NC> * ME: Progress Phase : ROM Phase / BUP Phase NC> seem to be interesting, and should be studied further. It seems "Recovery" in your case may be caused by the missing MFS partition (MFS failure : 0x1). What you can try is to copy a clean MFS partition from a non-initialized ME image[3] - this way it will pass the check and maybe not go into the recovery. It may then be possible to shrink the MFS partition to a minimal size to gain more space. [1] https://io.netgarage.org/me/ [2] https://github.com/skochinsky/me-tools [3] http://www.win-raid.com/t1658f39-Guide-Clean-the-Engine-Initialized-DATA-section-of-a-SPI-dump.html NC> Attached you can find the script we used to "clean" the ME images, the cbmem log NC> of an untouched ME image (the 2.1 MB firmware extracted from a Acer Chromebook NC> C710) and the cbmem log of the same image after executing the script on it NC> (therefore with just the FPT with a single entry and the FTPR). NC> Some help testing the further options would be nice, in particular on the NC> Nehalem architecture. NC> Be careful: messing with ME may cause a hard b