Typical example of how to do that, look at cell phones, or game consoles.
At the most basic, there's a hypervisor: a CPU running from internal mask ROM, including onboard keys (and some other obfuscation features, like extra metallization layers to frustrate decapping, and supply glitch reset circuitry). It only talks to the boot ROM. During boot, it checks if the code is encrypted and signed. If so, it decrypts it to RAM, and the CPU boots. Otherwise the CPU is held in reset. No functions are provided to control or manage the hypervisor, nor any BIOS functions are provided by it -- as these could provide a route to reading out its code.
What's an obvious problem with this? Well, if the update goes wrong, it's bricked. That kind of stinks. You might use a staged bootloader process, where there's a secured Flash area, that provides BIOS functions and a recovery screen; and maybe this region can be updated as well (hence Flash versus more mask ROM), but only with signed data (maybe the hypervisor could be called upon to validate a RAM buffer), and only when provided with a separate key (so that, if the bootloader is compromised, the hypervisor is not).
And so on; there are many convenience features that can be added, but each one must be checked for security, and not just individually, but against each other, because emergent patterns can arise even from individually-secure functions.
The hypervisor, by the way, would be a chip that you carefully control the design, production and distribution of. It's the key to making everything work. As it verifies and decrypts the boot ROM image (at least in part -- hopefully the whole thing, so that any aberration can be detected, and a suitable fallback executed instead), it can't be bypassed (the CPU isn't running at all yet), and it can't be modified (mask ROM). (Again, hopefully -- but every function added to it, is another risk that it can be affected somehow.) It is a single point of failure (once the keys are uncovered, anyone can sign and encrypt their own binaries). What you might do in production, is assemble and build the systems in China, except for the key store, or hypervisor chip, or whatever. That way, the system is little more than a brain-dead, useless dev kit, until it is unlocked by the OEM in the final stage of manufacture.
There can be no perfect system, of course, but learning from others' mistakes can at least be helpful. The Black Hat links above look like just such a thing.
And also in the news, Linux is now running on Switch, thanks to some boners in the hardware that didn't take very long to figure out...
Tim