Announcement

Collapse
No announcement yet.

Broadwell-DE SoC / Xeon D Support Added To Coreboot

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

  • Broadwell-DE SoC / Xeon D Support Added To Coreboot

    Phoronix: Broadwell-DE SoC / Xeon D Support Added To Coreboot

    While Xeon D (Broadwell-DE) hardware has been available for the past year, support for these SoCs is finally now in mainline Coreboot...

    Phoronix, Linux Hardware Reviews, Linux hardware benchmarks, Linux server benchmarks, Linux benchmarking, Desktop Linux, Linux performance, Open Source graphics, Linux How To, Ubuntu benchmarks, Ubuntu hardware, Phoronix Test Suite

  • #2
    There's at least one very good reason to use coreboot even if you're stuck with a property micro-controller blob: You can compile the UEFI rom without an ethernet \ wifi driver. That leaves the likes of Intel ME without a back door to open.

    Comment


    • #3
      Hope Coreboot gets support for Haswell and Skylake too and coming Kaby Lake.

      Comment


      • #4
        Originally posted by c117152 View Post
        There's at least one very good reason to use coreboot even if you're stuck with a property micro-controller blob: You can compile the UEFI rom without an ethernet \ wifi driver. That leaves the likes of Intel ME without a back door to open.
        If you are worried about backdoors, it's probably best to skip UEFI entirely and go to grub or an initram image. Not that I think it's malicious, but the codebase is so large and new there are bound to be nasty bugs that could be exploited by local processes.

        Comment


        • #5
          Originally posted by WorBlux View Post

          If you are worried about backdoors, it's probably best to skip UEFI entirely and go to grub or an initram image. Not that I think it's malicious, but the codebase is so large and new there are bound to be nasty bugs that could be exploited by local processes.
          That's technically impossible. The ME microcontroller has to be initialized first which is done using a property blob. The ME itself is looking for a UEFI header on the bios starting from the first SPI bit and then initializes the first section which has to be microcontroller opcodes signed by Intel. However, because the ME is generic between CPUs and can't interact with network interfaces it doesn't have drivers to, I thought it might be possible to at least make sure it doesn't have access to the lan by not loading it with network drivers.

          The only downside is that you wouldn't be able to do wake-on-lan from deep sleep states. But that functionality can be added using a separate hardware usb device that interacts with the LAN on the one end, and sends a keyboard like usb signal on the other end. BOM should be a couple of bucks and it could substitute the ME engine for this one job you actually want it for.

          Comment


          • #6
            Originally posted by c117152 View Post

            That's technically impossible. The ME microcontroller has to be initialized first which is done using a property blob. The ME itself is looking for a UEFI header on the bios starting from the first SPI bit and then initializes the first section which has to be microcontroller opcodes signed by Intel. However, because the ME is generic between CPUs and can't interact with network interfaces it doesn't have drivers to, I thought it might be possible to at least make sure it doesn't have access to the lan by not loading it with network drivers.

            The only downside is that you wouldn't be able to do wake-on-lan from deep sleep states. But that functionality can be added using a separate hardware usb device that interacts with the LAN on the one end, and sends a keyboard like usb signal on the other end. BOM should be a couple of bucks and it could substitute the ME engine for this one job you actually want it for.
            Huh, that's some pretty detailed information, thanks. I had the impression the FSP did the ME, CPU and RAM setup but once coreboot was done with whatever else it wanted to initialize it handed directly off to a payload. I know recent chromebooks/chromeboxes go from coreboot to depthcharge, which is tasked with finding and booting an OS even on hardware that typically uses UEFI otherwise. At the very least a TianoCore payload would have fairly fine-grained configuration options at compile-time.

            Comment


            • #7
              Originally posted by WorBlux View Post

              Huh, that's some pretty detailed information, thanks. I had the impression the FSP did the ME, CPU and RAM setup but once coreboot was done with whatever else it wanted to initialize it handed directly off to a payload. I know recent chromebooks/chromeboxes go from coreboot to depthcharge, which is tasked with finding and booting an OS even on hardware that typically uses UEFI otherwise. At the very least a TianoCore payload would have fairly fine-grained configuration options at compile-time.
              TianoCore is EFI executables, firmware drivers and shell. Mainly EFI boot loaders related. depthcharge is an EFI bootloader. They're unrelated to the ME bits.

              The sequence from boot is: ME physical micro-controller core seeks first bit on SPI flash bios (formatted as UEFI), ME loads drivers and such, ME initializes compute cores and the UEFI kernel. The UEFI kernel loads a few drivers and firmwares and eventually you have a UEFI bootloader that chainloads whatever you have on the disk.

              Intel implemented the PXE boot in the ME, and gave the UEFI setup and bootloader access to it. Intel also let the ME engine keep running while you power off your computer, and let it listen to the LAN for WOL packets and some encrypted backdoor stuff. The way to cut-off that backdoor, is to deny the ME core access to that lan by not letting it load a lan driver. You'd lose WOL functionality doing this. However, PXE functionality can be redone in the UEFI by writing UEFI lan drivers and PXE implementation. But that's a lot of work no one is willing to do.

              Hopefully, now that UEFI on ARM is being written, the PXE UEFI part will at least be available. Then it might be possible to port linux lan drivers for PXE.

              Comment

              Working...
              X