optee-teec: refactor plugin support

[ivila]

• Introduce optee-teec-plugin-bindgen crate to generate plugin bindings for plugin developers, replacing optee-teec-macros.
• Refactor optee-teec::PluginParameters and add additional methods.
• Update optee-teec-sys::PluginMethod to latest version.

With these changes, plugin development now only requires adding optee-teec-plugin-bindgen as a build dependency and including the generated artifact in lib.rs.

Why not use a proc macro?

I have thought about implementing a declare_supp_plugin macro like thisdemo:

declare_supp_plugin!(
    name: "my_plugin",
    uuid: "ef620757-fa2b-4f19-a1c4-6e51cfe4c0f9",
    init: my_init,
    invoke: my_invoke,
);

Developers can use it like:

use optee_teec::{declare_supp_plugin, PluginParameters};

fn plugin_init() -> optee_teec::Result<()> {
    println!("*plugin*: init, version: {}", env!("CARGO_PKG_VERSION"));
    Ok(())
}

fn plugin_invoke(_: &mut PluginParameters) -> optee_teec::Result<()> {
    println!("*plugin*: invoke");
    Ok(())
}

declare_supp_plugin!(
    name: "syslog",
    uuid: "ef620757-fa2b-4f19-a1c4-6e51cfe4c0f9",
    init: plugin_init,
    invoke: plugin_invoke,
);

The main issue is that developers may provide the UUID through a variable. Due to the limitations of proc macros, we cannot resolve the value of that variable during macro expansion. As a result, the UUID would need to be parsed and converted at runtime.

declare_supp_plugin!(
    name: "my_plugin",
    uuid: proto::PLUGIN_UUID,  // proc_macro cannot resolve the value at compile time.
    init: my_init,
    invoke: my_invoke,
);

However, this introduces another problem: what happens if UUID parsing fails? Triggering a panic in a shared library is not a good idea and should be avoided.

[DemesneGH]

I see why we're avoiding macros, but using strings for function names is a bit weird.
Since most users don't need custom names anyway, how about using defaults like plugin_init and plugin_invoke? Then the default constructor only requires the name and UUID. This would clean up the API and eliminate potential typos in build.rs.

We can also provide one more constructor that accepts the customized fn name if you'd like to.

[ivila]

Sounds good!😃

[ivila]

I have restored optee-teec-macros and am considering using macros to generate the injected functions automatically. What do you think about this approach?

With this solution, developers would apply macros to their init and invoke functions:

// lib.rs
#[derive_raw_plugin_init]
fn init() -> optee_teec::Result<()> {
    Ok(())
}

#[derive_raw_plugin_invoke]
fn invoke(_: &mut optee_teec::PluginParameters) -> optee_teec::Result<()> {
    Ok(())
}

// build.rs
fn main() -> anyhow::Result<()> {
    Config::new(Uuid::parse_str(proto::PLUGIN_UUID)?)
        .with_name("syslog")
        .build()?;

    Ok(())
}

If they need to customize the generated raw function name, it could work like this:

// lib.rs
#[derive_raw_plugin_init(raw_name = "raw_func_name")]
fn init() -> optee_teec::Result<()> {
    Ok(())
}

#[derive_raw_plugin_invoke]
fn invoke(_: &mut optee_teec::PluginParameters) -> optee_teec::Result<()> {
    Ok(())
}

// build.rs
fn main() -> anyhow::Result<()> {
    Config::new(Uuid::parse_str(proto::PLUGIN_UUID)?)
        .with_name("syslog")
        .with_init_fn_name("raw_func_name")
        .build()?;

    Ok(())
}

[ivila]

Here's another idea I am considering: introducing a dedicated UUID conversion crate (for example, optee-teec-build) that converts a UUID string into raw::TEEC_UUID during build.rs.

With this approach, build.rs would generate the UUID constant, and lib.rs would simply include the generated file and use the declare_supp_plugin macro to declare the plugin.

// build.rs
const OUTPUT_VAR_NAME: &str = "TA_PLUGIN_UUID";
const OUTPUT_FILENAME: &str = "ta_plugin_uuid.rs";

optee_teec_build::convert_uuid(
    uuid_str,
    OUTPUT_VAR_NAME,
    OUTPUT_FILENAME,
)?;

Ok(())

// lib.rs
include!(concat!(env!("OUT_DIR"), "/ta_plugin_uuid.rs"));

declare_supp_plugin!(
    name: "syslog",
    uuid: TA_PLUGIN_UUID,
    init: plugin_init,
    invoke: plugin_invoke,
);

This approach keeps the UUID parsing and conversion logic in the build phase, while keeping the plugin declaration in lib.rs clean and declarative.

[DemesneGH]

Thanks for your insightful proposals! The both approaches make sense to me technically.

However, considering consistency with the existing TA development flow, how about:

1. Use attribute macros (like #[plugin_init] and #[plugin_invoke]) from approach 1: This mirrors the #[ta_create] pattern that developers are already familiar with. Also keep the macro name in similar pattern if possible.

2. Introduce optee-teec-build and PluginConfig: This provides a symmetric API to TaConfig. It hides the complexity of UUID parsing and code generation (e.g., optee_teec_build::build_plugin(plugin_config)).

This alignment makes our API design more intuitive, if users know how to write a TA, they already know how to write a Plugin.

Edit: since we already have Config related implementation in optee-teec-plugin-bindgen, how about directly naming this to a sub module of optee-teec-build?