Heads port to Lenovo G505s

[tlaurion]

Someone has this laptop? @awokd?

[awokd]

Affirmative, and contact info for a few other owners. What's up?

[tlaurion]

@awokd : some of the owners are developers and would be willing to port Heads to them? Would you tag those owners or invite them here? I've ported Heads to KGPE-D16, would gladly port Heads to the G505s if I had access to one.

Couple of questions.
Does it have a TPM?
What are the max specs?

Have nice and cheap providers to buy from to suggest?
Some of you could lend me one for the time being of the porting?

[awokd]

• No TPM, is that OK for Heads?
• A10-5750M 4 core CPU with built in GPU, some models have an additional external GPU
• Not aware of any formal providers, can only find in used market

If TPM isn't required and there's no serious C level coding involved, I can give it a try. Might need some hand-holding, though. Do you have a step-by-step of how you ported Heads to that KPGE-D16? G505s ought to be pretty similar. If no TPM doesn't quash the idea, I'll drop a line to others and point them here to see if there's any developer availability.

[tlaurion]

TPM is not a show stopper, while better. Librem/Nitrokey Pro v2 keys can validate the integrity of the firmware in a similar way externally. Check the porting guide on heads-wiki project from osresearch's github. Can give you a hand but won't be able to debug. Working Linux and coreboot configurations are required. You can copy the kgpe-d16 board config as a start.

…

On Thu, Sep 27, 2018, 15:01 awokd, ***@***.***> wrote: - No TPM, is that OK for Heads? - A10-5750M 4 core CPU with built in GPU, some models have an additional external GPU - Not aware of any formal providers, can only find in used market If TPM isn't required and there's no serious C level coding involved, I can give it a try. Might need some hand-holding, though. Do you have a step-by-step of how you ported Heads to that KPGE-D16? G505s ought to be pretty similar. If no TPM doesn't quash the idea, I'll drop a line to others and point them here to see if there's any developer availability. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#453 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAygsm8jVq-BxgD73qhYI75ww2v5LQv3ks5ufSCigaJpZM4WsIe4> .

[awokd]

I am getting an error about strict aliasing. The same .config file gives no errors when I make in Coreboot. Any ideas? Is it a different version of Coreboot than master?

    CC         libagesa/vendorcode/amd/agesa/f15tn/Proc/CPU/Family/0x15/TN/F15TnEquivalenceTable.o
    CC         libagesa/vendorcode/amd/agesa/f15tn/Proc/CPU/Family/0x15/TN/F15TnInitEarlyTable.o
    CC         libagesa/vendorcode/amd/agesa/f15tn/Proc/CPU/Family/0x15/TN/F15TnIoCstate.o
src/vendorcode/amd/agesa/f15tn/Proc/CPU/Family/0x15/TN/F15TnIoCstate.c: In function 'F15TnInitializeIoCstate':
src/vendorcode/amd/agesa/f15tn/Proc/CPU/Family/0x15/TN/F15TnIoCstate.c:139:5: error: dereferencing type-punned pointer will break strict-aliasing rules [-Werror=strict-aliasing]
     ((CSTATE_ADDRESS_MSR *) &LocalMsrRegister)->CstateAddr = PlatformConfig->CStateIoBaseAddress;
     ^
src/vendorcode/amd/agesa/f15tn/Proc/CPU/Family/0x15/TN/F15TnIoCstate.c: In function 'F15TnCreateAcpiCstObj':
src/vendorcode/amd/agesa/f15tn/Proc/CPU/Family/0x15/TN/F15TnIoCstate.c:283:5: error: dereferencing type-punned pointer will break strict-aliasing rules [-Werror=strict-aliasing]
     CstBodyPtr->RegisterAddr   = ((CSTATE_ADDRESS_MSR *) &MsrData)->CstateAddr + 1;
     ^~~~~~~~~~
cc1: all warnings being treated as errors
make[2]: *** [Makefile:337: g505s/libagesa/vendorcode/amd/agesa/f15tn/Proc/CPU/Family/0x15/TN/F15TnIoCstate.o] Error 1
make[2]: Leaving directory '/home/user/heads/build/coreboot-4.7'
make[1]: *** [Makefile:356: /home/user/heads/build/coreboot-4.7/g505s/.build] Error 1
make[1]: Leaving directory '/home/user/heads'
Makefile:559: recipe for target 'all' failed
make: *** [all] Error 2

[tlaurion]

