Announcement

Collapse
No announcement yet.

AMI Is The Latest Vendor Joining The Linux Vendor Firmware Service

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #21
    This is certainly useful but ultimately nit that important if the firmware is still opaque blobs. We need more machines like the Talos where you can actually trust the firmware.

    Comment


    • #22
      The BIOS updates are also signed, both by LVFS(with GPG) and the manufacturer. Fwupd verifies signatures, and hopefully so does UEFI during upgrading.

      Also, it's not just gnome software and fwupdmgr that let you use fwupd. KDE Plasma 5.14 includes fwupd integration in Discover. Once that version trickles down to distributions, a lot more users will be covered

      Comment


      • #23
        Originally posted by schmidtbag View Post
        If you were aware that you are using a faulty/malicious BIOS, you can just simply pop out the CMOS battery or revert to the backup ROM. If you were to download the update manually (outside of the built-in tool) and it happens to be malicious then it doesn't matter whether you use the built-in utility or run one from the OS.
        Popping out the CMOS battery does jackshit to firmware written on a flash chip.

        Afaik only Gigabyte has backup ROM, and I've always had to do stupid shit like shorting pins around to "convince" it to boot the backup ROM so I would not really recommend it.

        Flashing a UEFI firmware manually with a hardware flasher is a major PITA as in many cases the "bios image" isn't a flash dump and only the onboard updater (or people who spent time reverse-engineering the bios image or have signed an NDA) can flash it right.

        If you have a flash dump you took whn the device was new, then you can flash that again.

        Comment


        • #24
          Originally posted by tomtomme View Post
          Asrock shares the same tech. Its nice yes. But I wonder how secure the code is...
          It rather secure due to two things :

          - on UEFI based machine, the flashing capability is only available during boot while in the firmware menu (while you select EZ-Flash from the boot menu). Upon booting an OS the UEFI locks itself (i.e.: right before executing /EFI/boot/boo64.efi, the chipset locks access to firmware flashing and to signing keys)
          That's also the reason why installing a personnal key for secure boot is complicated and can't simply be done by the installer.

          Thus there's no way a virus (running from the OS) could abuse EZ-Flash to write itself.

          - nearly all Flasher I've seen control a checksum and a signature in the flash file before proceeding to flash (and also check if the flash file targets the same platform). Then in case of failure, they either show big warnings and ask for user override confirmation, or outright refuse to flash the file.

          Now, this all boils down to how well thats crypto is implemented. I hope you motherboard doesn't use MD4 as a checksum, and 512-bit wide RSA keys for the signature (with a buffer overflow exploitable to skip the whole thing).

          Originally posted by debianxfce View Post
          Gnome software is buggy as hell and then you have unbootable system with a corrupted bios. It is idiotic to trust gnome developers when updating your bios. Your gnome Linux can hang, crash etc during flashing.
          As mentioned above, modern UEFI machines have a peculiar locking strategy. You *cannot* flash a UEFI firmware from the OS. There's no way for bugs in Gnome to corrupt the firmware.
          UEFI firmware "updating" is merely leaving a flash file in a predefinite location and reboot the machine to have the UEFI firmware flash itself (again, flashing capability is only available while the UEFI is running).
          The OS-based update (be it Windows with some vendor's SETUP.EXE, Linux's fwupd, or the MS-DOS boot disk for the last couple of enterprise vendor that still provide such) is merely a wrapper that automate the manual "put the file in a FAT partiton and select EZ-Flash from the boot menu" procedure.
          Actually writing into the flash chip from within the OS has stoped existing right around the time when BIOS-based firmwares (with an optional mini EFI payload) got phased out.

          You Gnome crashes : ...and nothing will happen.
          You Gnome silently corrupts the data : ... and the in-firmware UEFI flasher will simply reject the flash file due to checksum/signature mismatch upon the next reboot.
          (Then if you override and ask the flasher to flash an obviously corrupt image despite the red flashing warning box, you deserve whatever you got).

          Originally posted by Ardje View Post
          My gigabyte wanted to update using ms-dos... But it wouldn't using pxe, it wouldn't using usb flash and it wouldn't using any other way, since the floppy drives were already broken.
          Ah, yeah. One of those that stil rely on a BIOS-based firmware that only has a small horrendously buggy EFI payload started by the BIOS.
          I have a couple of such (a GA-990FXA-UD7 and an older GA-MA790FX-DQ6, usually the rev 1.0 of the boards - by the rev 3.0 of the boards Gigabyte has switched the other way around : a UEFI-based firmware that has a CSM (Compatibility Support Module) for Legacy BIOS compatibility mode).
          Even their BIOS is horrendously buggy and has trouble detecting USB HDD devices.

          Actually these type of BIOS bugs are known to SYSLINUX, and there is a trick to circumvent it that relies on making the BIOS think that you have a USB ZIP drive by using ZIP-style CHS geometry (64 heads, 32 sectors, DOS partition 4 is used - though in the specific case of Gigabyte, the partition number is not checked). You can use mkdiskimage -s -z -4 /dev/{your USB device} to achieve this.

          Though you need an OS that uses LBA addressing (since the CHS geometry is going to be wrong). Linux and Grub works nicely, the BIOS' EZ-Flash works too, but FreeDOS has occasional corruptions.

          For your bios updates problems, you can either try to see if the DOS used by gigabyte works with such franken-zip USB flash OR simply use Grub to boot the floppy image (use grub's memdisk) OR boot into the firmware's EZ-Flash which now is suddenly able to see USB drive.

          Originally posted by starshipeleven View Post
          Afaik only Gigabyte has backup ROM, and I've always had to do stupid shit like shorting pins around to "convince" it to boot the backup ROM so I would not really recommend it.
          Gigabyte is the only vendor to provide a whole fricking ROM as a backup (they basically have twice the amount of space on the flashchip, in order to save 2 copies).
          But every single vendor as a barebone boot loader as a backup that can do a flash using specific procedure
          (something along the lines of "rename the flashfile as 'RESCUE.BIN', put it as a single lone file on either a FAT formater floppy or a FAT32 formated USB stick, connect the floppy drive on A: or put the USB flash straight into one of the ports at the back without hubs, and keep holding the "insert" key while booting the machine" have actually done that after breaking the BIOS when uploading custom logo).

          Originally posted by michaelb1 View Post
          Lets ignore these measly handouts and go open source in a real way! coreboot/libreboot open source BIOSes (with SeaBIOS payload) , and flashrom open-source flashing tool
          Sorry to bring you back to the reality, but SeaBOIS is used to provide a classical BIOS firmware on Coreboot. Nobody has been using that for the past decade.
          Either you'd need Tianocore (to provide an UEFI firmware implementation as anybody else is used to)
          Or one of the "boot straight into Grub / into Linux kernel / etc." payloads.

          Comment


          • #25
            Originally posted by DrYak View Post
            But every single vendor as a barebone boot loader as a backup that can do a flash using specific procedure
            (something along the lines of "rename the flashfile as 'RESCUE.BIN', put it as a single lone file on either a FAT formater floppy or a FAT32 formated USB stick, connect the floppy drive on A: or put the USB flash straight into one of the ports at the back without hubs, and keep holding the "insert" key while booting the machine" have actually done that after breaking the BIOS when uploading custom logo).
            This is arcane and supersitious rituals based on half-assed generic documentation from the vendor and fragmented direct reports of workign examples which may or may not be what is actually done in the hardware.
            Like for example this holy text https://www.bios-mods.com/bios-recov...bios-recovery/

            Did you have better sources for these arcane rituals?

            Comment


            • #26
              Originally posted by starshipeleven View Post
              Did you have better sources for these arcane rituals?
              In most cases: The actual documentation which came with the actual motherboard in question.
              (And the "rescue" behaviour hasn't been modified between the time the manual was printed and whatever BIOS update was currently installed)

              In one case (missing manual) I had to download the latest manual from the motherboard manufacturer's site (SuperMicro).

              In my experience, the rescue is about the only thing where the printed manual more or less matches what you'll see in the actual hardware.
              (Unlike, say every single screen shot and description of every BIOS setting option - I have yet to see one where manual and real world match)

              My suspicion is that the rescue is actually on a non-upgradable ROM (as opposed to flash) and thus never gets modified by any BIOS update, but I don't have anything to test this hypothesis.
              (I might also be that the engineer never see any need to change that bit of the flash image so it's kept constant across versions, or its stored in a different EEPROM "partition" that never gets upgraded)

              But I see what you mean with your sarcastic comment (manual and actual BIOS on the machine never actually matching).

              Comment


              • #27
                Originally posted by starshipeleven View Post
                Popping out the CMOS battery does jackshit to firmware written on a flash chip.
                Depends on the board. But, I guess it was wrong for me to generalize to such a degree.
                Afaik only Gigabyte has backup ROM, and I've always had to do stupid shit like shorting pins around to "convince" it to boot the backup ROM so I would not really recommend it.
                Gigabyte is not the only one with backup ROMs, but they're the ones who popularized it.
                Flashing a UEFI firmware manually with a hardware flasher is a major PITA as in many cases the "bios image" isn't a flash dump and only the onboard updater (or people who spent time reverse-engineering the bios image or have signed an NDA) can flash it right.
                I was referring to the flash utility built into the motherboard, not using an external flasher. But yeah you're right - hardware flashers are a PITA and in most cases aren't worth using.

                Comment


                • #28
                  Originally posted by DrYak View Post
                  In most cases: The actual documentation which came with the actual motherboard in question.
                  (And the "rescue" behaviour hasn't been modified between the time the manual was printed and whatever BIOS update was currently installed)
                  Weird, I never found that in the manuals when I needed it

                  My suspicion is that the rescue is actually on a non-upgradable ROM (as opposed to flash) and thus never gets modified by any BIOS update, but I don't have anything to test this hypothesis.
                  (I might also be that the engineer never see any need to change that bit of the flash image so it's kept constant across versions, or its stored in a different EEPROM "partition" that never gets upgraded)
                  No it's a on the same flash chip. They call it "boot block" and is a minimal firmware that initalizes very basic stuff only and is not overwritten ever

                  Comment


                  • #29
                    Originally posted by DrYak View Post
                    Sorry to bring you back to the reality, but SeaBIOS is used to provide a classical BIOS firmware on Coreboot. Nobody has been using that for the past decade. Either you'd need Tianocore (to provide an UEFI firmware implementation as anybody else is used to) . Or one of the "boot straight into Grub / into Linux kernel / etc." payloads.
                    I am pretty sure SeaBIOS is more popular than Tianocore, it is proven reliable solution which has a relatively small and elegant source code, and perhaps that's why SeaBIOS is the default coreboot payload. Yes, you can use Tianocore if you would like, but there are relatively few coreboot people are doing that and in case of the problems less people will be able to help you

                    Comment


                    • #30
                      Originally posted by michaelb1 View Post
                      I am pretty sure SeaBIOS is more popular than Tianocore,
                      I'm pretty sure it's more popular only for the lazy, people that actually care use GRUB2 payload.

                      Comment

                      Working...
                      X