[coreboot] New Defects reported by Coverity Scan for coreboot

[scan-admin--- via coreboot]

Hi,

Please find the latest report on new defect(s) introduced to coreboot found 
with Coverity Scan.

1 new defect(s) introduced to coreboot found with Coverity Scan.


New defect(s) Reported-by: Coverity Scan
Showing 1 of 1 defect(s)


** CID 1419483:  Memory - corruptions  (OVERRUN)
/src/vendorcode/eltan/security/verified_boot/vboot_check.c: 85 in 
verified_boot_check_manifest()



*** CID 1419483:  Memory - corruptions  (OVERRUN)
/src/vendorcode/eltan/security/verified_boot/vboot_check.c: 85 in 
verified_boot_check_manifest()
79  pre->body_signature.data_size = 
CONFIG_VENDORCODE_ELTAN_OEM_MANIFEST_ITEMS *
80  DIGEST_SIZE;
81  pre->body_signature.sig_offset = sizeof(struct vb2_signature) +
82   pre->body_signature.data_size;
83  pre->body_signature.sig_size = size - pre->body_signature.data_size;
84  sd->workbuf_used += size;
>>> CID 1419483:  Memory - corruptions  (OVERRUN)
>>> Overrunning struct type vb2_signature of 24 bytes by passing it to a 
>>> function which accesses it at byte offset 663 using argument "size" (which 
>>> evaluates to 640). [Note: The source code implementation of the function 
>>> has been overridden by a builtin model.]
85  memcpy((void *)((void *)>body_signature + (long)sizeof(struct 
vb2_signature)),
86 (uint8_t *)CONFIG_VENDORCODE_ELTAN_OEM_MANIFEST_LOC, size);
87 
88 
89  if (vb2api_verify_kernel_data(ctx, (void 
*)CONFIG_VENDORCODE_ELTAN_OEM_MANIFEST_LOC,
90pre->body_signature.data_size))



To view the defects in Coverity Scan visit, 
https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P0qcxCbhZ31OYv50yq2SfQfrHt3Prsn4qSLrYIrajINpiFX8l0vrlNSf8iCrS27qY0Cr0DkycwNUgGZJj8-3DyVzL_L-2FDzr14mnrsJO5b1wX1hp9b1MAQygl7x-2B74RAaH2cn3nqY8HPK8e8YVnMZGxbWG1aaGWeSLFNzNVrgknn3sEILlxra1kp3dSPq8hliQIYiDW-2Fu0CRw79mUGAvlXGa3EJU0ys-2FHQpqcZJbPIwqdiZa053TDQD0ZFtyIRZebHPH5aKI0UXhbNzjGHTOd6dE6LeQixZNgN9hq7bphaxwnf-2Fy2sNVrLw9Fv-2BFkNdGqHihsY-3D
___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Open Source Firmware and Bootloader devroom CFP

[Michał Żygowski]

Hi,


The Open Source Firmware, BMC and Bootloader devroom will take place

on Sunday, 7th February 2021 at FOSDEM, virtual.


Call for Participation

--

We are opening the call for participation to our devroom, with the deadline

for talk proposals set to Sunday, 20th December 2020 23:59:59 UTC.


Devroom Scope

-

The devroom will focus on various topics related to the open source
firmware,

BMC and bootloaders including security issues. It will help to get together

all interested people in one place, present and discuss current developments

and issues haunting the community. Additionally, it will foster awareness

among attendees about pre-OS topics.


Possible topics: GRUB, TrustedGRUB, iPXE, TrenchBoot, coreboot, LinuxBoot,

SeaBIOS, UEFI, OVMF, TianoCore, hostboot, IPMI, OpenBMC, u-bmc, TPM,

attestation, security of firmware, BMC, bootloaders and related topics and

technologies.


Ideal submissions are actionable and opinionated. Submissions may be in the

form of 25 or 45 minutes talks, panel sessions or round-table discussions.


Dates

-

Submission Deadline:     20-Dec-2020 @ 23:59:59 UTC

Acceptance Notification: 31-Dec-2020

Final Schedule Posted:   31-Dec-2020


Recording and uploading presentations: 04-Jan-2021 - 16-Jan-2021

Processing, reviewing, fixing videos:  17-Jan-2021 - 31-Jan-2021


