coreboot May 2022

coreboot@coreboot.org

28 participants
27 discussions

Intel Quark - a quick update
by Andy Pont 20 Jul '22

20 Jul '22

Thanks to the generosity of members of the list there are two Intel Galileo boards, a Gen 1 and Gen 2, on their way to me which should arrive towards the end of the month. As soon as they get here I will start testing the various configs to see what works and what is broken. -Andy.

7 10

[RFH] Test Lenovo X230 with master?
by Paul Menzel 24 Jun '22

24 Jun '22

Dear coreboot folks, In #coreboot(a)irc.libera.chat a user reported, that flashing coreboot built from master (commit aa8b1f8b38 (mb/system76: Configure I2C HID IRQs as level triggered)) to SPI2 does not boot. > Display black but lit, no display output. I don't have coreboot logs. > Blinking power button + micmute button. Unfortunately, the user does not have any equipment to get any logs, and SPI flash console is not supported. Could somebody with such equipment please verify, and provide the logs? Kind regards, Paul PS: `defconfig`: ``` CONFIG_VENDOR_LENOVO=y CONFIG_CBFS_SIZE=0x400000 CONFIG_LINEAR_FRAMEBUFFER_MAX_HEIGHT=1600 CONFIG_LINEAR_FRAMEBUFFER_MAX_WIDTH=2560 CONFIG_CONSOLE_CBMEM_BUFFER_SIZE=0x20000 CONFIG_HAVE_IFD_BIN=y CONFIG_PCIEXP_HOTPLUG_BUSES=8 CONFIG_PCIEXP_HOTPLUG_MEM=0x800000 CONFIG_PCIEXP_HOTPLUG_PREFETCH_MEM=0x10000000 CONFIG_BOARD_LENOVO_X230=y CONFIG_UART_PCI_ADDR=0x0 CONFIG_VALIDATE_INTEL_DESCRIPTOR=y CONFIG_H8_SUPPORT_BT_ON_WIFI=y CONFIG_HAVE_ME_BIN=y CONFIG_CHECK_ME=y CONFIG_USE_ME_CLEANER=y CONFIG_HAVE_GBE_BIN=y CONFIG_LOCK_MANAGEMENT_ENGINE=y CONFIG_GENERIC_LINEAR_FRAMEBUFFER=y CONFIG_PCIEXP_HOTPLUG_IO=0x2000 CONFIG_SUBSYSTEM_VENDOR_ID=0x0000 CONFIG_SUBSYSTEM_DEVICE_ID=0x0000 CONFIG_I2C_TRANSFER_TIMEOUT_US=500000 CONFIG_POST_IO_PORT=0x80 CONFIG_PAYLOAD_GRUB2=y CONFIG_GRUB2_REVISION=y CONFIG_GRUB2_REVISION_ID="grub-2.06" CONFIG_GRUB2_EXTRA_MODULES="nativedisk crypto cryptodisk luks luks2 gcry_serpent gcry_twofish gcry_rijndael gcry_sha1 gcry_sha256 gcry_sha512 gcry_crc password_pbkdf2 part_gpt btrfs cat bsd png gfxterm_background all_video usbserial_ftdi usbserial_pl2303" CONFIG_COREINFO_SECONDARY_PAYLOAD=y CONFIG_MEMTEST_SECONDARY_PAYLOAD=y CONFIG_NVRAMCUI_SECONDARY_PAYLOAD=y ```

3 3

Automated Engineering Notes was Re: Deprecation of the Intel Quark SoC
by Karl Semich 18 Jun '22

18 Jun '22

