Announcement

Collapse
No announcement yet.

EFITools Ported To 32-Bit To Work With Secure Boot On Intel's Quark SoC

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

  • EFITools Ported To 32-Bit To Work With Secure Boot On Intel's Quark SoC

    Phoronix: EFITools Ported To 32-Bit To Work With Secure Boot On Intel's Quark SoC

    While James Bottomley's efitools package has traditionally been x86_64-only, he ended up porting the package to x86 32-bit in order to handle bringing up UEFI Secure Boot on the Intel Quark SoC board...

    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
    Coreboot

    Intel should just add Intel Quark support to Coreboot.

    Comment


    • #3
      Cheap ARM boards have major advantage - you do not have to deal with this shit.

      Seriously, BIOS or UEFI is worst part about dealing with x86 systems at all. These bugged proprietary chunks of code MUST DIE.

      And secure boot is a misnomer: as long as firmware implementing it is proprietary blob of suspicious code, its can't be "secure" at all. TBH, cheap chinese ARM boards have serious advantage: neither they do fuck my brain with this secure boot shit nor most of them dares to insist on huge proprietary blobs to start system up. Sure, there're some few exceptions, but most of them just far more comfortable than x86/UEFI crap.

      Comment


      • #4
        Do any one of them open the early boot loader (pre-uboot)? I recall only Allwinner has that part open, with all other ARM vendors supplying a blob.

        Comment


        • #5
          Originally posted by curaga View Post
          Do any one of them open the early boot loader (pre-uboot)? I recall only Allwinner has that part open, with all other ARM vendors supplying a blob.
          Please define "all other" ARM vendors? You have told allwinner as example. And there're plenty boards and modules using AW thanks to good peripherals, nice community and cheap prices. Then, for example, Ti OMAP would use so called X-Loader (extremely reduced u-boot version to fit 1ts few NAND blocks) which would then start more complicated u-boot in RAM. Actually u-boot got generic notion of "SPL", which is small preloader code which is loaded by ROM to limited onchip SRAM, executed 1st, does DRAM init and loads larger, smarter code (like "full" u-boot) to main system DRAM, once it available. If I remember, i.MX also can be started from just u-boot.

          In fact it can be more complicated. Say NAND or SD-card are not executable on its own unlike say parallel NOR Flash. So in these cases chip usually starts from internal ROM, this ROM does some tasks like reading "complicated" medium, getting boot code out of there and executing it. Here we come to yet another question: how much internal ROM haves and what it does. Say allwinner would have very small and trivial ROM which only reads few sectors at fixed location and executes that. Simple and not harmful. Ti would have far more complicated code, with "secure" part wihch can't be obtained or verified and they would not let their secure boot to serve "Average Joe" for some weid reason, only thinking it ok to be used by few huge corps. iMX would have really complex ROM with huge secure boot framework. But it at least documented and as long as your CPU is not yet fused, you can get this monster on your side, if that's what you want to. So it would accept YOUR secure boot hash of key as root of authority and would refuse all other code.

          Then some strange vendors like RockChip can have quite strange boot sequences where ROM calls user code but expects return or so. Things like these can rely on some blob-only code to do, say, DRAM init. Not something great to my taste.

          Speaking for myself,
          1) I would not trust huge ROMs, so I would rather prefer Allwinner from this point due to very simple boot sequence which is easy to audit. And if I'll need some "security" in boot phase, I better about to put u-boot with my own public key to readonly media and then let it load signed images/configurations only. And readonly medium would not allow attackers to replace boot and builtin public key it uses. Boot ROM is hard to avoid completely for some boot sources. But it can be small enough to be 100% verifiable.

          Good parts about ROMs is that most of them will get lost forever once your code takes control and they would no longer interfere. So most of them are not "resident" and can't do anything harmful at run time. Though on some ARMs with activated and used TrustZone it can happen you have to run resident code and it is big question if particular vendor will let you into truzt zone. My least favorite here will be Samsung. These bastards would only load binary blob loaders from samsung AND only blob-only TrustZone code signed by Samsung. Needless to say, one should be real idiot to "trust" some unchangeable, blob-only code which runs all the time SoC runs.

          2) Obviously I'm not a big fan of blobs in further boot sequence either. But similar to ROM, once they done their jobs, they vanish "forever" and no longer influence anything. Yet, this nasty crap can pose some limitations on ways you're booting.

          What's wrong with intel? They use implementation which took absolute worst of all worlds. Huge proprietary blob without soruces which is too big to be checked via disassembly is a requirement to boot system up. Secure boot crap, which could\would bother even those who does not needs it even a second. Overcomplicated UEFI shit, which gives over 9000 methods for firmware to subvert OS loaded and make it far less secure than anticipated. They also tend to preinstall some foreign keys (like MS keys) you're supposed to "trust".

          In short, this Intel's weirdling lacks any noteworthy properties but requires way too much attention, contains too much suspicious crap and poses way too much potential issues. So speaking for myself I'll better go buy some few more these neat chinese modules at unbeatable $30/board on CPU where I do understand boot sequence and damn sure it would do only what advertised.

          Comment

          Working...
          X