How to submit

--

Visit https://penta.fosdem.org/submission/FOSDEM21


1) If you do not have an account, create one here

2) Click "Create Event"

3) Enter your presentation details

4) Be sure to select the Open Source Firmware,

   BMC and Bootloader devroom track!

5) Submit


What to include

---

- The title of your submission

- A 1-paragraph abstract

- A longer description including the benefit of your talk to your target

  audience, including a definition of your target audience

- Approximate length/type of submission (talk, BoF, ...)

- Links to related websites/blogs/talk material (if any)


Administrative Notes



Since the FOSDEM21 is going virtual, the talks will be prerecorded. We
will be

streaming the recordings and performing live Q of the Open Source
Firmware,

BMC and Bootloader devroom. Presenting at FOSDEM implies permission to
record

your session and distribute the recording afterwards. All videos will be
made

available under the standard FOSDEM content license (CC-BY).


If you have any questions, feel free to contact the devroom organizers:

  Daniel Kiper (daniel.kiper at oracle.com) and

  Michał Żygowski (michal.zygowski at 3mdeb.com).


Daniel & Michał


___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: [SPECIFICATION RFC] The firmware and bootloader log specification

[Paul Menzel]

Dear Wim, dear Daniel,


First, thank you for including all parties in the discussion.
Am 04.12.20 um 13:52 schrieb Wim Vervoorn:


I agree with you. Using an existing standard is better than inventing
a new one in this case. I think using the coreboot logging is a good
idea as there is indeed a lot of support already available and it is
lightweight and simple.
In my opinion coreboot’s format is lacking, that it does not record the 
timestamp, and the log level is not stored as metadata, but (in 
coreboot) only used to decide if to print the message or not.


I agree with you, that an existing standard should be used, and in my 
opinion it’s Linux message format. That is most widely supported, and 
existing tools could then also work with pre-Linux messages.


Sean Hudson from Mentor Graphics presented that idea at Embedded Linux 
Conference Europe 2016 [1]. No idea, if anything came out of that 
effort. (Unfortunately, I couldn’t find an email. Does somebody have 
contacts at Mentor to find out, how to reach him?)



Kind regards,

Paul


[1]: 
http://events17.linuxfoundation.org/sites/events/files/slides/2016-10-12%20-%20ELCE%20-%20Shared%20Logging%20-%20Part%20Deux.pdf

___
coreboot mailing list -- coreboot@coreboot.org
To unsubscribe send an email to coreboot-le...@coreboot.org

[coreboot] Re: [SPECIFICATION RFC] The firmware and bootloader log specification

[Wim Vervoorn]

Hello Julius,

I agree with you. Using an existing standard is better than inventing a new one 
in this case. I think using the coreboot logging is a good idea as there is 
indeed a lot of support already available and it is lightweight and simple.

Best Regards,
Wim Vervoorn

Eltan B.V.
Ambachtstraat 23
5481 SM Schijndel
The Netherlands

T : +31-(0)73-594 46 64
E : wvervo...@eltan.com
W : http://www.eltan.com


"This message contains confidential information. Unless you are the intended 
recipient of this message, any use of this message is strictly prohibited. If 
you have received this message in error, please immediately notify the sender 
by telephone +31-(0)73-5944664 or reply email, and immediately delete this 
message and all copies."


-Original Message-
From: Grub-devel [mailto:grub-devel-bounces+wvervoorn=eltan@gnu.org] On 
Behalf Of Julius Werner
Sent: Thursday, December 3, 2020 2:18 AM
To: Daniel Kiper 
Cc: Coreboot ; The development of GRUB 2 
; LKML ; 
systemd-de...@lists.freedesktop.org; trenchboot-de...@googlegroups.com; U-Boot 
Mailing List ; x...@kernel.org; 
xen-de...@lists.xenproject.org; al...@umass.edu; 
alexander.burmas...@oracle.com; allen.cryp...@gmail.com; 
andrew.coop...@citrix.com; ard.biesheu...@linaro.org; btrot...@gmail.com; 
dpsm...@apertussolutions.com; eric.devol...@oracle.com; 
eric.snowb...@oracle.com; h...@zytor.com; h...@n-dimensional.de; 
javi...@redhat.com; joao.m.mart...@oracle.com; kanth.ghatr...@oracle.com; 
konrad.w...@oracle.com; krystian.he...@3mdeb.com; l...@nuviainc.com; 
lukasz.hawry...@intel.com; l...@amacapital.net; michal.zygow...@3mdeb.com; 
mj...@google.com; mtott...@akamai.com; Vladimir 'phcoder' Serbinenko 
; piotr.k...@3mdeb.com; pjo...@redhat.com; Paul Menzel 
; roger@citrix.com; ross.philip...@oracle.com; 
tyhicks@l
 inux.microsoft.com; Heinrich Schuchardt 