I'm not working on this but am still interested in the idea, in my hobby capacity. The below emails were exchanged. I didn't yet receive further reply. ---------- Forwarded message --------- Date: Sun, Apr 24, 2022, 10:31 AM Subject: Re: [coreboot] Re: Deprecation of the Intel Quark SoC To: Karl Semich <0xloem(a)gmail.com> I'm very interested in your ideas. Yep, I"m interested, I've been trying to find someone interested in this for 5 years now ---------- Forwarded message --------- Date: Sun, Apr 24, 2022, 10:32 AM Subject: Re: [coreboot] Re: Deprecation of the Intel Quark SoC To: Karl Semich <0xloem(a)gmail.com> I think we should start with a binary blob for an open system like the allwinner d1. We have the blob, it's pretty simple code. ---------- Forwarded message --------- From: *Karl Semich* <0xloem(a)gmail.com> Date: Sun, Apr 24, 2022, 2:41 PM Subject: Re: [coreboot] Re: Deprecation of the Intel Quark SoC hi is this too many words below? are you still interested? how do you feel about making the conversation more public? my biggest issue is neurological and psychological, it's had for me to do things, so the more people the better the transformer model approach works on data. they need a lot of examples of something to begin copying well, thousands or millions or more. it seems fewer and fewer examples are needed the more similar data a model has been trained on already, down to finally needing none. ("few-shot", "zero-shot"). so one could take a pretrained model and e.g. adjust it (via training) to predict comments from uncommented code, or predict source from binaries of an architecture where more binaries are available, or from a specific set of compilers compiler where many training binaries could be generated from commented code. then by combining these separate models one might likely be able to perform a task on which less data is available. for me at this point, finding or generating that data, and finding paths to fit the model better to the target tasks, seems equally challenging compared to just setting up a basic training framework to fine tune models. there are a few different infrastructures, and sometimes people make their own if doing a new kind of task. most people are using jupyter notebooks via various online portals. there are also compute servers at places like vast.ai. but I am out of money and most of my devices are very low end. I expect this to happen and am interested in helping it happen but i'll be pretty slow and flaky on my own :) do you have any thoughts on generating or finding data similar to many pairings of embedded binary blobs and license-free interface specifications? is the allwinner d1 much data? most of the similar models I know of out there continue streams of human text or source code pick selecting up to 2048 words from a fixed vocabulary maybe 10k to 100k words large. There are many known techniques to extend this to more words but finding and implementing them is part of the effort. This also informs how to pick or develop a training framework: something that makes it easier to rearchitect the models will be needed to work with or generate data larger than 2048 symbols long. the challenge of lengthening may also be postponeable if the meaningful patterns of the data can be squeezed to fit within that size, as is done for human text in the mainstream. the model may learn appropriate patterns and then take only a little further adjustment to handle larger ones once rearchitectured to do so. ---------- Forwarded message --------- From: *Karl Semich* <0xloem(a)gmail.com> Date: Sun, Apr 24, 2022, 2:58 PM Subject: Re: [coreboot] Re: Deprecation of the Intel Quark SoC Basically, there's a class of neural networks called transformer models that have become mainstream for successfully solving problems across domains. Common systems used to work with them that I'm aware of include pytorch, jax, huggingface transformers, keras, and tensorflow: all python libraries. A number of groups are offering hubs where people share pretrained models for others to use. I've heard https://fast.ai/ has a good starting course, but it didn't quite seem for me, I haven't taken it. I think most people are learning from example jupyter notebooks. I've mostly learned by skimming the huggingface transformers source code and occasional research papers. Each transformer model is roughly made of "layers" of "self attention" , which is roughly just a class of a few operations performed on data represented as matrices, and then passed to the next layer where the operations are performed again. Each layer has many "weights" -- coefficients -- which are how the model "learns", by backpropagating gradients to adjust their values. A big thing appears to have been how to organise the beginning and end of the chain. The models usually have something different on both ends, to process the input or output data between the internal representation of huge matrices of floating point numbers. It seems important to do this in a way that preserves the meaning of the data well, and often a couple other neural network parts are used -- very short algorithms that can operate with trainable coefficients on large matrices. The basic takeaway is that transformer models use an algorithm called "self attention" to combine mutating data matrices with trained matrices, in sequential layers like a pipeline, and these chunks of attention have been found to be able to adjust themselves to pretty much any task, if they have good data and enough quantity. As stated previously most of the mainstream code out there gets unwieldy if there are more than 2048 input or output elements, and there are many changes explored around that but I'm not aware of one having been settled upon. ---------- Forwarded message --------- Date: Sun, Apr 24, 2022, 2:49 PM Subject: Re: [coreboot] Re: Deprecation of the Intel Quark SoC To: Karl Semich <0xloem(a)gmail.com> you don't want to RE a binary, that gets you into trouble. But you are allowed to RE from the activity, basically memory reads and writes. That's turning observation into code. So, that's the first challenge. ---------- Forwarded message --------- From: *Karl Semich* <0xloem(a)gmail.com> Date: Sun, Apr 24, 2022, 3:01 PM Subject: Re: [coreboot] Re: Deprecation of the Intel Quark SoC I agree that's preferable, but I don't have a simulator or a circuit logger at this time. Do you have these things? I understand it's legal to re-engineer if the reverse engineer keeps their work private, sharing only an interface specification. Is this your experience? ---------- Forwarded message --------- From: *Karl Semich* <0xloem(a)gmail.com> Date: Mon, Apr 25, 2022, 5:34 AM Subject: Re: [coreboot] Re: Deprecation of the Intel Quark SoC On Sun, Apr 24, 2022, 10:31 AM wrote: I'm very interested in your ideas. Yep, I"m interested, I've been trying to find someone interested in this for 5 years now I think I kind of glossed over this; what approaches have you pursued already? What challenges did you encounter? On Sun, Apr 24, 2022, 2:49 PM wrote: you don't want to RE a binary, that gets you into trouble. But you are allowed to RE from the activity, basically memory reads and writes. That's turning observation into code. So, that's the first challenge. I didn't realize that serialice does this already. It looks like serialice's qemu patches make it pretty easy to probe firmware behavior. We could start training on normal open-source blobs and generate random working code to augment the data. ---------- Forwarded message --------- From: *Karl Semich* <0xloem(a)gmail.com> Date: Mon, Apr 25, 2022, 5:40 AM Subject: Re: [coreboot] Re: Deprecation of the Intel Quark SoC On Sun, Apr 24, 2022, 10:32 AM wrote: I think we should start with a binary blob for an open system like the allwinner d1. We have the blob, it's pretty simple code. I websearched this chip; it seems it's RISC-V. I think that means that serialice's qemu patches wouldn't work with it out of the box. Do you know how to hook i/o accesses for RISC-V in qemu? If the first step is patching qemu it seems it might make more sense to start with an x86 chip? ---------- Forwarded message --------- Date: Mon, Apr 25, 2022, 10:02 AM Subject: Re: [coreboot] Re: Deprecation of the Intel Quark SoC The x86 are fiendishly complex. There is in development an open source version of the memory setup code for the D1, so it would be possible to create a proof of concept by logging all the memory rights that are done to set up dram. I'm pretty familiar with the many types of dram startup and I would prefer if possible to start with the all winter D1 startup. ---------- Forwarded message --------- From: *Karl Semich* <0xloem(a)gmail.com> Date: Mon, Apr 25, 2022, 10:30 AM Subject: Re: [coreboot] Re: Deprecation of the Intel Quark SoC I websearched but didn't find the open firmware yet. Where's it at? You didn't mention an emulation environment, so I was thinking of how the logging would be done. I think the cpu or architecture actually wouldn't matter at all if you have enough example source, and instrument them to log their writes and reads. The relevent task here seems to be collecting firmware examples that can be expressed in blocks smaller than 2048 tokens, and logging their runs on host hardware with instrumented reads and writes. I'm thinking on this a little, not quite sure yet how to approach it. ---------- Forwarded message --------- Date: Mon, Apr 25, 2022, 10:34 AM Subject: Re: [coreboot] Re: Deprecation of the Intel Quark SoC To: Karl Semich <0xloem(a)gmail.com> You are helping me refine my thinking. We need a cheap platform, that has lots of people involved, that would let us do this test. I would still suggest something like the lichee r5 or similar allwinner-based platform ---------- Forwarded message --------- From: *Karl Semich* <0xloem(a)gmail.com> Date: Mon, Apr 25, 2022, 10:40 AM Subject: Re: [coreboot] Re: Deprecation of the Intel Quark SoC the hits I get for lichee r5 seem to mostly be in chinese, a language I haven't learned what do you think of the idea of setting up some scripts to instrument firmware sources for a lot of different platforms? ---------- Forwarded message --------- From: *Karl Semich* <0xloem(a)gmail.com> Date: Mon, Apr 25, 2022, 11:17 AM Subject: Re: [coreboot] Re: Deprecation of the Intel Quark SoC here is my present nascent idea, unsure: - instrument sources to log their writes and reads, and use the logs as input data - during compilation, use inotify to log which files are read from, and use these files as output data to train - change to different source history points and shuffle configuration options to produce more data - if needed, a larger model is bigbird: https://huggingface.co/docs/transformers/model_doc/bigbird_pegasus this can handle 4096 tokens of input+output - when input data is too large, add further trainable models to shrink it to fewer inputs as their output - when output data is too large, parameterise the generation to generate only part at once - run the code in qemu for the architecture so as to generate data for multiple architectures - if timing is important and the instrumentation changes the timing, this could be measured and compensated for arithmetically i'm a little confused on how logging might work in qemu. thinking of changing bootblock assembler to log things. seems this would best be done via a debugger with qemu that can act on the instructions themselves, not sure. it seems it might also be good to measure code coverage so as to train only around code that is actually executed. given there is a lot of hidden behavior, structures mutated without port writes, it could be good to err on the side of more data and more training expense. or if things are limited to ordered port writes, it could be incredibly simple. it seems to me x86 or arm makes more sense, so the code blocks could be executed on a normal consumer system.

