Coreboot Update for APU1

stephenw10

Ah, that's interesting. Had no idea those were there.

I assume you used the apu1 binary?

Did you use 4.8.0.1? Did you have to disable MSI? That seems unclear, since it's newer that 4.6.7....

Steve

jahonix

@stephenw10 Surely I used the APU1 file.
Flashed it with the TinyCore Installer from a dedicated USB stick. I had to use the "forced board mismatch" option, though.
Rebooted straight into my mSATA based pfSense install on both productive devices afterwards without enabling/disabling/changing anything.
0_1531493319238_APU1 screenshot.png

BTW: Infos (about repo etc.) taken from their site.

jahonix

I was able to install pfSense onto 2 different mSATA disks within these patched APU1s which wasn't possible previously. Both booted immediately without having to change anything. FWIW

interessierter

Hello all

First thanks for the answers. I don t want to leave the BIOS alone. As we all know, there where several security problems in CPU, and so updates to the Microcode available. So I think it s the total wrong approach to leave the bios on a Firewall box with potential security problems alone, but keep the pfsense software up2date.

Can someone guide me to the right firmware here? I m afraid to destroy the board

thanks

stephenw10

It's good to be aware of security risk certainly. But when you find an issue you need to assess what actual risk that poses and how it impacts your particular situation.
What exactly do you think you will gain by updating Coreboot?

If you are trying to boot an undetectable device that is detected by later versions that's a good reason to update. IMO at least.

Also note that PCEngines suggest here:
For FreeBSD based OS like OPNSense and pfSense please use the legacy versions.

There is no legacy version listed for apu1.

Steve

stephenw10

I have now tested this. I can afford to be without the APU had it failed to come back up.

I flashed it using flashrom from within pfSense (2.4.4a). I had to force the board override and specify the chip type.

It did come back up fine at 4.8.0.1.

The only anomaly I see is the console output is doubled before the kernel loads. I did read something about that in notes....

Steve

jahonix

@stephenw10 How did you do that?
For me flashrom wasn't able to find the flashable chip and exited, no matter what I tried. But I was on the initial firmware years old when I tried.

stephenw10

Nothing special I installed it and it found the chip but couldn't determine the exact type, I had to use the -c parameter to do so. It's a MX25L1606E on my board.
Needs to be flashrom 1.0 maybe? That's in 2.4.3 but I am running 2.4.4a .

[2.4.4-DEVELOPMENT][root@apu.stevew.lan]/root: flashrom -p internal -c MX25L1605A/MX25L1606E/MX25L1608E
flashrom v1.0 on FreeBSD 11.2-RELEASE (amd64)
flashrom is free software, get the source code at https://flashrom.org

Using clock_gettime for delay loops (clk_id: 4, resolution: 70ns).
coreboot table found at 0xdfd79000.
Found chipset "AMD SB7x0/SB8x0/SB9x0".
Enabling flash write... OK.
Found Macronix flash chip "MX25L1605A/MX25L1606E/MX25L1608E" (2048 kB, SPI) mapped at physical address 0x00000000ffe00000.
No operations were specified.

Steve

interessierter

@stephenw10 For me it was driven my the Intel Architecture security problem however, I think I can only be safe when I use the latest and greatest bits. In a dangerous online world, it works so leave it alone is a wrong way on a firewall applicance. Just my two cents on this.

Is there a guide available to do it?
thanks

stephenw10

Right but how is, for example, Spectre/Meltdown actually impacting you?

Do you have multiple users on your firewall?

Are you running bhyve VMs or jails on your firewall?

What risk are you actually trying to mitigate?

IMO you're probably actually risking more by upgrading to a newer BIOS than by remaining on the existing BIOS. You are obviously free to do so though. And it went smoothly for me.

Steve

interessierter

I want to close this risk simply
howto is available?

thanks

stephenw10

Ok, to be completely clear this is unnecessary in my opinion and although it ran fine for me it may not for you.
If this bricks your APU I assume you have something you can replace it with and a backup of your config.
This is what I did:

Download the bios file from here.
Extract the .rom and .md5 files and copy them to the root directory on the APU. I used SCP to do that. You could also fetch the file and extract it directly at the command line on the firewall.
Check the file checksum matches the MD5:

[2.4.4-DEVELOPMENT][root@apu.stevew.lan]/root: md5 apu1_v4.8.0.1.rom
MD5 (apu1_v4.8.0.1.rom) = dc5591bb2c9ff34608152bd4c7c806f7
[2.4.4-DEVELOPMENT][root@apu.stevew.lan]/root: cat apu1_v4.8.0.1.rom.md5 
dc5591bb2c9ff34608152bd4c7c806f7  apu1_v4.8.0.1.rom

