Proposal to augment chrome/services/util_win

27 views
Skip to first unread message

Nicolas Arciniega

unread,
Jun 10, 2021, 7:34:58 PM6/10/21
to services-dev
Hello all,

I'm working on a networking feature that will allow Chromium to use Windows APIs for proxy resolution. Today, proxy resolution logic lives in /net code and executes in the network service. I'd like my feature to call the necessary Windows APIs from a separate process since that way I won't block the network service sandboxing efforts.

This seems like it would fit alright in chrome/services/util_win since the stated purpose includes running "tasks that require certain DLLs to be loaded into the process address space that we don't want to load in the main process":

Specifically, my feature requires loading winhttp.dll:

My thought is that my proxy resolution logic could mojo out to the browser process, which will in turn mojo out to the util_win service.

Do folks in this group have any advice on:
  • Should I extend the existing util_win service to include proxy resolution via Windows?
  • Does this feature merit its own service?
  • Am I on the right track with the idea of network service <--> browser process <--> service/utility process mojo pipes?
I have a design doc for my feature (minus any service/utility process stuff since I haven't quite figured that out yet) below. I intend to run the WindowsSystemProxyResolver in a separate process.

Any advice, help, or pointers to documentation I missed would be much appreciated :)

Thanks,
Nicolas

Ken Rockot

unread,
Jun 11, 2021, 2:57:05 PM6/11/21
to Nicolas Arciniega, services-dev
On Thu, Jun 10, 2021 at 4:35 PM 'Nicolas Arciniega' via services-dev <servic...@chromium.org> wrote:
Hello all,

I'm working on a networking feature that will allow Chromium to use Windows APIs for proxy resolution. Today, proxy resolution logic lives in /net code and executes in the network service. I'd like my feature to call the necessary Windows APIs from a separate process since that way I won't block the network service sandboxing efforts.

This seems like it would fit alright in chrome/services/util_win since the stated purpose includes running "tasks that require certain DLLs to be loaded into the process address space that we don't want to load in the main process":

Specifically, my feature requires loading winhttp.dll:

My thought is that my proxy resolution logic could mojo out to the browser process, which will in turn mojo out to the util_win service.

Do folks in this group have any advice on:
  • Should I extend the existing util_win service to include proxy resolution via Windows?
  • Does this feature merit its own service?
  • Am I on the right track with the idea of network service <--> browser process <--> service/utility process mojo pipes?
I think the general idea is reasonable, yes.

Note that the few mixed-bag services we have (like util_win) are likely a consequence of how painful it used to be to define new services. Given that it's relatively straightforward now, I would recommend introducing a separate service for this thing.

I have a design doc for my feature (minus any service/utility process stuff since I haven't quite figured that out yet) below. I intend to run the WindowsSystemProxyResolver in a separate process.

Any advice, help, or pointers to documentation I missed would be much appreciated :)

Basic idea as I see it would be to define an interface which the browser can inject into the network service:

  // mojom: implemented by browser
  interface FooProvider {
    BindFoo(pending_receiver<Foo> receiver);
  };

  // mojom: implemented by your service
  interface FooService {
    BindFoo(pending_receiver<Foo> receiver);
  };

  // mojom: on NeworkService interface
  interface NetworkService {
     ...
     // alternatively this could be injected on initialization or whatever
     SetFooProvider(pending_remote<FooProvider> provider);
     ...
  };

  // browser-side impl of FooProvider
  void FooProviderImpl::BindFoo(mojo::PendingReceiver<mojom::Foo> receiver) {
    foo_service_remote_ = content::ServiceProcessHost::Launch<mojom::FooService>(...);
    foo_service_remote_->BindFoo(std::move(receiver));
  }

So when the network service uses its Remote<FooProvider> to bind a new Foo receiver, net result will be that the browser launches a new service process and routes the receiver down to it. You may of course wish to do things a bit differently, like have a single lazy instance of the service process running to support multiple Foo connections, or whatever.

Documentation here looks up-to-date and covers basic service definition and process launching, both of which are fairly trivial these days.


Thanks,
Nicolas

--
You received this message because you are subscribed to the Google Groups "services-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to services-dev...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/services-dev/8761e386-60e0-4225-bf68-10ee9b4617e4n%40chromium.org.

Nicolas Arciniega

unread,
Jun 11, 2021, 4:11:44 PM6/11/21
to services-dev, Ken Rockot, services-dev, Nicolas Arciniega
On Friday, June 11, 2021 at 11:57:05 AM UTC-7 Ken Rockot wrote:
On Thu, Jun 10, 2021 at 4:35 PM 'Nicolas Arciniega' via services-dev <servic...@chromium.org> wrote:
Hello all,

I'm working on a networking feature that will allow Chromium to use Windows APIs for proxy resolution. Today, proxy resolution logic lives in /net code and executes in the network service. I'd like my feature to call the necessary Windows APIs from a separate process since that way I won't block the network service sandboxing efforts.

This seems like it would fit alright in chrome/services/util_win since the stated purpose includes running "tasks that require certain DLLs to be loaded into the process address space that we don't want to load in the main process":

Specifically, my feature requires loading winhttp.dll:

My thought is that my proxy resolution logic could mojo out to the browser process, which will in turn mojo out to the util_win service.

Do folks in this group have any advice on:
  • Should I extend the existing util_win service to include proxy resolution via Windows?
  • Does this feature merit its own service?
  • Am I on the right track with the idea of network service <--> browser process <--> service/utility process mojo pipes?
I think the general idea is reasonable, yes.

Note that the few mixed-bag services we have (like util_win) are likely a consequence of how painful it used to be to define new services. Given that it's relatively straightforward now, I would recommend introducing a separate service for this thing.

Right, that makes sense. Alright, I'll create a new service!
 

I have a design doc for my feature (minus any service/utility process stuff since I haven't quite figured that out yet) below. I intend to run the WindowsSystemProxyResolver in a separate process.

Any advice, help, or pointers to documentation I missed would be much appreciated :)

Basic idea as I see it would be to define an interface which the browser can inject into the network service:

  // mojom: implemented by browser
  interface FooProvider {
    BindFoo(pending_receiver<Foo> receiver);
  };

  // mojom: implemented by your service
  interface FooService {
    BindFoo(pending_receiver<Foo> receiver);
  };

  // mojom: on NeworkService interface
  interface NetworkService {
     ...
     // alternatively this could be injected on initialization or whatever
     SetFooProvider(pending_remote<FooProvider> provider);
     ...
  };

  // browser-side impl of FooProvider
  void FooProviderImpl::BindFoo(mojo::PendingReceiver<mojom::Foo> receiver) {
    foo_service_remote_ = content::ServiceProcessHost::Launch<mojom::FooService>(...);
    foo_service_remote_->BindFoo(std::move(receiver));
  }

So when the network service uses its Remote<FooProvider> to bind a new Foo receiver, net result will be that the browser launches a new service process and routes the receiver down to it. You may of course wish to do things a bit differently, like have a single lazy instance of the service process running to support multiple Foo connections, or whatever.

Documentation here looks up-to-date and covers basic service definition and process launching, both of which are fairly trivial these days.

Awesome, thanks for the suggestions! I don't think I had found the doc you linked yet, so that was very helpful too. I'll go ahead and prototype this to make sure I understand what's going on.
Reply all
Reply to author
Forward
0 new messages