[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 Sat, Jan 12, 2013 at 12:03 AM, Maciej Stachowiak <mjs at apple.com> wrote:
> On Jan 11, 2013, at 2:53 PM, Adam Barth <abarth at webkit.org> wrote:
>> On Fri, Jan 11, 2013 at 2:19 AM, Maciej Stachowiak <mjs at apple.com> wrote:
>>> On Jan 11, 2013, at 12:21 AM, Adam Barth <abarth at webkit.org> wrote:
>>>> Is that really the case?  If so, I'm surprised that the patches for
>>>> the shared memory cache and the NetworkProcess landed.  I raised
>>>> similar questions to the ones you're raising now, but the folks
>>>> purposing those changes basically ignored me and landed their patches
>>>> anyway.
>>>
>>> NetworkProcess itself exists primarily for correctness reasons in the face of process-per-tab. I hope the idea of handling networking outside any of the web/render processes in a process-per-tab architecture is not itself controversial.
>>
>> I don't want delve too deeply into this issue because it's primarily a
>> WebKit2 concern.  However, I'll note that in Chromium, networking is
>> just a thread in the UIProcess rather than a separate process.  I
>> haven't really thought though the consequences of that design choice.
>> My point is more that folks just started landing patches for the
>> NetworkProcess without discussing the design with the community.
>> That's fine if you're not interested feedback from the community, but
>> I've also heard repeated requests to share more code between Chromium
>> and WebKit2.  If you don't seek feedback on your designs, it's
>> unlikely that you'll happen to design something that Chromium will be
>> able to adopt in the future.  Put another way, I don't think it's
>> reasonable to simultaneously design WebKit2 without community feedback
>> and also to complain when Chromium doesn't adopt WebKit2 (in part or
>> in whole).
>
> 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.

>  (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.

>> The main point I was trying to make in the document is that hooking in
>> at the CachedResource layer has worse security properties than hooking
>> in at the ResourceHandle layer.  I understand that Safari and Chromium
>> have different goals when it comes to security, which I believe is the
>> main reason you're even willing to consider hooking in at the
>> CachedResource layer.
>>
>> In particular, Chromium needs to be able to run in a strong sandbox on
>> Windows XP.  Unlike Mac OS X, Windows XP does not have a particularly
>> sensible sandboxing mechanism, mostly because the OS mechanisms that
>> we use in Chromium were not intended to be used for sandboxing by the
>> designers of XP.  As a consequence, any network requests that we fail
>> to hook will simply fail (or more likely just crash).  For that
>> reason, we need complete interposition, which means we need to hook
>> into WebCore at a layer like ResourceHandle that has actually has
>> complete interposition.
>>
>> Moreover, we've enjoyed the security benefits of complete
>> interposition for a while now and have raised our security goals,
>> namely we're interested in achieving software fault isolation based
>> API integrity.  As far as I can tell, the approach WebKit2 has taken
>> to out-of-proces networking is not compatible with software fault
>> isolation based API integrity.  Now, I understand if that sounds very
>> futuristic to you given the current security posture of the apple-mac
>> port, but if you're serious about working on a common design, you need
>> to be willing to accept design goals and constraints beyond those that
>> affect the apple-mac port.  As long as you minimize or ignore those
>> constraints, it's unlikely that the folks who have those goals and
>> constraints will be interested in adopting your designs.
>
> 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.

When using software fault isolation (SFI), the untrusted code cannot
talk with the underlying operating system at all (not even on advanced
operating systems like Mac OS X that provide high quality sandboxing
APIs).  In particular, code inside an SFI sandbox cannot use
CFNetwork.  Given that WebCore contains code that uses ResourceHandle,
we're left with the following choice:

1) Implement ResourceHandle in terms of an SFI API rather than an
operating system API.
2) Move the parts of WebCore that call ResourceHandle out of the SFI
sandbox so that ResourceHandle can use operating system APIs.

Generally speaking, the more code we put in the sandbox, the better
security we'll achieve.  I'd certainly hope we'd be able to put at
least WebCore inside the sandbox, which makes (2) unattractive.  (In
fact, I hope we'll be able to put much of the "content" and "chrome"
layers of Chromium inside the SFI sandbox as well, much as these
layers are inside the current Chromium sandbox.)  In order to sandbox
WebCore, we'll need to choose (1), which means we'll need to intercept
network requests at the ResourceHandle layer anyway.

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)?

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?

Adam