Backup the existing rom:

[2.4.4-DEVELOPMENT][root@apu.stevew.lan]/root: flashrom -p internal -c MX25L1605A/MX25L1606E/MX25L1608E -r backup.rom
flashrom v1.0 on FreeBSD 11.2-RELEASE (amd64)
flashrom is free software, get the source code at https://flashrom.org

Using clock_gettime for delay loops (clk_id: 4, resolution: 70ns).
coreboot table found at 0xdfd79000.
Found chipset "AMD SB7x0/SB8x0/SB9x0".
Enabling flash write... OK.
Found Macronix flash chip "MX25L1605A/MX25L1606E/MX25L1608E" (2048 kB, SPI) mapped at physical address 0x00000000ffe00000.
Reading flash... done.

Copy that off the firewall.

Write the new rom to the flash:

[2.4.4-DEVELOPMENT][root@apu.stevew.lan]/root: flashrom -p internal -c MX25L1605A/MX25L1606E/MX25L1608E -w apu1_v4.8.0.1.rom
flashrom v1.0 on FreeBSD 11.2-RELEASE (amd64)
flashrom is free software, get the source code at https://flashrom.org

Using clock_gettime for delay loops (clk_id: 4, resolution: 70ns).
coreboot table found at 0xdfd79000.
Found chipset "AMD SB7x0/SB8x0/SB9x0".
Enabling flash write... OK.
Found Macronix flash chip "MX25L1605A/MX25L1606E/MX25L1608E" (2048 kB, SPI) mapped at physical address 0x00000000ffe00000.
Reading old flash chip contents... done.
Erasing and writing flash chip... Erase/write done.
Verifying flash... VERIFIED.

Reboot and hope nothing went wrong! It probably won't but subtle differences in hardware can come into play. I've done it twice now to get those console logs and had no issue.

Steve

stephenw10

@stephenw10 said in Coreboot Update for APU1:

The only anomaly I see is the console output is doubled before the kernel loads. I did read something about that in notes....

That was here: https://github.com/pcengines/apu2-documentation/blob/master/docs/pfSense-install-guide.md#pfsense-image

jahonix

@interessierter said in Coreboot Update for APU1:

howto is available?

ja, das steht alles auf den Seiten von PCengines. Einfach dort nachlesen, ist nicht so schwierig.
(with that nic you can surely read & understand German).

jahonix

@stephenw10 This is all I get from within FreeBSD no matter if I put the "-c" parameter there or not

flashrom -p internal -c MX25L1605A/MX25L1606E/MX25L1608E
flashrom v1.0 on FreeBSD 11.1-RELEASE-p10 (amd64)
flashrom is free software, get the source code at https://flashrom.org

Using clock_gettime for delay loops (clk_id: 4, resolution: 70ns).
coreboot table found at 0xdfd79000.
Found chipset "AMD SB7x0/SB8x0/SB9x0".
Enabling flash write... OK.]
No EEPROM/flash device found.
Note: flashrom can never write if the flash chip isn't found automatically.

However, using the TinyCore installer with a dedicated USB stick worked on both these boards. But I don't recall which flash chip was actually found on my APU1s.

stephenw10

I had to pull out a torch and check manually. I could believe they used different chips during the build life.

I was using 2.4.4 also. I don't believe flashrom is any different there but...

Steve

VAMike

It's an AMD CPU, it was never affected by meltdown and there is no firmware fix for meltdown. The spectre mitigations require both an updated CPU microcode as well as OS support. AFAIK this combination doesn't exist for pfsense and the T40E in the APU. (If it did, the OS is capable of loading the microcode update regardless of the firmware.)

Short answer: you're wasting your time.

interessierter

thats a good one
thank you

jahonix

@vamike said in Coreboot Update for APU1:

Short answer: you're wasting your time.

I did the update myself and, as noted before, there are severe benefits for doing so. Booting from previously unsupported mSATA drives for example.
For me it was absolutely worth it.

VAMike

@jahonix said in Coreboot Update for APU1:

@vamike said in Coreboot Update for APU1:

Short answer: you're wasting your time.

I did the update myself and, as noted before, there are severe benefits for doing so. Booting from previously unsupported mSATA drives for example.
For me it was absolutely worth it.

Sure, if you need functionality in a newer version then go for it. If you're doing it for vague reasons of "security", no.