On Wed, Jan 16, 2013 at 11:33 PM, Maciej Stachowiak <m...@apple.com> wrote: > On Jan 12, 2013, at 1:14 AM, Adam Barth <aba...@webkit.org> wrote: >> On Sat, Jan 12, 2013 at 12:03 AM, Maciej Stachowiak <m...@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. Bu t 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 _______________________________________________ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo/webkit-dev