-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Hi @ all,
is there a Coroboot for the Lenovo T410 Laptop?
Greetings
Alex Veek
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
iF4EAREIAAYFAlNxKzsACgkQ53cWmi2XuzOOXAD8CNLPoycJNftQzeHnMQbl8ZG9
4y2SPIHwLota1/Gsfm0BAJzhG2M+MKXDBJgazHjt/HM2DyAeHi6S24sGcwd1W2GN
=sFKM
-----END PGP SIGNATURE-----
Does anyone know what TPM's are compatible?
I also want to know what coreboot's tpm support is like these days, such
as how can you perform an erase/reset like one could with a standard OEM
bios.
- Thanks in advance
Dear coreboot administrators,
Currently, I am unable to fetch the newest commits/objects(?) from the
coreboot git server.
```
$ LANG=C git fetch -vv origin
[…]
have ccbaabe5cf6b7eaa20fc323858680a404383537b
got ack 3 dee643a360ad75787f2982a013c62a4d49352121
got ack 3 a1de1a0810892c3c3a22ed6e2868fbef3bde8134
got ack 3 6a720e16e7e966b034c462242ccdf99e371a1ad7
got ack 3 5d5fb1402be06cacc45d4785201b719e8c3501d1
got ack 3 eb9b2c8105642ba99c34bd727e26483ffc6a0b57
got ack 3 9e882dfff180a75c28a01c49d80e27f545bddb3a
got ack 3 26ee056a55ee835a9c3bfc8b18854cb121e9371c
got ack 3 27c8b82d09083e1733bcd60bb42fc52693615ce8
got ack 3 fec58518a57f67e6e1186a573503ccaec7bcf8e6
got ack 3 4d4286faa0b5e134c71c65e0e3a3a7480ca0d79d
got ack 3 907a0831fb4ac4dc491656d68191274411c65944
got ack 3 30796a481fb752d63bb9b2f939595a29cb18c823
got ack 3 bdcf664a03ef6a4a17b1b367c9ab2fbf34aea244
got ack 3 4be4ad343aa40deaf627ef02da7c07dfcad47b6c
got ack 4 91ec3f1264a85aa57715e059276d96bfbc178c80
done
got ack (4) ccbaabe5cf6b7eaa20fc323858680a404383537b
got ack (1) 4be4ad343aa40deaf627ef02da7c07dfcad47b6c
fatal: internal server error
remote: internal server error
fatal: protocol error: bad pack header
```
Aaron reported the same problem in the IRC channel some days ago, and I
remember having this problem some months ago too.
Could you please take a look on the server?
Kind regards,
Paul
tldr;
10.08.2017 18:30 (open end) AfRA (different location!)
Hi,
the Berlin Usergroup Meeting in August will taken
place on 10.08.2017 in the rooms of the Department Of Redundancy
Department (AfRA).
Abteilung für Redundanz Abteilung
Margaretenstraße 30
10317 Berlin
https://afra-berlin.de/
best,
lynxis
Ps. If you want to flash your laptop, send me a notice in advance.
Certain things might need to prepared for your device.
--
Alexander Couzens
mail: lynxis(a)fe80.eu
jabber: lynxis(a)fe80.eu
mobile: +4915123277221
gpg: 390D CF78 8BF9 AA50 4F8F F1E2 C29E 9DA6 A0DF 8604
On 10.08.2017 16:36, Zheng Bao wrote:
> Thanks. Your advice is quite helpful.
>
>
> I got the BMP and BSF, created a vBIOS which enables the DDI2 as DP. The vBIOS has been
>
> validated by IBV(AMI) BIOS.
>
>
> But the VBIOS can not enable DDI2 in Coreboot. I assume I still miss something.
There used to be a priority list which display is preferably initia-
lized. It was in a weird notation LFP (local flat panel) would be
the eDP port and EFP2 (external flat panel 2) might be DDI2. Some-
where you have to set that EFP2 is preferred, I suppose. (All what
I remember from an Ivy Bridge VBT.)
Nico
>
>
> Zheng
>
> ________________________________
> From: Nico Huber <nico.h(a)gmx.de>
> Sent: Wednesday, August 9, 2017 6:29 PM
> To: Zheng Bao; coreboot(a)coreboot.org
> Subject: Re: [coreboot] [Broadwell-U]How the eDP, DDI1, DDI2 are enabled?
>
> On 08.08.2017 05:39, Zheng Bao wrote:
>> In text mode,
>> only one display can be enabled.
>>
>>
>> Can this enabled display port be DDI1 or DDI2?
>>
>> I just extracted VBIOS from BIOS provided on board. I assume the display ports are enabled based on the board settings.
>>
>> Can I just set register "gpu_panel_port_select" = "2" to enable DDI1?
>
> No, unfortunately not. This setting only affects the panel power sequen-
> cer (i.e. which port needs special care because it hosts a panel whose
> power is controlled by us). It shouldn't affect the VBIOS.
>
> Again, the VBIOS has many options, set in the binary. I know free tools
> to dump them partially, but none to set them. The regular way is to ask
> Intel for their Binary Modification Program (BMP, may be compatible with
> Intel's Binary Configuration Tool [1]) *and* a description file for the
> Video BIOS Table format (.bsf IIRC). That .bsf file is specific to the
> chipset generation (I can't find one for Broadwell, sadly), though, one
> for another generation might work too. Sometimes these files can be
> found in graphics driver packages or FSP [2].
>
> If you happen to get the Intel tool running, I advice to double check
> the result in a hex editor (e.g. there should be only the change you
> made, plus about two checksums).
>
> Nico
>
> [1] https://github.com/IntelFsp/BCT
> [https://avatars1.githubusercontent.com/u/19785541?v=4&s=400]<https://github.com/IntelFsp/BCT>
>
> GitHub - IntelFsp/BCT: Binary Configuration Tool for Intel ...<https://github.com/IntelFsp/BCT>
> github.com
> BCT - Binary Configuration Tool for Intel(R) FSP
>
>
> [2] Here is one for Kabylake (the closest I could find, might be
> incompatible though):
>
> https://github.com/IntelFsp/FSP/blob/Kabylake/KabylakeFspBinPkg/SampleCod...
> [https://avatars1.githubusercontent.com/u/19785541?v=4&s=400]<https://github.com/IntelFsp/FSP/blob/Kabylake/KabylakeFspBinPkg/SampleCod...>
>
> IntelFsp/FSP<https://github.com/IntelFsp/FSP/blob/Kabylake/KabylakeFspBinPkg/SampleCod...>
> github.com
> Repository of FSP binaries posted by Intel
>
>
>
I can't download the .pdf file for some reason (maybe the tla's got to it?)
http://fm.csl.sri.com/LAW/2009/dobry-law09-HAP-Challenges.pdf
can someone send it to me?
Thanks
Thoughts:
Sad this is still not an actual method of disablement, but it doesn't
really matter as anyone who buys *new* x86 hardware is still supporting
wintel's development of newer and better anti-features, DRM and
surveillance technology - one that can't even be me-cleaner/hap/etc
nerfed will be released some day. I wish people spent their energy
popularizing owner controlled arches instead of beating a dead horse.
While IBM also makes surveillance tech they make POWER which as the last
performance owner controlled arch that sells for attainable prices goes
a long way to offset that. Heres to hoping IBM starts selling POWER
workstations...
I find it hard to believe that the NSA uses made in china intel stuff
with ME chips present for their high security stuff (hap nerfed or not),
I imagine top secret things are done on POWER (which has a USA cpu fab
and no black boxes).
Dear folks and techpriests,
the more I want to contribute and learn about low-level-code the less I
understand, it seems.
1. cb switches the CPU immediately to Protected Mode, yet Payloads like
seaBIOS work in Real Mode. Does coreboot switch the CPU always back
to RM before jumping to the payload?
2. When CB switches to PM - who generates and administrates the Page
Tables and where?
3. Gustavo Duarte writes
<http://duartes.org/gustavo/blog/post/how-computers-boot-up/> that
GRUB switches from protected mode to real mode and vice versa all
the time to address >1MiB of RAM and also use the BIOS-calls. If
this is true using GRUB as payload would not work, as GRUB needs to
call the non-existent BIOS, right?
4. Once CB is in PM it can't access physical addresses anymore? It
doesn't need to, too?
5. PM means RAM-access is only possible through virtual addresses which
are translated by the MMU using the Page Tables. This question is
similar to [2.]: If coreboot generates the Page Tables and the
payload would start in PM as well (is this even possible? At least
the Linux-Kernel has entry points for RM and PM) this would mean the
payload needs to use the Page Tables generated by CB. That wouldn't
be a problem as they're linked in the register CR3 anyways?
And an unimportant bonus question:
* Why does every modern CPU still start in RM? I do get the
compatibility problem, but on the other hand: Do you need it for
anything beside booting MS-DOS on your Ryzen? Is it really
impossible for AMD and Intel to create a new CPU-generation with the
x86-instruction set without RM, 16-bit-registers and 20-bit-mode
registers like CS, SS etc. No modern OS uses bios calls. No CPU is
ever switched to RM again after booting up. They should get rid of
this old stuff.
Would be cool if someone could put this in its true light.
Thanks,
Philipp
Zoran, Vincenzo,
BIOS and UEFI have higher privilege in the system than the OS kernel,
which has higher privilege than userland processes, which have higher
privilege than the user.
Any component with higher privilege can override, circumvent or
contradict parts of the system and users with lower privilege levels.
BIOS is x86-specific.
UEFI is arguably not technically superior to BIOS.
UEFI has sadly infected other platforms than x86.
Interrupt services were introduced with the BIOS, and will continue
to always be available on x86 platforms, for compatibility.
Compatibility is the only actual value of x86.
UEFI on x86 does not neccessarily have to, but in practice generally
does include a CSM, which provides BIOS-compatible interrupt services
also on systems with UEFI.
Regardless of whether that's a 32 or 64 bit UEFI, the CSM always
provides the legacy 16 bit interface.
Vincenzo, if you are creating a secure system, you must first establish
what is secure *enough* for your use case. Risk assessment and a threat
model are essential, or you will never reach a working reliable system,
because they define your goal.
Security issues can exist pretty much everywhere, so an "ideal" secure
system is not very practical.
//Peter
Dear coreboot folks,
Trying to run `make test-abuild` on my system with a 32-bit userspace,
it looks like quite some boards require the program futility from
`util/futility`, but that fails to build with the error below.
```
/dev/shm/coreboot/util/futility(master) $ git describe
4.6-1292-g5bf3457bc4
/dev/shm/coreboot/util/futility(master) $ LANG= make
MAKE futility/build/futility/futility
unset CFLAGS LDFLAGS; make -C /dev/shm/coreboot/3rdparty/vboot \
BUILD=/dev/shm/coreboot/util/futility/build \
CC="cc" \
V= \
/dev/shm/coreboot/util/futility/build/futility/futility
make[1]: Entering directory '/dev/shm/coreboot/3rdparty/vboot'
CC futility/futility.o
CC futility/cmd_dump_fmap.o
CC futility/cmd_gbb_utility.o
CC futility/misc.o
CC futility/ryu_root_header.o
CC futility/cmd_bdb.o
CC futility/cmd_create.o
CC futility/cmd_dump_kernel_config.o
CC futility/cmd_load_fmap.o
CC futility/cmd_pcr.o
CC futility/cmd_show.o
CC futility/cmd_sign.o
CC futility/cmd_validate_rec_mrc.o
CC futility/cmd_vbutil_firmware.o
CC futility/cmd_vbutil_kernel.o
CC futility/cmd_vbutil_key.o
CC futility/cmd_vbutil_keyblock.o
CC futility/file_type.o
CC futility/file_type_bios.o
CC futility/file_type_rwsig.o
CC futility/file_type_usbpd1.o
CC futility/vb1_helper.o
CC futility/vb2_helper.o
CC futility/bdb_helper.o
GEN gen/futility_cmds.c
CC gen/futility_cmds.o
CC cgpt/cgpt_create.o
CC cgpt/cgpt_add.o
CC cgpt/cgpt_boot.o
CC cgpt/cgpt_show.o
CC cgpt/cgpt_repair.o
CC cgpt/cgpt_prioritize.o
CC cgpt/cgpt_common.o
CC futility/dump_kernel_config_lib.o
make[1]: *** No rule to make target '/dev/shm/coreboot/util/futility/build/host/arch/i686/lib/crossystem_arch.o', needed by '/dev/shm/coreboot/util/futility/build/libvboot_util.a'. Stop.
make[1]: Leaving directory '/dev/shm/coreboot/3rdparty/vboot'
Makefile.inc:4: recipe for target '/dev/shm/coreboot/util/futility/build/futility/futility' failed
make: *** [/dev/shm/coreboot/util/futility/build/futility/futility] Error 2
```
I haven’t tested this yet with a 64-bit userspace, but assume that
works. Does somebody have a fix?
Thanks,
Paul
