gRPC server pseudo-node in Rust Oak Runtime

[ipetr0v]

Currently Rust Oak Runtime doesn't support TLS gRPC credentials that is supported by the C++ version:

oak/oak/server/dev/dev_oak_loader.h

Lines 33 to 34 in 09c7d6d

	grpc::Status CreateApplication(const oak::ApplicationConfiguration& application_configuration,
	std::shared_ptr<grpc::ServerCredentials> grpc_credentials);

Necessary, since we are moving towards using a Rust Oak Loader binary in the future #749.

[ipetr0v]

TLS credentials are not implemented because Rust Oak Runtime does not have a gRPC server pseudo-node for receiving messages from clients yet.

Before Split gRPC (#627) is implemented we could have a gRPC server pseudo-node implemented as a Tonic server (related to #695) that encapsulates client requests in a generic Protobuf message:

oak/oak/proto/grpc_encap.proto

Lines 30 to 34 in 09c7d6d

	message GrpcRequest {
	string method_name = 1;
	google.protobuf.Any req_msg = 2;
	bool last = 3;
	}

and passes it to the initial Oak node, specified in the config:

oak/examples/hello_world/config/config.textproto

Lines 12 to 13 in 09c7d6d

	initial_node_config_name: "app"
	initial_entrypoint_name: "oak_main"

[ipetr0v]

@conradgrobler

The C++ implementation of the gRPC pseudo-node uses the grpc::AsyncGenericService, that accepts all gRPC calls and does not implement any particular Protobuf schema:

oak/oak/server/oak_grpc_node.cc

Lines 43 to 45 in 09c7d6d

	// Register an async service.
	node->module_service_ = absl::make_unique<grpc::AsyncGenericService>();
	builder.RegisterAsyncGenericService(node->module_service_.get());

Have you seen a similar service for Tonic?
IIUC Tonic requires some schema in order to start server:

oak/examples/hello_world/proto/hello_world.proto

Lines 30 to 35 in 09c7d6d

	service HelloWorld {
	rpc SayHello(HelloRequest) returns (HelloResponse);
	rpc LotsOfReplies(HelloRequest) returns (stream HelloResponse);
	rpc LotsOfGreetings(stream HelloRequest) returns (HelloResponse);
	rpc BidiHello(stream HelloRequest) returns (stream HelloResponse);
	}

oak/experimental/split_grpc/server/src/main.rs

Lines 84 to 88 in 09c7d6d

	Server::builder()
	.tls_config(ServerTlsConfig::new().identity(identity))
	.add_service(HelloWorldServer::new(handler))
	.serve(address)
	.await?;

[conradgrobler]

The approach I was considering was to create a new generic service (see #695 (comment)). The service would need to implement a call method that can receive a generic Request object.

This service would look similar to some of the code generated by Tonic for a proto file (eg https://github.com/project-oak/oak/pull/647/files#diff-6116dfd8bdebbd1ea4776bec4c89ecccR65)

Initially, we can test using only a unary service and later figure out how to handle client streaming or bidirectional streaming services in a generic way.

This service could then be added using add_service

[ipetr0v]

In order to be able to use add_service, the service should implement a tonic::transport::server::NamedService trait:
https://github.com/project-oak/oak/pull/647/files#diff-6116dfd8bdebbd1ea4776bec4c89ecccR229-R231

impl<T: HelloWorld> tonic::transport::NamedService for HelloWorldServer<T> {
    const NAME: &'static str = "oak.examples.hello_world.HelloWorld";
}

And it requires to set a service name (e.g. "oak.examples.hello_world.HelloWorld").

Is it enough to just set an empty string as a service name? Because it looks like upon receiving a message from a client Tonic searches for a corresponding service based on its name.

[conradgrobler]

Looking at the Tonic code, it seems that the routing just checks that the request URI starts with / followed by the service name.
https://github.com/hyperium/tonic/blob/master/tonic/src/transport/server/mod.rs#L328

I would think that an empty string would work, although it feels like it might be brittle if the logic changes in future. For initial testing it should be OK, but it might be better in the long term to use hyper directly, rather than Tonic, as we are not currently relying on any real gRPC functionality in the gRPC pseudo node. The code could look very similar to the hyper web API example:
https://github.com/hyperium/hyper/blob/master/examples/web_api.rs#L100

[tiziano88]

Yes, my suggestion is to aim directly for a Hyper service, and not involve Tonic at all, if possible.

[conradgrobler]

Tonic provides a nice mechanism for configuring TLS. When using Hyper directly, it would need code similar to the following:
https://users.rust-lang.org/t/use-hyper-server-with-tls/18535

[ipetr0v]

Since Hyper requires the function that creates and starts a server to be async:
https://github.com/hyperium/hyper/blob/97ed0478a871f45555ee1985ae228a0adc27c35a/examples/hello.rs#L18-L23

Do we need to consider making node_create function async as well?

oak/oak/server/rust/oak_runtime/src/runtime/mod.rs

Lines 626 to 633 in 589b2d2

	pub fn node_create(
	&self,
	_node_id: NodeId,
	module_name: &str,
	entrypoint: &str,
	label: &oak_abi::label::Label,
	reader: Handle,
	) -> Result<(), OakStatus> {

But I think this may require rewriting a lot of internal Runtime code in async/await.