[webkit-dev] Out-of-process networking and potential for sharing memory cache (was Re: Feature Announcement: Moving HTML Parser off the Main Thread)

[Adam Barth]

On Wed, Jan 16, 2013 at 11:33 PM, Maciej Stachowiak <mjs at apple.com> wrote:
> On Jan 12, 2013, at 1:14 AM, Adam Barth <abarth at webkit.org> wrote:
>> On Sat, Jan 12, 2013 at 12:03 AM, Maciej Stachowiak <mjs at apple.com> wrote:
>>>
>>> Do you think thread in the UI process vs. completely separate process is a topic worth discussing? It seems like the WebCore layer is unaffected by the difference, and in fact the impact of Chromium's choice is not even visible in the WebKit repository afaict.
>>
>> I don't know.  As I wrote above, I haven't really thought through the
>> consequences of that design choice.  My point was just that the design
>> wasn't discussed with the community at all.
>
> The NetworkProcess and its nature as a process have been mentioned before. At the time, no one expressed an opinion about the matter or pressed for an alternative, and it seems you have not (yet) done so either. If you have an interest in discussing it yourself, I at least would be happy to discuss it. If, for example, you would like to ask questions about it, advocate for a different design, argue that it's important for WK2 and Cr architectures to be consistent in this regard, present the Chromium team's reasons for choosing a thread, or anything else, then I would gladly engage in such discussion.
>
> Indeed, if anyone has a substantive point to make, I'll concede the foul of insufficient prior discussion. If no one does, then it doesn't seem very valuable to debate the meta-point.

The point isn't to "concede the foul."  As discussed in the rest of
this thread, the current design of the NetworkProcess might be a good
design on Mac OS X, but it doesn't work well on other platforms.  To
the extent that the impact of its design is limited to WebKit2, I
don't really care.  The consequence, however, is that Chromium is
unlikely to want to share any abstractions or mechanisms whose design
follows from that design decision.

>>> (One reason for our particular choice, FYI, is so that we can give the NetworkProcess a tighter sandbox profile than the Safari UI process).
>>
>> I'm surprised that the Mac OS X sandboxing mechanisms are
>> sophisticated enough to provide a meaningful sandbox for the
>> NetworkProcess.  That's certainly not possible on other platforms
>> (e.g., Windows).  The reference monitor we use in Chromium for network
>> requests contains a great deal of web-specific details that are
>> necessary to prevent, for example, an attacker from stealing
>> confidential information (such as tax returns) stored in the user's
>> file system.
>
> I take your word for it that it's not possible on Windows.

Given that Chromium has many users on Windows (and other non-Mac
platforms), you should now understand why this design does not fit
well with Chromium's design constraints.

>>> I'm certainly not blowing off your use case. But I would like to understand how it impacts the design.
>>>
>>> Can you explain why the WebKit2 approach to out-of-process networking is incompatible with software fault isolation based API integrity, whereas interposing at the ResourceHandle layer is? Is it (a) because some loads don't go through the CachedResource layer currently, (b) because there are some loads you think it is fundamentally impossible (or at least unduly challenging) to send through the CachedResource layer, or (c) some other reason?
>>
>> Issue (a) is already a problem with the CachedResource approach with
>> the sandbox we use today.  Network requests that don't get intercepted
>> will not work on Windows because code running inside the sandbox we
>> use on Windows cannot talk to the network.
>
> Our long-term goal is to make all WebCore loads go through ResourceLoader/CachedResource, and have nothing hit ResourceHandle directly. I agree with you that this is not the case today. I take it from your response that you don't think it is fundamentally impossible or overly complex to make this happen. And it seems like attaining this goal would have a number of advantages regardless of the interposition layer of choice, such as making all loads, even obscure ones, correctly respect ResourceLoader-level concepts such as ApplicationCache and WebArchives.

Even while we've been having this discussion, more patches have landed
that don't follow this design.  For example, a patch landed that
shoehorned an interception point into FrameLoader.

