[coreboot] Re: Security notice: SMM can be hijacked by the OS on APs

[Shawn C]

Nice hunt, Arthur! The attack surface in coreboot is lesser than UEFI but the 
misconfig during the setup will lead to serious issue. This one is neat and 
worth a CVE. Please use CVE-2022-29264 as record:

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2022-29264

regards
Shawn


--- Original Message ---
On Thursday, April 7th, 2022 at 10:43 PM, Arthur Heymans  
wrote:


> Hi
> When refactoring the coreboot SMM setup I noticed that there is a security 
> vulnerability in our SMM setup code.
> It boils down to this: except on the BSP the smihandler code will execute 
> code at a random location, but most likely at offset 0. With some carefully 
> crafted code a bootloader or the OS could place some code at that offset, 
> generate an SMI on an AP and get control over SMM. More recent silicon has 
> hardware mechanisms to avoid executing code outside the designated SMM area 
> (TSEG) so those would not be affected.
> The commit introducing this problem is 
> https://review.coreboot.org/c/coreboot/+/43684.
> Roughly it affects most x86 builds from end 2020/ beginning 2021 till now.
>
> https://review.coreboot.org/c/coreboot/+/63478 fixes the problem. (Feel free 
> to review the rest of that series as it makes the smm setup much more 
> readable ;-))
> Kind regards
> Arthur
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] [coreboot - Bug #351] test issue for mailing list

[Felix Singer]

Issue #351 has been updated by Felix Singer.


test 2


Bug #351: test issue for mailing list
https://ticket.coreboot.org/issues/351#change-900

* Author: Felix Singer
* Status: New
* Priority: Normal
* Target version: none
* Start date: 2022-04-25

Testing the mailing list bot for coreboot.



-- 
You have received this notification because you have either subscribed to it, 
or are involved in it.
To change your notification preferences, please click here: 
https://ticket.coreboot.org/my/account
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: Request help and Support

[rainhe...@savelife-tech.com]

Hello:
After I signed CNDA with Intel. I have got the FSP of Rocket Lake 
platform. But I don't know how to use this FSP in Coreboot.

Looking forward to your reply
Thank you very much


SAVELIFE® Technology of Yunnan Co., LTD
云南赛莱福科技有限公司
王祥福 (Rainhenry Wang)
Tel: +86-13104051251 (Voice calls only support Chinese)
E-mail: rainhe...@savelife-tech.com 
Website: www.savelife-tech.com 
 
From: Lance Zhao
Date: 2022-04-22 10:46
To: rainhe...@savelife-tech.com
CC: coreboot
Subject: Re: [coreboot] Request help and Support
https://github.com/intel/FSP
I am not sure you can use tiger lake fsp on rocket lake or not.

Regards,
Lance

rainhe...@savelife-tech.com  于2022年4月21日周四 17:55写道：
Hello:
I'm Rainhenry Wang from SAVELIFE Technology of Yunnan Co., LTD Company. 
We are currently developing a computer motherboard. 
Also want to use Coreboot to develop its BIOS firmware. It is based on Intel's 
Rocket Lake platform. The PCH model is FH82H510, 
and the spec code is SRKM2. However, I did not find Rocket Lake platform 
support code in all versions of Coreboot.
So we want to understand and learn in detail how to add the code of another 
platform into Coreboot.
I am not sure whether you have relevant learning resources or documents to 
share with us?

Looking forward to your reply.
Thank you very much.



SAVELIFE® Technology of Yunnan Co., LTD
云南赛莱福科技有限公司
王祥福 (Rainhenry Wang)
Tel: +86-13104051251 (Voice calls only support Chinese)
E-mail: rainhe...@savelife-tech.com
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: No instructions for the Biostar AM1ML?

[Mike Banon]

Hi there Nicholas,

Recently I've provided a lot of instructions for you at Biostar AM1ML
thread on Reddit. Below, for the archival purposes, is a repost from
https://www.reddit.com/r/coreboot/comments/u4ncpe/biostar_am1ml/ :

1) Biostar AM1ML seems to have a socket'ed DIP8 chip, so it is
possible to flash just by a USB CH341A (preferably with a green PCB)
to get it done. You also need a DIP8 or PLCC extraction tool, to be
able to safely remove a DIP8 chip from a socket without bending its'
pins. In addition, maybe order a USB extension cable for convenience.
There are also DIP8 test clips, but they are expensive compared to
SOIC8 ones - and, since the chip is socket'ed - are not essential. Any
cheapest DIP8 or PLCC extraction tool from AliExpress - still should
be good enough. Usually I'm using a PLCC one even for DIP8 chips,
slightly more convenient IMHO, but you can get both considering their
dirt cheap price.