@awokd : Coreboot 4.8.1 hasn't been merged into Heads yet...

git remote add kylerankin https://github.com/kylerankin/heads
git remote add flammit https://github.com/flammit/heads
git merge flammit/coreboot-4.8 
make BOARD=x230 modules.clean
make BOARD=x230 -j4

[tlaurion]

@awokd: coreboot 4.8.1 is merged.
Is there any advancements?

[awokd]

Thank you, I will try it again when I get a few!

[zamaudio]

I used to have this laptop and co-authored the coreboot port for it. Unfortunately I no longer have the hardware and it's quite rare around here even on the second hand market :(

[awokd]

Damien Zammit wrote on 12/27/18 4:02 AM:

I used to have this laptop and co-authored the coreboot port for it. Unfortunately I no longer have the hardware and it's quite rare around here even on the second hand market :(

Nice, thanks for stopping by! My "lab" is in storage at the moment, but I should be able to get back to work on this in a month or so.

[awokd]

Attempted the compile again, but although it worked in Coreboot, in Heads it failed with the same error as above:

src/vendorcode/amd/agesa/f15tn/Proc/CPU/Family/0x15/TN/F15TnIoCstate.c:139:6: error: dereferencing type-punned pointer will break strict-aliasing rules [-Werror=strict-aliasing]

I think it might be due to Coreboot respecting src/vendorcode/amd/agesa/f15tn/Makefile.inc which contains:

CFLAGS_x86_32 += -march=k8-sse3 -mtune=k8-sse3 -fno-zero-initialized-in-bss -fno-strict-aliasing
CFLAGS_x86_64 += -march=k8-sse3 -mtune=k8-sse3 -fno-zero-initialized-in-bss -fno-strict-aliasing

while Heads might not. How can I persuade Heads to include that Makefile.inc?

[awokd]

I was able to get past the warning above by running ~/heads/build/coreboot-4.8.1$ /home/user/heads/build/make-4.2/make obj=/home/user/heads/build/coreboot-4.8.1/g505s DOTCONFIG=/home/user/heads/build/coreboot-4.8.1/g505s/.config BUILD_TIMELESS=1 CFLAGS_x86_32="-fdebug-prefix-map=/home/user/heads=heads -gno-record-gcc-switches -Wno-error=strict-aliasing" CFLAGS_x86_64="-fdebug-prefix-map=/home/user/heads=heads -gno-record-gcc-switches -Wno-error=strict-aliasing". However, now it's failing further on with:

    CC         libagesa/vendorcode/amd/agesa/f15tn/Proc/Mem/Main/mu.o
src/vendorcode/amd/agesa/f15tn/Proc/Mem/Main/mu.c: In function 'MemUWriteCachelines':
src/vendorcode/amd/agesa/f15tn/Proc/Mem/Main/mu.c:135:3: error: unknown type name '__m128i'; did you mean '__int128'?
   __m128i *Src = (void *) Pattern;
   ^~~~~~~
   __int128
src/vendorcode/amd/agesa/f15tn/Proc/Mem/Main/mu.c:136:3: error: unknown type name '__m128i'; did you mean '__int128'?
   __m128i *Dest = (void *) (size_t)Address;
   ^~~~~~~
   __int128

Should I wait and try again once coreboot 4.9 is merged?

[tlaurion]

@awokd : what is the building distro?

[tlaurion]

@awokd : have you tested this?

[tlaurion]

and merged this?

[awokd]

Thank you, #445 (comment) fixed it. I should have seen that! It's getting through the compile now and only failing because bzImage is too big at 4830305 bytes while my largest free region in CBFS is 3299032 bytes. I've already disabled PGP, anything else I can to shrink it further? I'm thinking TPM and FLASHROM since this laptop doesn't have TPM and only has the single 4MB flash chip.

export CONFIG_COREBOOT=y
CONFIG_COREBOOT_CONFIG=config/coreboot-g505s.config
CONFIG_LINUX_CONFIG=config/linux-g505s.config

CONFIG_CRYPTSETUP=y
CONFIG_FLASHROM=y
CONFIG_FLASHTOOLS=y
# CONFIG_GPG=y
CONFIG_KEXEC=y
CONFIG_UTIL_LINUX=y
CONFIG_LVM2=y
CONFIG_MBEDTLS=y
CONFIG_PCIUTILS=y
CONFIG_POPT=y
CONFIG_QRENCODE=y
CONFIG_TPMTOTP=y
CONFIG_DROPBEAR=y