2 2

Removing Yabits as a payload - Now, or after 4.19 release?
by Martin Roth 31 May '22

31 May '22

Unfortunately, yabits hasn't really seen any updates since it was added as a payload, so I think it's time to remove it. If there's no objection, we can remove it as a payload after today's 4.17 release. I don't believe this counts as deprecation, but if others feel otherwise, we can announce it in the 4.17 release notes (I'm working on those, I swear) and release it after the 4.19 release. Let me know what you think, either about the timing or about removing it period. As always, if it sees a reassurance in work, we can bring it back. Martin

3 2

Hello, coreboot general inquiries.
by mictty 31 May '22

31 May '22

tldr: OpenID does not work. Help me, sysmin. The url tells me it is to contact with the administrator. In comparison, it also seems to do with the administrator. Through Launchpad, the OpenID provider, I attempted to sign in dear your Gerrit. However, I only get this 'no found' message(https://review.coreboot.org/SignInFailure,SIGN_IN,Contact+site+admi…. Through Launchpad, I can sign in another website(not Coreboot). Can you do something for it? If your about to simply pass me the email of the administrator, you may forward to the admin instead. Best Regards, Mictty.

2 1

How to register on Coreboot Mainboard Vendor
by hechen42＠hotmail.com 31 May '22

31 May '22

Dear Coreboot team, Good days. We are an OEM&OEM Firewall mini pc manufacturer in SHENZHEN China. We are developing 2.5G firewall Mini PC hareware(we already finished them). And as Coreboot is very poweful and well knowned in firewall field so we are wonding that if we can become a coreboot registered motherboard vendor so user could use coreboot on our devices. May we know how to achieve its requirements ? Waitng for your comments and thanks a lot. Best Regards He Chen

2 1

New Defects reported by Coverity Scan for coreboot
by scan-admin＠coverity.com 31 May '22

31 May '22

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 1489551: Null pointer dereferences (FORWARD_NULL) ________________________________________________________________________________________________________ *** CID 1489551: Null pointer dereferences (FORWARD_NULL) /src/cpu/x86/mp_init.c: 797 in install_permanent_handler() 791 792 printk(BIOS_DEBUG, "Installing permanent SMM handler to 0x%08lx\n", smbase); 793 794 if (smm_load_module(smbase, smsize, &smm_params)) 795 return CB_ERR; 796 >>> CID 1489551: Null pointer dereferences (FORWARD_NULL) >>> Passing "&smm_params" to "adjust_smm_apic_id_map", which dereferences null "smm_params.stub_params". 797 adjust_smm_apic_id_map(&smm_params); 798 799 return CB_SUCCESS; 800 } 801 802 /* Load SMM handlers as part of MP flight record. */ ________________________________________________________________________________________________________ To view the defects in Coverity Scan visit, https://u15810271.ct.sendgrid.net/ls/click?upn=HRESupC-2F2Czv4BOaCWWCy7my0P…

