Support badged SMC caps to restrict SMC function IDs

[midnightveil]

Note: this contains a breaking change by removing the SMC attribute.
This should be fine, as the 3.0.0 release is planned to be breaking anyway.
This change could be reverted; it is left as a separate commit to make that easy.

The other design choice here was that we do not permit "function_id=0", or some other way to make badge = 0 <=> unbadged smc cap which has no allowlisting, instead allowing everything. This is always (in my opinion) a bad design.

<system>
    <protection_domain name="arm_smc" priority="1">
        <program_image path="arm_smc.elf" />

        <cspace>
            <!-- An (ARM) SMC capability that permits SMC calls to 0x84000000 (PSCI_VERSION) -->
            <cap_smc slot="1" function_id="0x84000000" />
        </cspace>
    </protection_domain>
</system>

Review commit-by-commit.

[Indanz]

The current way of doing SMC is by setting an attribute smc=true on the PD description and calling microkit_arm_smc_call().

The proposed way is using the recently added cap export mechanism and letting users call seL4_ARM_SMC_Call() directly on that cap.

I agree that this is a better API, as it is more generic and avoids the Microkit wrapper function.

However, the cap_smc part makes it SMC specific again. That's probably in line with the other exported caps, but I would have made it more generic and support all boot caps and have a generic badge thing instead of function_id, which requires SMC specific code again. I think I made the same comment on other caps exported via cspace.

I would not disallow function_id="0" for unbadged SMC caps, that is user policy. It can be handy for testing and if a process needs to do multiple SMC calls and one of them is destructive, then it doesn't add much to badge the caps.