2) It's quite easy to build a coreboot for AM1ML, also because it's
AMD so you don't need to extract / use any parts of your original BIOS
(like the people often need to do for their Intels). You could follow
use the instructions at Lenovo G505S hacking page
(http://dangerousprototypes.com/docs/Lenovo_G505S_hacking) : these
not-merged-yet patches can benefit any AMD, and although I don't
provide an example config for AM1ML, you can take an example config of
AM1I-A (very similar board from the same AMD family) as the base for
your own config.

3) You don't need to change anything in this ./csb_patcher.sh script
for your AM1ML board (well, unless you'd like to help me by improving
some code ;-) ). Just use a script as-is and reply N when it asks to
apply the G505S / A88XM-E / AM1I-A configs.

coreboot uses a hidden ./coreboot/.config file as a place for storing
the configuration, and "apply" in that context - means copying a
board's example config from ./coreboot/configs/filename to
./coreboot/.config

Each of the primary patches - either does a small improvement for you,
or no improvement but no harm too: i.e. there's no IRQ improvement for
your board in "AMD good irq" (if you'd like - do a similar one by
yourself). So you could reply Y to all the other patches.

After the launch of a script, you need to somehow get a good config
for your board and put to ./coreboot/.config . To produce a good
config for your AM1ML, I propose to do the following:

*) Look at this diff
(https://github.com/mikebdp2/temp_4friend/commit/cbc0885faa9b5a338153c44ba5ec15c413089d99)
between the default AM1I-A config VS my improved version, research
about these changed options and decide by yourself if you'd like to
add any of these changes on top of your default AM1ML config. To avoid
the error-prone manual text editing, open "make menuconfig" while at
./coreboot/ directory, figure out the menu location of any particular
config by pressing / key, then go there and enable it manually.

*) Also check this diff
(https://github.com/mikebdp2/temp_4friend/commit/3ddc6cc095ce19aba007fe4e8747d3b479c74975)
between the default AM1ML config VS the latest known good AM1ML config
which has been "refreshed" by putting it into the coreboot directory,
running "make menuconfig" and saving the changes (some config options
appear, some disappear, etc.) and also review it.

In addition, for the working integrated graphics, you will need to get
the AtomBIOS blob. I provide some of these blobs by one of the
unofficial patches installed by a script above -
https://review.coreboot.org/c/coreboot/+/58748 - including
pci1002,9830.rom for the iGPU of Athlon 5370 on AM1I-A; but this
top-of-the-line CPU for AM1 socket is rare (many people only have
5350) and I don't know if "extracted_on_AM1I-A" AtomBIOS will be
compatible for your board since it may have different internal
configuration values. To get your own AtomBIOS, first of all update
your UEFI to the latest version - so that AtomBIOS may be also fresher
- and I recommend you to use a "Retrieval via Linux kernel" method;
there's also a more advanced "Ultimate" method described at my post
here (https://mail.coreboot.org/pipermail/coreboot/2017-July/084660.html)
but it's more time consuming and I hope you won't need it.

After getting the AtomBIOS rom, rename it to pci,.rom where
 and  are PCI vendor ID / device ID of your iGPU (could be
found with lspci -vvvnn), put to your ./coreboot/ directory and choose
the CONFIG_VGA_BIOS_ID="," ,
CONFIG_VGA_BIOS_FILE="pci,.rom" in your config.

Then you could go ahead, build your coreboot, and maybe run
"./csb_patcher.sh flop" if you'd like to add some awesome floppy-based
OS which will be available as the SeaBIOS boot entries.

Advanced:

To improve the irqs for your AMD board, you may look at the source
code improvements I did for g505s / a88xm-e / am1i-a boards, and try
to do something similar for your am1ml by trial and error. Although
the sophisticated OS like Linux works fine even with the "bad irq
routing" (unless it 

[coreboot] Re: [RFC] i945 problematic code for IGD device enable, BUG?

[Angel Pons]

Hi Petr,

On Sun, Apr 24, 2022 at 7:33 AM Petr Cvek  wrote:
>
> Hello again :-D,
>
> I'm working on a code for a simultaneous use of IGD (GMA950) and x16 PCIe 
> slot GPU. I've made some success, but the code which handles the IGD 
> initialization is really weird.

If your PCIe device is a graphics card, you could try removing this
condition in early_init.c:

if (reg32 == 0x03) {
printk(BIOS_DEBUG, "PCIe device is VGA. Disabling IGD.\n");
reg16 = (1 << 1);
pci_write_config16(HOST_BRIDGE, GGC, reg16);

pci_and_config32(HOST_BRIDGE, DEVEN, ~(DEVEN_D2F0 | DEVEN_D2F1));
}

> The IGD is initialized by DEVEN register (DEVEN_D2F0 and DEVEN_D2F1 bits), 
> which is first written in i945_setup_pci_express_x16(). Few times before that 
> the DEVEN_D2F0 and DEVEN_D2F1 bits are already tested during 
> sdram_initialize() code. Also after the reset these bits are initialized to 
> 1. This will cause the test from:
>
> https://elixir.bootlin.com/coreboot/4.16/source/src/northbridge/intel/i945/raminit.c#L2127
>
> if (!(pci_read_config8(HOST_BRIDGE, DEVEN) & (DEVEN_D2F0 | 
> DEVEN_D2F1)))
> integrated_graphics = false;
>
> to be effectively always -> if (0)

Well, there are i945 versions without integrated graphics (82945P,
82945PL, 82945PM). I haven't tested it, but I'm pretty sure the
DEVEN_D2F0 and DEVEN_D2F1 bits are always zero on these northbridges.

> also even when DEVEN_D2F0 is zeroed after chipset reset, the code located 
> after a few lines:
>
> https://elixir.bootlin.com/coreboot/4.16/source/src/northbridge/intel/i945/raminit.c#L2270
>
> pci_or_config8(IGD_DEV, 0xc1, 1 << 2);
>
> will have a problem to work correctly. IGD_DEV is PCIe device enabled by 
> DEVEN_D2F0 (setting DEVEN_D2F0 to 0 will remove IGD_DEV from the PCIe bus). 
> It seems to not cause problems, but I didn't test it extensively.

This write has no effect if IGD_DEV is disabled by DEVEN. Looks like
this magic 0xc1 register is called UPMC4, but it's undocumented.

> Also the test in northbridge_get_tseg_base() (used everytime top of the 
> memory is needed):
>
> https://elixir.bootlin.com/coreboot/4.16/source/src/northbridge/intel/i945/memmap.c#L39
>
> if (pci_read_config8(HOST_BRIDGE, DEVEN) & (DEVEN_D2F0 | DEVEN_D2F1))
> /* IGD enabled, get top of Memory from BSM register */
> tom = pci_read_config32(IGD_DEV, BSM);
>
> If only DEVEN_D2F1 is enabled, the test will succeed, but as the IGD_DEV is 
> now disabled by DEVEN_D2F0 it will read garbage data for the global "top of 
> the memory" value.

Having D2F1 enabled without D2F0 being enabled is not allowed by the
PCI specification. Function 0 of multi-function devices must always be
implemented.

> I've sort of solved the missing initialization problem with CMOS config entry 
> in mainboard_romstage_entry():
>
> switch (get_uint_option("igd_en", 1)) {
> case 0:
> //disable
> pci_and_config32(HOST_BRIDGE, DEVEN, ~(DEVEN_D2F0 | 
> DEVEN_D2F1));
> break;
> case 2:
> //enable func0 only ??? TEST
> pci_update_config16(HOST_BRIDGE, DEVEN, 
> ~(DEVEN_D2F1), DEVEN_D2F0);
> break;
> case 1:
> default:
> //enabled both
> pci_or_config32(HOST_BRIDGE, DEVEN, DEVEN_D2F0 | 
> DEVEN_D2F1);
> break;
> }
>
> sdram_initialize( ...
>
> RFC:
>
> Is this approach OK? Of course the patch will need to cover the if (0) tests 
> and skip access to missing PCI devices. Does anybody know if GCFC (Graphics 
> Clock Frequency Control) register (i945 datasheet, section 8.1.35, page 296) 
> needs to be explicitly disabled when IGD PCIe access is disabled by DEVEN 
> bits or do I need to enable IGD PCIe access with DEVEN, disable clocks in 
> GCFC and then disable IGD PCIe access again with DEVEN bits?

Unless you need to disable cdclk and crclk (the two graphics clocks
controlled by GCFC, as I see in the document number 309219-006) for
some reason, I wouldn't worry too much about the GCFC details. Your
approach looks reasonable, I'd remove the "func0 only" case for
simplicity. I think the existing code should be able to handle this
properly.

> Similar to GCFC settings without enabled IGD PCIe access. There are many 
> registers in affected code, which doesn't have a name/description in the i945 
> datasheet. Does anybody know their function? It could help to determine if 
> they needs to be set even when IGD will be disabled.

Ah yes, the magic registers. They're not publicly documented (I think
the i945 code was initially written based on information in
confidential documents), and I'm not sure if anyone still has access
to that information.

> Best regards,
> Petr
> 

[coreboot] Re: Can coreboot run on a Dell Wyse 3290 or 3030?

[Angel Pons]

Hi,

On Sat, Apr 23, 2022 at 11:37 AM Peter Stuge  wrote:
>
> Martin Butt wrote:
> > Do you know if Coreboot would work on either of these systems?
> ..
> > Both the 3290 and the 3030 CPUs are a Intel Celeron N2807 1.58GHz
>
> That's the CPU marketing name which in firmware like coreboot doesn't
> mean much. What matters is that this is a Bay Trail platform.

Yes, it's a Bay Trail platform.

> > From a visual inspection, the only difference between the boards of the two
> > models is that the BIOS chip is different. The 3029 is a Winbond 25Q64FVSIG
> > (or a 25Q64FWSIG, the chip is hard to read). The 3030 is a Macronix
> > MX25U6435F.
>
> The 25Q64 chip is unproblematic. flashrom mentiones an OTP region in
> the MX chip, I would investigate if and how that is being used, if
> the OTP lies within the 8 Mbyte then that could be a problem and
> you'd have to replace the chip by soldering.

I've never seen the OTP being used in any x86 systems. Note that these
SPI flash chips run at 1.8V, not the usual 3.3V that most programmers
provide.

> (If you need to replace a chip: cut its pins flush with the black
> package so that you can first remove the package and then use a
> soldering iron to remove one pin at a time. Clean the pads with
> solder wick and then solder a new chip in.)
>
> > flashrom v1.2 on Linux 5.13.0-30-generic (x86_64)
> ..
> > Found chipset "Intel Bay Trail" with PCI ID 8086:0f1c.
>
> I know that coreboot *has* had *some* support for Bay Trail, IIRC
> the minnowmax board, IIRC that was the very first attempt at using
> Intel's FSP blob in coreboot and I think it did work but it wasn't
> a great success. You'd have to investigate.

Support for the Bay Trail FSP was dropped from coreboot after the 4.11
release because it's impossible to implement the postcar stage with
FSP 1.0 (see 4.12 release notes). However, coreboot still has Bay
Trail support using the MRC.bin blob from Chromebooks (the refcode.elf
blob used to be required as well, but it was reimplemented as native
coreboot code). You can use `mainboard/bostentech/gbyt4` as an example
coreboot port for a Bay Trail board.

> Kind regards
>
> //Peter
> ___
> coreboot mailing list -- coreboot@coreboot.org
> To unsubscribe send an email to coreboot-le...@coreboot.org

Best regards,
Angel
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: [BUG] nb/intel/i945: smm_subregion() prints assert when it should not

[Petr Cvek]

OK thanks for info

Petr

Dne 25. 04. 22 v 8:30 Arthur Heymans napsal(a):
> Hi
> 
> 2M TSEG is hardcoded in nb/intel/i945/early_init.c so it should never have an 
> 8M value.
> 
> --
> Arthur
> 
> On Mon, Apr 25, 2022 at 8:22 AM Petr Cvek  > wrote:
> 
> Dne 25. 04. 22 v 7:51 Arthur Heymans napsal(a):
> > 4MB IGD stolen memory is fine for 2M alignment on TSEG, so only 
> dropping 1M would be needed.
> 
> Yeah but TSEG can have 8MB and will require 8MB alignment (however I 
> don't know if this setting is used in coreboot).
> 
> Petr
> 
> > Also that value goes up to 64MB, not 8M, but it's not documented in the 
> official documentation.
> >
> > Kind regards,
> > Arthur
> >
> > On Sun, Apr 24, 2022 at 11:54 PM Petr Cvek    >> wrote:
> >
> >     Thanks! I would never find the SMRR feature.
> >
> >     Hmm that means 4MB stolen memory should be dropped along 1MB (TSEG 
> can up to 8MB on i945). Or alternatively to check if TSEG >= UMA in cmos 
> configuration. I suppose cmos.layout would need to support some kind of 
> scripting though.
> >
> >     Petr
> >
> >     Dne 24. 04. 22 v 18:56 Arthur Heymans napsal(a):
> >     > Hi
> >     >
> >     > You want to align tseg for when smrr is supported by the CPU. I 
> would just drop support for 1MB stolen memory.
> >     >
> >     > Arthur
> >     >
> >     > On Sun, 24 Apr 2022, 05:40 Petr Cvek,    >     >     >
> >     >     Hello,
> >     >
> >     >     On i945 northbridge:
> >     >
> >     >             ASSERTION ERROR: file 
> 'src/cpu/x86/smm/tseg_region.c', line 31
> >     >
> >     >     can be triggered by some configurations. The assert
> >     >
> >     >             ASSERT(IS_ALIGNED(sub_base, sub_size));
> >     >
> >     >     tests alignment of SMM base with SMM size. The problem is 
> that IGD stolen memory can offset the SMM base by a smaller size than the SMM 
> size. This causes SMM base to be unaligned. For example:
> >     >
> >     >     8000: 2 GiB Top of RAM, stored in TOLUD
> >     >     7ff0: 1 MiB Stolen IGD RAM base, address in BSM
> >     >     7fd0: 2 MiB SMM base, defined as SMM size in ESMRAMC
> >     >
> >     >     -> 0x7fd0 is not aligned to SMM size. Probably works for 
> different settings too.
> >     >
> >     >     RFC: should the assert from
> >     >
> >     >             
> https://elixir.bootlin.com/coreboot/4.16/source/src/cpu/x86/smm/tseg_region.c#L31
>  
> 
>  
>   
> >
>  
>   
> 
>  
>   
> >>
> >     >
> >     >     be removed, changed or ignored on i945? The correct test 
> should be probably for 1 MiB alignement as the base of stolen IGD memory have 
> [31:20] bits. But I understand the smm_subregion() test is a generic one.
> >     >
> >     >     regards,
> >     >     Petr
> >     >     ___
> >     >     coreboot mailing list -- coreboot@coreboot.org 
>   >    >>
> >     >     To unsubscribe send an email to coreboot-le...@coreboot.org 
>   >    >>
> >     >
> >
> 
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: [BUG] nb/intel/i945: smm_subregion() prints assert when it should not

[Petr Cvek]

Dne 25. 04. 22 v 7:51 Arthur Heymans napsal(a):
> 4MB IGD stolen memory is fine for 2M alignment on TSEG, so only dropping 1M 
> would be needed.

Yeah but TSEG can have 8MB and will require 8MB alignment (however I don't know 
if this setting is used in coreboot).

Petr

> Also that value goes up to 64MB, not 8M, but it's not documented in the 
> official documentation.
> 
> Kind regards,
> Arthur
> 
> On Sun, Apr 24, 2022 at 11:54 PM Petr Cvek  > wrote:
> 
> Thanks! I would never find the SMRR feature.
> 
> Hmm that means 4MB stolen memory should be dropped along 1MB (TSEG can up 
> to 8MB on i945). Or alternatively to check if TSEG >= UMA in cmos 
> configuration. I suppose cmos.layout would need to support some kind of 
> scripting though.
> 
> Petr
> 
> Dne 24. 04. 22 v 18:56 Arthur Heymans napsal(a):
> > Hi
> >
> > You want to align tseg for when smrr is supported by the CPU. I would 
> just drop support for 1MB stolen memory.
> >
> > Arthur
> >
> > On Sun, 24 Apr 2022, 05:40 Petr Cvek,    >> wrote:
> >
> >     Hello,
> >
> >     On i945 northbridge:
> >
> >             ASSERTION ERROR: file 'src/cpu/x86/smm/tseg_region.c', line 
> 31
> >
> >     can be triggered by some configurations. The assert
> >
> >             ASSERT(IS_ALIGNED(sub_base, sub_size));
> >
> >     tests alignment of SMM base with SMM size. The problem is that IGD 
> stolen memory can offset the SMM base by a smaller size than the SMM size. 
> This causes SMM base to be unaligned. For example:
> >
> >     8000: 2 GiB Top of RAM, stored in TOLUD
> >     7ff0: 1 MiB Stolen IGD RAM base, address in BSM
> >     7fd0: 2 MiB SMM base, defined as SMM size in ESMRAMC
> >
> >     -> 0x7fd0 is not aligned to SMM size. Probably works for 
> different settings too.
> >
> >     RFC: should the assert from
> >
> >             
> https://elixir.bootlin.com/coreboot/4.16/source/src/cpu/x86/smm/tseg_region.c#L31
>  
> 
>  
>   
> >
> >
> >     be removed, changed or ignored on i945? The correct test should be 
> probably for 1 MiB alignement as the base of stolen IGD memory have [31:20] 
> bits. But I understand the smm_subregion() test is a generic one.
> >
> >     regards,
> >     Petr
> >     ___
> >     coreboot mailing list -- coreboot@coreboot.org 
>   >
> >     To unsubscribe send an email to coreboot-le...@coreboot.org 
>   >
> >
> 
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org