In my Coreboot build I provide both VBIOS and VBT blobs via appropriate configuration items. The VBIOS blob contains expected signature at the top and VBT is valid as confirmed by running intelvbttool against it. The platform is slightly modified kblrvp (RVP3). During the build I can see cbfstool reporting that both blobs were placed in the image: To see the image's read-only sections as well, rerun with the -w option. CBFSPRINT coreboot.rom Name Offset Type Size Comp cbfs master header 0x0 cbfs header 32 none fallback/romstage 0x80 stage 41372 none cpu_microcode_blob.bin 0xa280 microcode 98304 none fallback/ramstage 0x22300 stage 90199 none config 0x383c0 raw 1302 none revision 0x38940 raw 612 none spd.bin 0x38c00 spd 2048 none --> vbt.bin 0x39440 raw 1168 LZMA (4608 decompressed) cmos_layout.bin 0x39940 cmos_layout 904 none (empty) 0x39d00 null 664 none fspm.bin 0x39fc0 fsp 401408 none (empty) 0x9c000 null 3992 none fsps.bin 0x9cfc0 fsp 188416 none --> pci8086,591e.rom 0xcb000 optionrom 65536 none fallback/postcar 0xdb080 stage 16512 none fallback/dsdt.aml 0xdf140 raw 19077 none fallback/payload 0xe3c40 simple elf 1166029 none (empty) 0x200780 null 997400 none bootblock 0x2f3fc0 bootblock 49152 none However, once the system boots, the VBIOS is not found at address 0xc0000 and VBT cannot be located either. I need VBT to be accessible in order to specify the DP connector configuration for eDP. Suggestions are appreciated
Hello Alex, On 16.02.19 18:39, Alex Feinman wrote:
In my Coreboot build I provide both VBIOS and VBT blobs via appropriate configuration items. The VBIOS blob contains expected signature at the top and VBT is valid as confirmed by running intelvbttool against it. The platform is slightly modified kblrvp (RVP3).
AIUI, you only need the VBT. If you are not going to run the VBIOS, you don't need that one.
During the build I can see cbfstool reporting that both blobs were placed in the image: To see the image's read-only sections as well, rerun with the -w option.
However, once the system boots, the VBIOS is not found at address 0xc0000
You'd have to tell coreboot or a payload to load the VBIOS. AFAIK, coreboot only does it when you also tell it to use it for gfx init (`VGA_ROM_RUN`).
and VBT cannot be located either. I need VBT to be accessible in order to specify the DP connector configuration for eDP. Suggestions are appreciated
Maybe check the coreboot console for clues. For instance there should be a line "ACPI: * IGD OpRegion" telling us that an OpRegion is set up that points to the VBT. If that doesn't happen, one possible cause is that your processors SKU isn't listed here: `src/soc/intel/common/block/graphics/graphics.c:108`. There is no reliable public source for these IDs. So it's hard to tell if the list is comprehensive. In any case, please report back. If you can't find a solution, please point to the exact code you are using and attach your `.config` file. Nico
Nico, thank you. I got it to work after enabling the VGA ROM (instead of the GOP driver) and, on advise of a colleague, changing the PCI ID in the VBIOS header from 8086:0406 to the one matching my hardware. Now I see the 0xc0000 segment and intelvbttool can decode VBT. However there is a remaining issue - the video on boot is not present and only comes up when Linux boots. I feel like I need the GOP driver after all. Best regards Alex From: Nico Huber <nico.h@gmx.de> Sent: Saturday, February 16, 2019 11:05 AM To: Alex Feinman; coreboot@coreboot.org Subject: Re: [coreboot] VBIOS/VBT in Coreboot Hello Alex, On 16.02.19 18:39, Alex Feinman wrote:
In my Coreboot build I provide both VBIOS and VBT blobs via appropriate configuration items. The VBIOS blob contains expected signature at the top and VBT is valid as confirmed by running intelvbttool against it. The platform is slightly modified kblrvp (RVP3).
AIUI, you only need the VBT. If you are not going to run the VBIOS, you don't need that one.
During the build I can see cbfstool reporting that both blobs were placed in the image: To see the image's read-only sections as well, rerun with the -w option.
However, once the system boots, the VBIOS is not found at address 0xc0000
You'd have to tell coreboot or a payload to load the VBIOS. AFAIK, coreboot only does it when you also tell it to use it for gfx init (`VGA_ROM_RUN`).
and VBT cannot be located either. I need VBT to be accessible in order to specify the DP connector configuration for eDP. Suggestions are appreciated
Maybe check the coreboot console for clues. For instance there should be a line "ACPI: * IGD OpRegion" telling us that an OpRegion is set up that points to the VBT. If that doesn't happen, one possible cause is that your processors SKU isn't listed here: `src/soc/intel/common/block/graphics/graphics.c:108`. There is no reliable public source for these IDs. So it's hard to tell if the list is comprehensive. In any case, please report back. If you can't find a solution, please point to the exact code you are using and attach your `.config` file. Nico
what payload is being used here? If SeaBIOS, you'd ideally want SeaBIOS to run the VGA BIOS, not coreboot (in which case, only the oprom name in cbfs needs to match the PCI ID, not the one in the VBIOS header - only coreboot checks that). You'd set coreboot's display init to none, and simply include the VBIOS and set the PCI ID to match. That's what I'm doing here for the Purism Librem 13v4/15v4 boards (which are loosely RVP3-based). Might not hurt to do a 'make savedefconfig' and reply with the contents of defconfig (stripping your board's make/model if needed) On Mon, Feb 18, 2019 at 11:08 PM Alex Feinman <alexfeinman@hotmail.com> wrote:
Nico, thank you.
I got it to work after enabling the VGA ROM (instead of the GOP driver) and, on advise of a colleague, changing the PCI ID in the VBIOS header from 8086:0406 to the one matching my hardware. Now I see the 0xc0000 segment and intelvbttool can decode VBT. However there is a remaining issue - the video on boot is not present and only comes up when Linux boots. I feel like I need the GOP driver after all.
Best regards Alex
From: Nico Huber <nico.h@gmx.de> Sent: Saturday, February 16, 2019 11:05 AM To: Alex Feinman; coreboot@coreboot.org Subject: Re: [coreboot] VBIOS/VBT in Coreboot
Hello Alex,
On 16.02.19 18:39, Alex Feinman wrote:
In my Coreboot build I provide both VBIOS and VBT blobs via appropriate configuration items. The VBIOS blob contains expected signature at the top and VBT is valid as confirmed by running intelvbttool against it. The platform is slightly modified kblrvp (RVP3).
AIUI, you only need the VBT. If you are not going to run the VBIOS, you don't need that one.
During the build I can see cbfstool reporting that both blobs were placed in the image: To see the image's read-only sections as well, rerun with the -w option.
However, once the system boots, the VBIOS is not found at address 0xc0000
You'd have to tell coreboot or a payload to load the VBIOS. AFAIK, coreboot only does it when you also tell it to use it for gfx init (`VGA_ROM_RUN`).
and VBT cannot be located either. I need VBT to be accessible in order to specify the DP connector configuration for eDP. Suggestions are appreciated
Maybe check the coreboot console for clues. For instance there should be a line "ACPI: * IGD OpRegion" telling us that an OpRegion is set up that points to the VBT.
If that doesn't happen, one possible cause is that your processors SKU isn't listed here: `src/soc/intel/common/block/graphics/graphics.c:108`. There is no reliable public source for these IDs. So it's hard to tell if the list is comprehensive.
In any case, please report back. If you can't find a solution, please point to the exact code you are using and attach your `.config` file.
Nico _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
I am using Tianocore payload because I require UEFI support. PCI ID for the option ROM is set to 8086:591e (KBL-Y) config file is attached From: Matt DeVillier <matt.devillier@gmail.com> Sent: Monday, February 18, 2019 10:10 PM To: Alex Feinman Cc: Nico Huber; coreboot@coreboot.org Subject: Re: [coreboot] Re: VBIOS/VBT in Coreboot what payload is being used here? If SeaBIOS, you'd ideally want SeaBIOS to run the VGA BIOS, not coreboot (in which case, only the oprom name in cbfs needs to match the PCI ID, not the one in the VBIOS header - only coreboot checks that). You'd set coreboot's display init to none, and simply include the VBIOS and set the PCI ID to match. That's what I'm doing here for the Purism Librem 13v4/15v4 boards (which are loosely RVP3-based). Might not hurt to do a 'make savedefconfig' and reply with the contents of defconfig (stripping your board's make/model if needed) On Mon, Feb 18, 2019 at 11:08 PM Alex Feinman <alexfeinman@hotmail.com> wrote: Nico, thank you. I got it to work after enabling the VGA ROM (instead of the GOP driver) and, on advise of a colleague, changing the PCI ID in the VBIOS header from 8086:0406 to the one matching my hardware. Now I see the 0xc0000 segment and intelvbttool can decode VBT. However there is a remaining issue - the video on boot is not present and only comes up when Linux boots. I feel like I need the GOP driver after all. Best regards Alex From: Nico Huber <nico.h@gmx.de> Sent: Saturday, February 16, 2019 11:05 AM To: Alex Feinman; coreboot@coreboot.org Subject: Re: [coreboot] VBIOS/VBT in Coreboot Hello Alex, On 16.02.19 18:39, Alex Feinman wrote:
In my Coreboot build I provide both VBIOS and VBT blobs via appropriate configuration items. The VBIOS blob contains expected signature at the top and VBT is valid as confirmed by running intelvbttool against it. The platform is slightly modified kblrvp (RVP3).
AIUI, you only need the VBT. If you are not going to run the VBIOS, you don't need that one.
During the build I can see cbfstool reporting that both blobs were placed in the image: To see the image's read-only sections as well, rerun with the -w option.
However, once the system boots, the VBIOS is not found at address 0xc0000
You'd have to tell coreboot or a payload to load the VBIOS. AFAIK, coreboot only does it when you also tell it to use it for gfx init (`VGA_ROM_RUN`).
and VBT cannot be located either. I need VBT to be accessible in order to specify the DP connector configuration for eDP. Suggestions are appreciated
Maybe check the coreboot console for clues. For instance there should be a line "ACPI: * IGD OpRegion" telling us that an OpRegion is set up that points to the VBT. If that doesn't happen, one possible cause is that your processors SKU isn't listed here: `src/soc/intel/common/block/graphics/graphics.c:108`. There is no reliable public source for these IDs. So it's hard to tell if the list is comprehensive. In any case, please report back. If you can't find a solution, please point to the exact code you are using and attach your `.config` file. Nico _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
since you're using Tianocore, you'll need to set a VESA/hi-res framebuffer; VGA text mode doesn't work IIRC. You can set that under the Display options, but a better option than using/running a VBIOS would be to use the FSP/GOP init, since it automatically sets a hi-res framebuffer (usually equal to the panel native resolution). But it seems you were having trouble with that before? On Tue, Feb 19, 2019 at 8:33 AM Alex Feinman <alexfeinman@hotmail.com> wrote:
I am using Tianocore payload because I require UEFI support. PCI ID for the option ROM is set to 8086:591e (KBL-Y) config file is attached
From: Matt DeVillier <matt.devillier@gmail.com> Sent: Monday, February 18, 2019 10:10 PM To: Alex Feinman Cc: Nico Huber; coreboot@coreboot.org Subject: Re: [coreboot] Re: VBIOS/VBT in Coreboot
what payload is being used here? If SeaBIOS, you'd ideally want SeaBIOS to run the VGA BIOS, not coreboot (in which case, only the oprom name in cbfs needs to match the PCI ID, not the one in the VBIOS header - only coreboot checks that). You'd set coreboot's display init to none, and simply include the VBIOS and set the PCI ID to match. That's what I'm doing here for the Purism Librem 13v4/15v4 boards (which are loosely RVP3-based). Might not hurt to do a 'make savedefconfig' and reply with the contents of defconfig (stripping your board's make/model if needed)
On Mon, Feb 18, 2019 at 11:08 PM Alex Feinman <alexfeinman@hotmail.com> wrote:
Nico, thank you.
I got it to work after enabling the VGA ROM (instead of the GOP driver) and, on advise of a colleague, changing the PCI ID in the VBIOS header from 8086:0406 to the one matching my hardware. Now I see the 0xc0000 segment and intelvbttool can decode VBT. However there is a remaining issue - the video on boot is not present and only comes up when Linux boots. I feel like I need the GOP driver after all.
Best regards Alex
From: Nico Huber <nico.h@gmx.de> Sent: Saturday, February 16, 2019 11:05 AM To: Alex Feinman; coreboot@coreboot.org Subject: Re: [coreboot] VBIOS/VBT in Coreboot
Hello Alex,
On 16.02.19 18:39, Alex Feinman wrote:
In my Coreboot build I provide both VBIOS and VBT blobs via appropriate configuration items. The VBIOS blob contains expected signature at the top and VBT is valid as confirmed by running intelvbttool against it. The platform is slightly modified kblrvp (RVP3).
AIUI, you only need the VBT. If you are not going to run the VBIOS, you don't need that one.
During the build I can see cbfstool reporting that both blobs were placed in the image: To see the image's read-only sections as well, rerun with the -w option.
However, once the system boots, the VBIOS is not found at address 0xc0000
You'd have to tell coreboot or a payload to load the VBIOS. AFAIK, coreboot only does it when you also tell it to use it for gfx init (`VGA_ROM_RUN`).
and VBT cannot be located either. I need VBT to be accessible in order to specify the DP connector configuration for eDP. Suggestions are appreciated
Maybe check the coreboot console for clues. For instance there should be a line "ACPI: * IGD OpRegion" telling us that an OpRegion is set up that points to the VBT.
If that doesn't happen, one possible cause is that your processors SKU isn't listed here: `src/soc/intel/common/block/graphics/graphics.c:108`. There is no reliable public source for these IDs. So it's hard to tell if the list is comprehensive.
In any case, please report back. If you can't find a solution, please point to the exact code you are using and attach your `.config` file.
Nico _______________________________________________ coreboot mailing list -- coreboot@coreboot.org To unsubscribe send an email to coreboot-leave@coreboot.org
I think I almost got to the bottom of it. I thought, incorrectly, that the VBT on my system is not accessible because I trusted intelvbttool from utils/ to dump it. It is outdated as it relies on VGA option ROM. If I use the intel_vbt_decode from intel-gpu-tools package (Ubuntu), I can see the VBT just fine: sudo intel_vbt_decode --file /sys/kernel/debug/dri/0/i915_vbt As for VBT - the way to set it up is to use vbt.bin (renamed to vbt.dat) and vbt.bsf with intel BMP.exe or bct tool supplied in the FSP GIT. I think it would be nice to document that intelvbttool does not work in UEFI/GOP setups (and is generally speaking obsoleted by the new utilities in the intel-gpu-tools package). Best regards Alex ________________________________________ From: Matt DeVillier <matt.devillier@gmail.com> Sent: Tuesday, February 19, 2019 2:52 PM To: Alex Feinman Cc: Nico Huber; coreboot@coreboot.org Subject: Re: [coreboot] Re: VBIOS/VBT in Coreboot since you're using Tianocore, you'll need to set a VESA/hi-res framebuffer; VGA text mode doesn't work IIRC. You can set that under the Display options, but a better option than using/running a VBIOS would be to use the FSP/GOP init, since it automatically sets a hi-res framebuffer (usually equal to the panel native resolution). But it seems you were having trouble with that before? On Tue, Feb 19, 2019 at 8:33 AM Alex Feinman <alexfeinman@hotmail.com<mailto:alexfeinman@hotmail.com>> wrote: I am using Tianocore payload because I require UEFI support. PCI ID for the option ROM is set to 8086:591e (KBL-Y) config file is attached From: Matt DeVillier <matt.devillier@gmail.com<mailto:matt.devillier@gmail.com>> Sent: Monday, February 18, 2019 10:10 PM To: Alex Feinman Cc: Nico Huber; coreboot@coreboot.org<mailto:coreboot@coreboot.org> Subject: Re: [coreboot] Re: VBIOS/VBT in Coreboot what payload is being used here? If SeaBIOS, you'd ideally want SeaBIOS to run the VGA BIOS, not coreboot (in which case, only the oprom name in cbfs needs to match the PCI ID, not the one in the VBIOS header - only coreboot checks that). You'd set coreboot's display init to none, and simply include the VBIOS and set the PCI ID to match. That's what I'm doing here for the Purism Librem 13v4/15v4 boards (which are loosely RVP3-based). Might not hurt to do a 'make savedefconfig' and reply with the contents of defconfig (stripping your board's make/model if needed) On Mon, Feb 18, 2019 at 11:08 PM Alex Feinman <alexfeinman@hotmail.com<mailto:alexfeinman@hotmail.com>> wrote: Nico, thank you. I got it to work after enabling the VGA ROM (instead of the GOP driver) and, on advise of a colleague, changing the PCI ID in the VBIOS header from 8086:0406 to the one matching my hardware. Now I see the 0xc0000 segment and intelvbttool can decode VBT. However there is a remaining issue - the video on boot is not present and only comes up when Linux boots. I feel like I need the GOP driver after all. Best regards Alex From: Nico Huber <nico.h@gmx.de<mailto:nico.h@gmx.de>> Sent: Saturday, February 16, 2019 11:05 AM To: Alex Feinman; coreboot@coreboot.org<mailto:coreboot@coreboot.org> Subject: Re: [coreboot] VBIOS/VBT in Coreboot Hello Alex, On 16.02.19 18:39, Alex Feinman wrote:
In my Coreboot build I provide both VBIOS and VBT blobs via appropriate configuration items. The VBIOS blob contains expected signature at the top and VBT is valid as confirmed by running intelvbttool against it. The platform is slightly modified kblrvp (RVP3).
AIUI, you only need the VBT. If you are not going to run the VBIOS, you don't need that one.
During the build I can see cbfstool reporting that both blobs were placed in the image: To see the image's read-only sections as well, rerun with the -w option.
However, once the system boots, the VBIOS is not found at address 0xc0000
You'd have to tell coreboot or a payload to load the VBIOS. AFAIK, coreboot only does it when you also tell it to use it for gfx init (`VGA_ROM_RUN`).
and VBT cannot be located either. I need VBT to be accessible in order to specify the DP connector configuration for eDP. Suggestions are appreciated
Maybe check the coreboot console for clues. For instance there should be a line "ACPI: * IGD OpRegion" telling us that an OpRegion is set up that points to the VBT. If that doesn't happen, one possible cause is that your processors SKU isn't listed here: `src/soc/intel/common/block/graphics/graphics.c:108`. There is no reliable public source for these IDs. So it's hard to tell if the list is comprehensive. In any case, please report back. If you can't find a solution, please point to the exact code you are using and attach your `.config` file. Nico _______________________________________________ coreboot mailing list -- coreboot@coreboot.org<mailto:coreboot@coreboot.org> To unsubscribe send an email to coreboot-leave@coreboot.org<mailto:coreboot-leave@coreboot.org>
Hi Alex, On 20.02.19 15:56, Alex Feinman wrote:
I think I almost got to the bottom of it. I thought, incorrectly, that the VBT on my system is not accessible because I trusted intelvbttool from utils/ to dump it.
ah, quite some misunderstanding. You said initially the "VBT cannot be located" and I automatically assumed your OS driver doesn't pick it up.
It is outdated as it relies on VGA option ROM.
It's not a perfect tool, but doesn't lack anything obvious. I mean a switch like `--inoprom` of course relies on an option ROM, and `--inlegacy` not working with UEFI shouldn't surprise either.
If I use the intel_vbt_decode from intel-gpu-tools package (Ubuntu), I can see the VBT just fine: sudo intel_vbt_decode --file /sys/kernel/debug/dri/0/i915_vbt
That file lies in a virtual file system which reports a size of 0, that's where intelvbttool fails. But it works generally: # cp /sys/kernel/debug/dri/0/i915_vbt /tmp/ # intelvbttool --invbt /tmp/i915_vbt --outdump Should show a dump (not a very comprehensive one).
As for VBT - the way to set it up is to use vbt.bin (renamed to vbt.dat) and vbt.bsf with intel BMP.exe or bct tool supplied in the FSP GIT.
Yes, that's the only known option to edit a VBT (beside a hex editor).
I think it would be nice to document that intelvbttool does not work in UEFI/GOP setups (and is generally speaking obsoleted by the new utilities in the intel-gpu-tools package).
It doesn't seem that black and white. The dump mode of `intelvbttool` could be dropped, I guess (I never really used it). That would make it more obvious that it's more useful for file mangling. Patches are welcome. About documentation, it would be really nice if you could write some- thing up [1]. Even if it's just one paragraph for each tool (and a reference to BMP). I guess the most precious information is the path `/sys/kernel/debug/dri/0/i915_vbt` ;) might be worth to patch that into the help text of intelvbttool (along with support to read it directly). Nico [1] We maintain documentation in the coreboot repository below `Documentation/`. https://doc.coreboot.org/getting_started/writing_documentation.html The only other page about graphics seems to be: https://doc.coreboot.org/gfx/libgfxinit.html Might be worth to group that somehow (reminds me, that page needs an update).
Sorry if that's off-topic, but by using a Tianocore payload you could be exposing yourself to the new UEFI-targeting NSA-grade malware. Of course the coreboot is more secure when paired with more traditional payloads. But I don't know about your setup, maybe the security is not your primary concern...
do you have any evidence to support that Tianocore is vulnerable to this type of malware (given that it doesn't support module injection/persistence, as implemented), or in any way less secure than a "traditional" payload? If not, then your warning strikes me as nothing more than FUD On Wed, Feb 20, 2019 at 12:22 PM Ivan Ivanov <qmastery16@gmail.com> wrote:
Sorry if that's off-topic, but by using a Tianocore payload you could be exposing yourself to the new UEFI-targeting NSA-grade malware. Of course the coreboot is more secure when paired with more traditional payloads. But I don't know about your setup, maybe the security is not your primary concern...
Tianocore, being a standard UEFI, is vulnerable to UEFI-targeting malware whose functionality is based on UEFI architecture. "Traditional" payloads are not UEFI - and therefore are not vulnerable to UEFI-targeting malware. It does not take a genius to realize that.
UEFI is a specification; exploits are necessarily against implementations thereof, not the spec itself. Tianocore is a partial reference implementation of the UEFI spec, and the package built for use with coreboot an even smaller subset of that (since it completely skips the PEI phase). So unless you can provide evidence that UEFI-targeting malware exploits specific features (or bugs) implemented in Tianocore as built for coreboot, then it's not accurate in the least to say that "UEFI malware exists, Tianocore is UEFI, so Tianocore is vulnerable to all UEFI-targeting malware." And certainly, traditional/legacy payloads not being vulnerable to UEFI-targeting malware does not make them de-facto more secure. Vulnerabilities/exploits/attack vectors, along with mitigations, etc in open source firmware is certainly a topic worth discussing. But let's base that discussion in fact, and leave out the drive-by implications of security not being a concern based on payload selection for a given use case. On Thu, Feb 21, 2019 at 12:24 AM Ivan Ivanov <qmastery16@gmail.com> wrote:
Tianocore, being a standard UEFI, is vulnerable to UEFI-targeting malware whose functionality is based on UEFI architecture. "Traditional" payloads are not UEFI - and therefore are not vulnerable to UEFI-targeting malware. It does not take a genius to realize that.
Hi Ivan, On 21.02.19 07:24, Ivan Ivanov wrote:
Tianocore, being a standard UEFI, is vulnerable to UEFI-targeting malware whose functionality is based on UEFI architecture.
can you give an example of a malware (or exploit) that targets the UEFI architecture in general (and not specific features of it that may or may not be implemented by a payload)? That would be a very valuable information to have. Nico
participants (4)
-
Alex Feinman -
Ivan Ivanov -
Matt DeVillier -
Nico Huber