Basic understanding of OPAL

[cchinicz]

Hi everyone,

I'm trying to understand what OPAL does and how it works. I noticed the memory I see on "host" OS is about 0.5GB smaller than actual physical memory and I wonder OPAL works as a tier 1 "hypervisor" for what we call "host" OS (Fedora 32 in my case), which is kind of para virtualized.

Besides memory, what else OPAL provides to the OS? CPU scheduler, PCI devices, NICs, USB, and HDMI (through BMC in my case with Blackbird)?

If this is so, it can be good from a security point of view (besides providing standard interfaces for any OS) since any reboot will bring up a fresh and clean OPAL, regardless of what happened before. If so, also important to keep firmware up to date, which I have not done since I got the machine on May 2020.

Any input is appreciated.

Regards,
Claudio

[ClassicHasClass]

I guess you could think of it as a sort of hypervisor, but what it's actually doing is serving as an abstraction layer (hence the acronym) to give a common entry point for doing necessary low-level services. OPAL is part of Skiboot, so as you update your firmware, OPAL is updated as well.

The full list of OPAL calls by number defines its services. It largely concerns itself with low-level functions like PCI devices and interrupts. Here's one such list maintained in FreeBSD: http://fxr.watson.org/fxr/source/powerpc/powernv/opal.h

[cchinicz]

Hey ClassicHasClass, thank you for the input. I've followed your lead and found the OPAL API reference link here https://open-power.github.io/skiboot/doc/opal-api/

Now it has became a lot clearer.

Cheers!

[cchinicz]

By the way, does OPAL "harden" the security of openpower systems by moving to firmware (stateless) hardware related activities? Would it help prevent Evil Maid attacks on USB? Or at the driver level with all devices?

[ClassicHasClass]

That's not really its purpose; its purpose is to make implementation differences between systems appear unified to an OS running at a higher level. Things like USB and hardware attacks are probably best approached from the OS itself by simply disabling the conduits for those attacks, which certainly could be done through OPAL calls and thus will work on any class of OpenPOWER machine. But the role it serves is far more general than that.

[cchinicz]

Well, that makes sense. OSs can handle that through whatever drivers (maybe OPAL can be better characterized as a "standard" driver for OSs running on openpower). But anyway, any OS which has been compromised will continue to be compromised boot after boot, it's statefull. The OPAL seems to add some tier between the HW and the OS that is not present on x86 machines and I like it. When I started this thread I wanted to better understand OPAL functionality and architecture. Now it's much clear to me. Thank you.

[cchinicz]

Something else which intrigues me is what is skiboot? I suppose it's a Linux kernel. I read OPAL is started as part of skiboot and continues to run after Petitboot has loaded the OS and exited. Skiboot running OPAL after the OS has started has a relatively small footprint, some 0.5GB on my system (not so small as Mirage, which runs with some 30MB of RAM). As I'm not a code guy, I have no clue and would appreciate any inputs about this also.

[ClassicHasClass]

Skiboot is not a Linux kernel. Skiboot's most important component is OPAL. It is also responsible for setting up the PCIe Host Bridges (PHBs) and certain other kinds of midlevel initialization. Once this is done, it then starts a kernel stored in the BOOTKERNEL firmware partition, which is usually Skiroot/Petitboot.