I am wondering what is the format of CPU-DRAM DQ byte map for FSP-M
configuration. Typically there are 64 DQ lanes per non-ECC SODIMM/DIMM
(correct me if I'm wrong) for DDR4 for example. But the DQ map is an
2x12 array, so I assume 12 bytes for each channel (why not 8 bytes?). My
1. Why there are more bytes in array than DQ lanes?
2. How should I define the DQ map? Does 0xFF or 0x00 mean 1 to 1 mapping?
3. Some FSP2.0 mainboards have values like 0x0F and 0xF0 in their
mappings which looks like 1 byte swap, but there are also 0xCC and 0x33.
What is the difference?
The DQS mapping is clear to me (rather obvious as there are only 8 DQS
which matches the 2x8 array).
I know about 3 Rcomp resistors of the chipset and what they are for, but
what RcompTarget is?
In the code I can see function `mainboard_fill_rcomp_strength_data` and
begin to wonder what rcomp strength is (not Rcomp Target?). How to
correctly fill RcompTarget FSP-M configuration?
Any tips and pointers appreciated.
http://3mdeb.com | @3mdeb_com
I'm not coreboot, but I'm a part of it, so I will try to answer your
question. CCing the coreboot mailing list for more input, as I can only
assume that that list was the intended recipient for your email.
It is unproven that Intel deliberately builds in backdoors into their
CPUs. However, a lot of their software / hardware designs create a
rather large attack surface that could be exploited, if someone puts the
right amount of resources on the problem.
This attack surface lives
- in the SOC's converged security management engine (CSME / ME), which
in some SKUs enables remote access to the system through builtin
network interfaces. The CSME cannot be fully disabled, but some
security issues can be mitigated in a good hardware software design
i.e. by using the non-enterprise (aka 1.5M SKU) of the ME firmware or
by not using the SOC associated network interfaces (questionable) or
by disabling as many CSME features as possible.
CSME is particularly problematic because it can access main memory, so
a remote attack could steal your private keys, rendering your
cryptographical secrets useless.
- FSP / BLOBS. Closed source firmware pieces generally have the problem
that they are impossible to audit. Even if there are fixed version out
in the field, you can not tell from a binary what is fixed or not.
Bugs are also impossible to fix, even when known. Imaginable attack
scenarios could also be deliberate changes to memory training data
which open known but fixed memory controller issues.
Generally coreboot tries to enable the user / developer / systembuilder
to address as many of these concerns as possible, but it can not 100%
fix them at this point. If you are concerned about your hardware
architecture, please study the source code of coreboot and the available
open documentation on x86 hardware (of which there is a fair amount) and
help us audit our code.
* Coins <coins(a)cryptolab.net> [190331 18:29]:
> Dear Coreboot,
> As far as I know, Intel puts proprietary backdoors in any recent CPU they
> How does this affect the security of a PC/laptop with coreboot installed
> when it is using such a processor?
> Best regards,
I'm trying to put coreboot on a Lenovov Thinpad T530. I'm using a ch341a SPI flasher with the Pomona clip. I disassembled the mainboard to do a backup of the original BIOS image, but I think flashrom can not recognize the BIOS chips correctly. I tried to do the backup on both chips separately but they were BOTH recognized as a 8MB MX25L6405 Chip instead of a 4MB MX25L3206E and a 8MB MX25L3206E. Any suggestions?
I asked the same question on IRC, but I hate this shit IRC. By mistake I disconnected to the channel so I have no glue what was answered there. Maybe someone could be nice and send me the answeres on IRC.
I wonder if there's some way I can contribute financially in a
significant way to this effort (up to $500).
I have 12 Intel Compute Sticks (STCK1A8LFC) which have only 1GB RAM and
8GB of eMMC storage. They are very resource-starved.
(Nobody wants these things...there are still 1,000s of them in
shrinkwrap going for $30 a piece.)
The stock Ubuntu 14.04 LTS 64-bit completely overwhelms the remaining
storage space once 3 years worth of updates are allowed to download and
MY ENTIRE GOAL IS TO PUT A NON-UEFI WINDOWS OS ON THERE that is older
than Windows 8.1 (preferably anything before and up to Windows XP).
There is not the luxury of storage space or RAM to do this any other
way, such as with a VM. That is a total dead end.
(I have a separate effort on my own to put a much smaller Linux version
on SOME of these for a different project, but that does NOT satisfy what
I want to do here with Legacy/CSM BIOS).
Therefore my entire fixated, obsessed effort is to modify the existing
or create a new Coreboot firmware to enable Legacy/CSM BIOS.
That is the ONLY effort I'm interested in with this forum.
I have a standing offer of $250 on one of the BIOS mod websites and can
increase that to $500 here if needed. I really want this done badly and
want to make a significant financial contribution.
I see a little bit of evidence using UEFITool that the Legacy/CSM BIOS
is merely disabled and hidden and it may just be a case to enable it and
make it visible in the F2 setup.
I am a student interested in contributing to coreboot as part of GSoC 2019.
I have seen the ideas list on the documentation page, and I am considering
working on fixing issues reported by Coverity Scan, and maybe additional
work on firmware RE tools. However, I would like to know if ports to new
mainboards/systems would be an acceptable project. I have an Ivy Bridge
desktop (Gigabyte GA-Z77X-UD5H) as well as a Arrandale laptop (HP Pavilion
dv7), and I am interested in porting coreboot to these platforms. I do have
some experience with UEFI programming in C (as well as x86(_64) ASM).