[coreboot] subscribe

[Igor Skochinsky via coreboot]

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

[Igor Skochinsky via coreboot]

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

[Igor Skochinsky via coreboot]

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

[Igor Skochinsky via coreboot]

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

[Igor Skochinsky via coreboot]

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

[Igor Skochinsky via coreboot]

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

[Igor Skochinsky via coreboot]

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 ?

[Igor Skochinsky via coreboot]

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?

[Igor Skochinsky via coreboot]

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

[Igor Skochinsky via coreboot]

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

[Igor Skochinsky via coreboot]

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

[Igor Skochinsky via coreboot]

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

[Igor Skochinsky via coreboot]

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

[Igor Skochinsky via coreboot]

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

[Igor Skochinsky via coreboot]

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

[Igor Skochinsky via coreboot]

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

[Igor Skochinsky via coreboot]

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

[Igor Skochinsky via coreboot]

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

[Igor Skochinsky via coreboot]

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

[Igor Skochinsky via coreboot]

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

[Igor Skochinsky via coreboot]

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 
<coreboot@coreboot.org> 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 
<coreboot@coreboot.org> 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 <rminn...@gmail.com> 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

Re: [coreboot] VGA and Graphics

[Igor Skochinsky via coreboot]

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 
<coreboot@coreboot.org> 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 <rminn...@gmail.com> 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 <rminn...@gmail.com> 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

[Igor Skochinsky via coreboot]

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?

[Igor Skochinsky via coreboot]

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

[Igor Skochinsky via coreboot]

>Четверг,  9 февраля 2017, 12:16 +01:00 от Michal Widlok 
><michalwd1...@gmail.com>:
>
>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

[Igor Skochinsky via coreboot]

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

[Igor Skochinsky via coreboot]

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?

[Igor Skochinsky via coreboot]

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

[Igor Skochinsky via coreboot]

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

[Igor Skochinsky via coreboot]

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

[Igor Skochinsky via coreboot]

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] More experiments with disabling the ME

[Igor Skochinsky via coreboot]

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 ()"
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 brick,