Subject: Re: [SPECIFICATION RFC] The firmware and bootloader log specification

Standardizing in-memory logging sounds like an interesting idea, especially 
with regards to components that can run on top of different firmware stacks 
(things like GRUB or TF-A). But I would be a bit wary of creating a "new 
standard to rule them all" and then expecting all projects to switch what they 
have over to that. I think we all know https://xkcd.com/927/.

Have you looked around and evaluated existing solutions that already have some 
proliferation first? I think it would be much easier to convince people to 
standardize on something that already has existing users and drivers available 
in multiple projects.

In coreboot we're using a very simple character ring buffer that only has two 
4-byte header fields: total size and cursor (i.e. current position where you 
would write the next character). The top 4 bits of the cursor field are 
reserved for flags, one of which is the "overflow" flag that tells you whether 
the ring-buffer already overflowed or not (so readers know whether to print the 
whole ring buffer, or only from the start to the current cursor). We try to 
dimension the buffers so they don't overflow on a single boot, but this 
approach allows us to log multiple boots on platforms that can persist memory 
across reboots, which sometimes comes in handy.

The disadvantages of that approach compared to your proposal are lack of some 
features, like the facilities field (although one can still just print a tag 
like "<0>" or "<4>" behind each newline) or timestamps (coreboot instead has 
separate timestamp logging). But I think a really big advantage is size: in 
early firmware environments before DDR training, space is often very precious 
and we struggle to find more than a couple of kilobytes for the log buffer. If 
I look at the structure you proposed, that's already 24 bytes of overhead per 
individual message. If we were hooking that up to our normal printk() facility 
in coreboot (such that each invocation creates a new message header), that 
would probably waste about a third of the whole log buffer on overhead. I think 
a complicated, syslog-style logging structure that stores individual message 
blocks instead of a continuous character string isn't really suitable for 
firmware logging.

