[coreboot] AMD Lenovo G505S board status update! + board_status.sh discussion

Mike Banon mikebdp2 at gmail.com
Tue Apr 10 23:56:30 CEST 2018

Hi friends! I have submitted a new board status update for Lenovo
G505S laptop. The previous one was exactly 6 month old and I started
worrying that our wonderful quad core AMD laptop without Intel ME /
AMD PSP hardware backdoors - could be removed ; not because of the
lack of users (in fact, there are a lot of G505S+coreboot users!) ,
but just because of the lack of board status updates :P Three primary
obstacles I had to overcome while submitting:

1) board_status.sh is trying to tell too much information about your system :

cbfs.txt          coreboot_console.txt     payload_config.txt
config.short.txt  coreboot_timestamps.txt  revision.txt
config.txt        kernel_log.txt           rom_checksum.txt

Two of these files - coreboot_console.txt and especially
kernel_log.txt - could contain some information which is very private:
in my case, kernel_log.txt contained the MAC address of my Ethernet
card, both coreboot_console.txt and kernel_log.txt contained the model
of my USB flash drive - knowing a model helps to figure out the
controller and raises the possible success of some targeted BadUSB
attack against the submitter, and so on

Maybe this is why some coreboot users do not want to use this script,
a very important one :P But there is an easy solution:

To pause the board_status.sh script just before it uploads the logs,
so that I could personally look through them and remove the parts of
information that I consider as private, I have inserted the following
lines just before the "echo "Uploading results" at ~440 line:

    stty -echo
    printf "Press_any_key_1...: "
    read variable1
    stty echo
    printf "\n"
    sleep 1
    stty -echo
    printf "Press_any_key_2...: "
    read variable2
    stty echo
    printf "\n"
    sleep 1

I run a board_status.sh script, it collects the logs and puts them
inside the freshly cloned board-status repository, then a script
pauses, I could edit the logs until I consider them as OK, and then
give a "go ahead" command by pressing the any key two times, and only
then a script does the "git add" of them and commits the upload

2) board_status.sh - "Verifying that CBMEM is available" part at
380-390 lines is broken, in particular, line 381 " sudo command -v
"$cbmem_cmd" >/dev/null " tells that command not found - perhaps this
'command' command is not available at some linux distros. I had to
comment out this code, leaving only cbmem_cmd="sudo $cbmem_cmd" line:

    echo "Verifying that CBMEM is available"
#    if [ $(id -u) -ne 0 ]; then
#        sudo command -v "$cbmem_cmd" >/dev/null
#        if [ $? -ne 0 ]; then
#            echo "Failed to run $cbmem_cmd using sudo. Check \$PATH
or use -c" \
#            "to specify path to cbmem binary."
#            exit $EXIT_FAILURE
#        else
            cbmem_cmd="sudo $cbmem_cmd"
#        fi
#    else
#        test_cmd $LOCAL "$cbmem_cmd"
#    fi

and the rest of board_status.sh script is working, after I supply a
path to cmbem executable file, which is obtained by going to
./util/cbmem/ directory and running "make"

3) Despite that I have not modified the coreboot source code, just the
couple of changes to config all through "make menuconfig" + some
floppies added AFTER the build, I still got a "-dirty" added to my
version while building. Maybe some bug there? git diff does not show
anything interesting, there were no local changes (except the
board_status.sh but that happened much later). Did not like that
"-dirty" as it was unfair, and fixed the already-submitted board
status to become clean with a follow-up commit. Know thats a bit of
cheating, but though it was OK to do in such a situation, as I have
not modified anything at the sources that could have changed the
working status of that build

Best regards,
Mike Banon

More information about the coreboot mailing list