refactor: decouple foreign functions from WasmBase.

[mathetake]

It seems unnecessary to have foreign functions managed by WasmBase because it's just using global lookup tables.

Signed-off-by: Takeshi Yoneda [email protected]

[PiotrSikora]

I don't think it works right now, but foreign functions must be coupled with WasmBase in order to enforce capability restrictions.

[mathetake]

No I don't think so. The decoupled codes are only used in the "allowed" case - inside of exports::call_foreign_function which is replaced with the stub when capability not given: https://github.com/proxy-wasm/proxy-wasm-cpp-host/blob/master/src/wasm.cc#L109.

[PiotrSikora]

No I don't think so. The decoupled codes are only used in the "allowed" case - inside of exports::call_foreign_function which is replaced with the stub when capability not given: https://github.com/proxy-wasm/proxy-wasm-cpp-host/blob/master/src/wasm.cc#L109.

Right, I guess there is some context missing. The end goal is to be able to allow/deny specific arguments, e.g. you should be able to allow only http_call(cluster="httpbin") or foreign_function(name="foo", args="bar") and deny everything else. The list of allowed arguments would be scoped to a given WasmBase, which is why the current code might work better.

Having said that, it's not implemented yet, so feel free to merge this if you need it.

[mathetake]

The end goal is to be able to allow/deny specific arguments,

Oh I see. I think then we have to refactor around all the exports functions, not only this foreign function calls in order to couple with WasmBase. Thanks for letting me know the context.

The initial intent of this was I just wanted to reduce the complexity in the wasm.cc/wasm.h. I will go ahead and merge since I believe this could make them a bit less complex and readable (plus added doc!)🙂