FWIW the coreboot console has existing support in Linux 
(https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/firmware/google/memconsole-coreboot.c),
SeaBIOS 
(https://github.com/coreboot/seabios/blob/master/src/fw/coreboot.c#L219),
TF-A 
(https://github.com/ARM-software/arm-trusted-firmware/blob/master/drivers/coreboot/cbmem_console/aarch64/cbmem_console.S),
GRUB 
(https://git.savannah.gnu.org/cgit/grub.git/tree/grub-core/term/i386/coreboot/cbmemc.c),
U-Boot 
(https://github.com/u-boot/u-boot/blob/master/drivers/misc/cbmem_console.c)
and probably a couple of others I'm not aware of. And the code to add support 
(especially when only appending) is so simple that it just takes a couple of 
lines to implement (binary code size to implement the format is also 

[coreboot] Re: Apollo Lake cannot load coreboot

[Anatolii Vorobev]

Hi Wolfgang,
We have TI650944 PMIC and LPDDR4 memory down configuration. SPI flash chip JDEC 
ID do present in IFD VSCC table. SPI boot strap is selected, TXE ROM Bypass is 
disabled.
I program flash device with Dediprog programmer.
Yes, I can see __FMAP__ signature in the dumped binary at 0x30 offset.

I have a question. Is it TXE that copies bootblock and romstage into RAM(cache)?

I also wonder what differences can be between UP2 and my board? May be I should 
preprogram something into FPF (signing keys maybe) before loading coreboot? Can 
it be related to Boot Guard?

Best Regards,
Anatolii Vorobev
Lead Developer, Firmware | WayRay
anatolii.voro...@wayray.com | 
http://wayray.com
+7 915 423-87-68 (RU)

From: Wolfgang Kamp - datakamp 
Sent: Thursday, December 3, 2020 11:40 AM
To: Anatolii Vorobev 
Cc: coreboot@coreboot.org
Subject: AW: [coreboot] Re: Apollo Lake cannot load coreboot

Hi Anatolii,

If you search the web for “apollolake implementation – coreboot”, you will find 
interesting information about the Apollo Lake boot process. The IFD will be 
processed from the internal microcontroller which looks for the correct Flash 
device and the PMIC. The PMIC must be the TI chip TPS65094x in the case of 
using the UP Squared board BIOS components. To boot from SPI the SOC_COM1_TXD 
(eMMC boot) signal must be pulled low and the SOC_COM1_RTS_N (SPI boot) signal 
must be pulled high.
How do you program the on board FLASH device?
If you dump the binary contents you can see –FMAP-- signature at 0x30?

Kind regards,
Wolfgang

Von: Anatolii Vorobev [mailto:anatolii.voro...@wayray.com]
Gesendet: Mittwoch, 2. Dezember 2020 13:44
An: Wolfgang Kamp - datakamp mailto:wmk...@datakamp.de>>
Cc: coreboot@coreboot.org
Betreff: RE: [coreboot] Re: Apollo Lake cannot load coreboot

Hi Wolfgang,
If I read memory at address 0xFF00 -0xFFFE  after SPI is initialized by 
bootblock_soc_early_init() then I will get only 0xFF bytes. So there is no 
mapped SPI image there – it is empty. But I should see at least IFD at 0xFF00 
-0xFF00 1000, am I right?

The mainboard I’m debugging is not UP Squared, the schematics are just a bit 
resembling (as far as I see, because UP2 design files are disclosed). That’s 
why there are some hardware differences that lead to problems above. Is it GPIO 
settings or bootstraps? What would you suggest me to check first?

Best Regards,
Anatolii Vorobev

From: Wolfgang Kamp - datakamp mailto:wmk...@datakamp.de>>
Sent: Tuesday, December 1, 2020 5:33 PM
To: Anatolii Vorobev 
mailto:anatolii.voro...@wayray.com>>
Cc: ger...@coreboot.org
Subject: AW: [coreboot] Re: Apollo Lake cannot load coreboot

Hi Anatolii,

In this early stage there is no RAM initialized. The SPI Flash is memory mapped 
starting at 0xFF00  if the FLASH size is 16M, which is on UP Squared 
default.  On address 0xFF30  (0x30 relative to FLASH start address) 
starts FMAP. You will find the header –FMAP—on this position. With an in 
circuit programmer like DEDIPROG 100 you can check this on UP Squared board.

Kind regards,
Wolfgan


Von: Anatolii Vorobev [mailto:anatolii.voro...@wayray.com]
Gesendet: Dienstag, 1. Dezember 2020 12:44
An: Maxim Polyakov 
mailto:max.senia.pol...@gmail.com>>
Cc: coreboot@coreboot.org
Betreff: [coreboot] Re: Apollo Lake cannot load coreboot

Hi, Maxim. Sure, I’ve attached .config file.
Here is cbfstool output:

./build/cbfstool build/coreboot.rom print
FMAP REGION: COREBOOT
Name   Offset Type   Size   Comp
cbfs master header 0x0cbfs header32 none
fallback/romstage  0x80   stage   48164 none
cpu_microcode_blob.bin 0xbd00 microcode   48128 none
fallback/ramstage  0x17980stage  106068 none
vgaroms/seavgabios.bin 0x31840raw 28160 none
config 0x386c0raw   283 none
revision   0x38840raw   681 none
fallback/dsdt.aml  0x38b40raw  6338 none
fspm.bin   0x3a480fsp364544 none
vbt.bin0x934c0raw  1299 LZMA (6154 
decompressed)
payload_revision   0x93a40raw   235 none
(empty)0x93b80null 1048 none
fsps.bin   0x93fc0fsp176128 none
fallback/postcar   0xbf000stage   22064 none
fallback/payload   0xc4680simple elf  69275 none
payload_config 0xd5580raw  1760 none
(empty)0xd5cc0null 11137752 none
bootblock  0xb74fc0   bootblock   32768 none

Best Regards,
Anatolii Vorobev

From: Maxim Polyakov