CONFIG_LINUX_USB=y
CONFIG_LINUX_E1000E=y

[tlaurion]

4MB flash is really limited. Heads, without a TPM/LibremKey can't perform firmware measurements. GPG is required to sign /boot files. But that would require more space to have LibremKey support and GPG2 config.

Are all G505S are found with 4MB flash? I doubt anything is really possible in such limited space.

You could get rid of dropbear:
#CONFIG_DROPBEAR=y

Since you do not have a TPM, you could get rid of:

#CONFIG_POPT=y
#CONFIG_QRENCODE=y
#CONFIG_TPMTOTP=y

and add:
CONFIG_TPM=n

Then try to use merge this PR to use the LibremKey as a TPM replacement, but that again would probably use more then available space.

You would otherwise get Heads without firmware measurements and integrity attestation. :/

[awokd]

Well, getting rid of those and not adding LibremKey still only got it down to 4603489 bytes. :( Yes, I think they are all 4MB only. I could maybe put Heads' bzImage on a fixed disk, but that would make it more vulnerable to tampering...

[awokd]

Thinking some more, there are only three models of this laptop varying only by GPU options. I'm going to try to strip down the Linux config to the bare minimum needed to support just this laptop. "[F]irmware measurements and integrity attestation" are more important to me than networking support on boot, for example.

[awokd]

Trimming the Linux config shaved off ~400KB, but I'm still close to 1MB short. I'm afraid we'll need to shelve this idea. :(

[tlaurion]

@awokd : would be nice if you posted your used board config and any other files you changed for the record :)

[mikebdp2]

@awokd Hi there 😉 What is your current Linux config? I think it could be trimmed even more, and there might be some Linux kernel fork for space-constrained environments. Also, what compression you are using - LZMA ? By the way, it might be possible to update G505S BIOS chip from 4MB to 8MB or even 16MB, but that's pretty hard to do without a special equipment (our friend damaged a copper track on his G505S while trying to do that) and even if you'll succeed, the other people with 4MB chips wouldn't be able to get involved in your project until these space issues are resolved. So you should try your best to solve this.

[awokd]

Here are my preliminary config files. I used the kgpe-d16 ones as a template and removed EXTRA_FLAGS from compiler options per #445 (comment).

These are: modules/coreboot, boards/g505s/g505s.config, config/coreboot-g505s.config, config/linux-g505s.config. It compiles but fails at CBFS insert because it's too large, so it's untested. Some of those Linux options I disabled might still be required for some reason.

g505s.zip

Hi @mikebdp2 ! If there's something I'm overlooking in the Linux config, please let me know. Not much fat in there as far as I can tell. I am using whatever compression Heads defaults to. I remember your email on Coreboot's mailing list saying the newer version of LZMA had better results, but it would have to be a lot better to go from 4MB to 3MB.

I see in the reference above there might be graphics files somewhere that could be trimmed?

[awokd]

Your recent email reminds me, would it be compatible with Heads' threat model to chainload from Corebooted flash to a burnt DVD with the kernel? I think most of these had DVD drives. There is also an SD card reader on USB 2.0; I think those can be write-protected.

[tlaurion]

Interesting idea for SDcard chainloading.

That would require some additional kernel modules integration (look for SDHCI)

I still think the first step should be #590

[mikebdp2]

@awokd sorry for a really late reply! I wonder - why this TPM stuff is taking so much space? Maybe cut out some not-essential functions? Also, upgrading LZMA to a newer version is unlikely to give a 1MB, so you'll need to look at the alternative compression like paq8px and implement it to coreboot. A decompressor would also need to be small enough. Overall: this is possible, but could significantly prolong a boot time - i.e. an extra one minute. These alternative (de)compressors could be quite strong and aren't widely used only because of a turtle decompression speed - but with sizes like 4MB it hopefully won't be as noticeable.

[tlaurion]

I wonder - why this TPM stuff is taking so much space?
@mikebdp2 : TPM stuff?

Heads relies on TPM (measured boot) and GPG2 for signed /boot digest (from USB Security dongle), verified against public key inserted in ROM, which is also measured by TPM.

As replied in other tickets you opened, without a TPM or any other root of trust for firmware measurements in romstage (in cache, prior to ramstage) there would be no root of trust, as other binaries could be tampered with and there would not be any way of knowing.

The heavy parts under heads are the GPG toolset (take a look at modules/* and dependencies of gpg2).

Take a look at #590 :)