1 0

[Proposal] Drop support for Ice lake [unmaintained]
by Tim Wawrzynczak 30 May '22

30 May '22

Good day folks, In a recent change[0], it was proposed that we drop support for the Intel Ice Lake platform. The only mainboard supporting the platform was the Intel RVP, but as far as anyone knows, it appears the project never progressed past the initial silicon, and so the code is now unmaintained and also unused. Since Ice Lake is very similar to TGL & ADL, it poses a maintenance burden when dealing with Intel common code e.g., anything in src/soc/intel/common. According to [1], this should be announced in upcoming release notes first, and removal could happen in 6 months. Wondering if anyone has any thoughts on why we should keep it around, otherwise let's update the upcoming release notes to give the "official" notice that it will be dropped. Cheers, - Tim [0]https://review.coreboot.org/c/coreboot/+/60053 [1]https://doc.coreboot.org/releases/templates.html

2 1

"vPub v5" opensource online Party! - this Thursday at 4 PM UTC
by Mike Banon 25 May '22

25 May '22

Dear friends, I'm happy to tell you about the upcoming "vPub v5" online party which starts this Thursday (26 May) at 4 PM UTC. Here's a homepage of our online party - https://vpub.dasharo.com/ Aside from having fun, we'd like to discuss and learn more about the wonderful open-source projects from the embedded world of firmware & hardware - and their advantages of liberty, security and quality. Some examples of the possible topics: *) new opensource coreboot BIOS port for a fresh retail Intel Alder Lake MSI PRO Z690-A WiFi DDR4 motherboard & its' testing results by QubesOS users. This port has been done by our 3mdeb company and is quite a spectacular accomplishment - because it's for a new motherboard still widely available as new! (usually by the time an opensource firmware is ported to some motherboard, it's long gone from the market and the people have to search for the old used ones); *) RustSBI - a software supervisor for RISC-V written on Rust programming language; *) qspimux - a hardware adapter for the safe remote flashing of SPI flash chip (used for storing the firmwares) without detaching it from a target motherboard; *) lnDSO150 - an alternative firmware for the popular handheld DSO oscilloscopes; *) bcm5719-fw - an alternative firmware for the network card Broadcom BCM5719; *) swtpm - a software Trusted Platform Module emulator and the ways of using it; *) TrenchBoot - a framework which uses multiple projects to improve the security of firmware booting. Thank you for a wonderful time with us at our past parties and your kind feedback! We hope that this one will be as exciting as the previous ones (which lasted for 10-12 hours) - and will be waiting for you. Expect a great time in a cosy community of opensource enthusiasts from all over the world! ;-) -- Best regards, Mike Banon Open Source Community Manager of 3mdeb - https://3mdeb.com/

1 0

Another day, another SMM loader vulnerability
by Arthur Heymans 23 May '22

23 May '22

Hi After last week's SMM loader problem on all but the BSP, I noticed another problem in the SMM setup. The permanent smihandler is currently built as a relocatable module such that coreboot can place it wherever it thinks it's a good idea. (TSEG is not known at buildtime). These relocatable modules have an alignment requirement. It looks however that the code to deal with the alignment requirement is also wrong and aligns the handler upwards instead of downwards which makes it encroach either an SSE2 FX_SAVE area or an SMM register save state. It's hard to know whether this is easily exploitable. I would think that a carefully crafted SMM save state on the right AP arbitrary code executing might be possible. On the other hand I noticed last week that launching SMM on APs is broken too so this is likely a lesser problem. Anyway the fix is in https://review.coreboot.org/c/coreboot/+/63475 (It has a comment indicating what code was causing this problem) Please review and update your coreboot code! Kind regards Arthur

2 3

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

coreboot May 2022