Given that your team appears to be prioritizing schedule over
implementing this feature in an architecturally sound way, I don't
think we'll be able to work together on this topic.  As I've written
before, on Windows and other platforms, we don't have the fallback
option of issuing network requests from the web process.  Maybe in the
"long-term" when you're done refactoring all network loading paths to
flow though ResourceLoader, we might be able to reconsider.  In the
mean time, the code that your team is landing does not work in a
secure way on non-Mac platforms.

I will note, however, that if instead you simply chose ResourceHandle
as the interception point, we would be able to share the same
interception point today and you would not need to hack ifdefs all
over the loader.  What I take way from the actions of your team is
that you're not interested in working together on out of process
networking.

> My understanding of your point is that, when interposing at the CachedResource/ResourceLoader level rather than at the ResourceHandle level, in some sense "more code" has to run outside the web process/render process sandbox, and that's the sandbox that we are most confident can be applied across many platforms, and made really tight, so that it can work with schemes like SFI.
>
> Is that correct?

Yes.  Additionally, when running inside an SFI sandbox (and also in
the sandbox we use on Windows today), there is no "fallback" plan when
we fail to intercept network requests.

> There may be some nuance or detail here that I am missing. If you think there is functionality that has to end up living in the NetworkProcess instead of WebProcess when interposing at a high level instead of a low level, I'd be curious what it is.

Historically speaking, we've had many more security vulnerabilities in
the WebCore loader than in Chromium's network stack.  I don't think
it's controversial to say that WebCore's loader is a mess of code.
Moving WebCore's loader into a privileged process is a non-starter
from a security point of view.

>> Another way to think about this issue is to consider how you'd sandbox
>> the NetworkProcess in these scenarios.  How would you sandbox the
>> NetworkProcess on Windows (where the sandboxing mechanisms are
>> primitive)?  How would you sandbox the NetworkProcess using SFI (where
>> the sandboxing mechanism is draconian)?
>
> I think we would not attempt to sandbox the NetworkProcess on Windows or using SFI if doing so is infeasible. Still, sandboxing it on those platforms where it is possible and to the extent possible seems like an advantage over having it be a thread in a privileged UI process.

Again, the design you've chosen is optimized for Mac OS X.  Perhaps
that's the best design given your goals and constraints, but it
doesn't fit well with the goals and constraints of the Chromium
project.

>> The only way I can see of solving these problems is to implement
>> ResourceHandle out-of-process (in the Windows case) or with an SFI API
>> (in the SFI case).  If you're going to do that anyway, what have you
>> gained by creating a NetworkProcess in the first place?
>
> I think having networking code in a non-SFI sandbox on some platforms is better than having it in a privileged process on all platforms. That seems like a gain. Do you disagree?

That's a false dichotomy.  "Networking code" is not a monolithic blob
that's either sandboxed or not.  The question is how to factor the
networking code so that it can be sandboxed effectively on many
platforms.

> In addition to the potential for better cache sharing, one other reason for interposition at a high level is to avoid layering violations in ResourceHandle. ResourceHandle was designed to be a wrapper around a network library that is otherwise meant to be unaware of higher-level concepts relating to the WebCore and the Web platform. That is the reason it's in WebCore/platform/. But proxying at that level seems to require threading higher-level information, such as the frame associated with a load, the resource load type, priority following from page visibility, etc, through the ResourceHandle level. If ResourceHandle has knowledge of such Web-level concepts, then it has no meaningfully distinct role from ResourceLoader. But if it was merged into ResourceLoader, the end result would end up not much different from interposing at a higher level in the first place. I concede that this design concern is trumped by actual practical advantages or disadvantages of this approach. But I wanted to mention it as an additional point of concern.

That's a pretty weak argument.  You're assuming that the network
library works like CFNetwork.  In the Chromium "platform," the
available network library is more featureful than CFNetwork and, as a
result, ResourceHandleChromium has a few more bits of state than
ResourceHandleMac.

Adam