[webkit-dev] Thread Model in WebKit2!!
Hi Everyone, WebKit2 can have following models : 1. Shared Secondary Process 2. Secondary Process 3. Shared Thread Model As per current webkit2 code, only Shared Secondary process is implemented. Does community is having any plan for *thread model* or is any patch available for *thread model*? If community is not planning, is there any specific reason, as thread model can reduce the *memory consumption *on risk of security due to single process*?* Thanks, Prince Goyal ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] how to configure a PAC file in webkit
Hi, Using winLauncher exe I am trying to access the internal sites of my company.but i am able to do so. I have to craete a PAC file to setup the rules. Please help me to create a PAC file in Webkit. Thanks, Moumita ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] WebCL Release
WebCL would not be enabled in the browser by default, and users will have the choice to enable it in the browser. That's not really a great consolation -- defining a spec where there's is the assumption it will be disabled by default doesn't seem like a good plan in the long term. In all honesty disabled by default is only a bit better than asking the user's permission in terms of security. My apologies for the misinterpretation. What I meant to state in my previous email was that WebCL would be behind a compile time flag, and developers would need to explicitly turn it on. At a later time, only after the completion of the WebCL specification, and after the security issues have been addressed, would this be changed. in WebCL I assume an ArrayBuffer or similar, and then the kernel can compute an arbitrary index into that storage -- is that understanding correct? If so how does WebCL ensure that this behaviour is safe? Your understanding is correct. As the WebCL standard gets defined, it will be addressed in the specification, through collaboration with the OpenCL driver vendors. does the WebCL WG have a table of attack surfaces and hardening solutions that have been taken? A discussion on the security aspects of WebCL is currently in progress in the WebCL working group. The working group is working on identifying the issues, defining solutions and providing recommendations to OpenCL driver vendors and hardware vendors, where needed. I would also like to note that there is an updated version of Samsung's WebCL prototype, which can be found at http://code.google.com/p/webcl/. This has been tested with WebKit r92365, on MacOS 10.7. Regards, Tasneem -Original Message- From: Oliver Hunt [mailto:oli...@apple.com] Sent: Wednesday, August 24, 2011 4:00 PM To: Tasneem Brutch - Samsung Cc: webkit-dev@lists.webkit.org; Won Jeon - SISA; Simon Gibbs - Samsung Subject: Re: [webkit-dev] WebCL Release On Aug 24, 2011, at 3:20 PM, Tasneem Brutch - Samsung wrote: Khronos WebCL is not yet a specification, and the WebCL API has not yet been standardized. The WebCL members are currently discussing the security and interoperability issues in the WebCL Working Group. Samsung would like to introduce a WebCL patch at this time, to follow the ongoing specification activity in the Khronos WebCL working group. WebCL would not be enabled in the browser by default, and users will have the choice to enable it in the browser. That's not really a great consolation -- defining a spec where there's is the assumption it will be disabled by default doesn't seem like a good plan in the long term. In all honesty disabled by default is only a bit better than asking the user's permission in terms of security. The WebGL security concerns previously raised, related to the following aspects: 1) Cross domain image access - timed loop attack. 2) Issues related to general hardening. In response to item 1), WebGL and HTML specs have been updated, mandating CORS (Cross Origin Resource Sharing) for video, images and audio, and servers have to grant cross domain access to media resources. Item 2) was addressed by the WebGL working group, through ARB_ROBUSTNESS extensions, which provide additional protection being mandated. The new robustness specification limits the side-effects of a GPU reset after a Denial of Service attack. In addition the ANGLE shader validator was improved. The hardening policies for WebGL work because WebGL is built on a heavily restricted version of GLSL. My understanding was that OpenCL had access to pointers and arrays provided by the host application, but did not guarantee memory safety. Given all kernels provided to WebCL are untrusted code that is clearly unsafe, to what extent does the WebCL spec (or draft spec as the case may be) limit illegal memory operations? ARB_ROBUSTNESS is specifically a GPU flag (mostly needed due to the absence of any memory protection on GPU), but one of the goals of OpenCL was to provide a uniform interface to CPU and GPU compute resources so is not particularly relevant to the discussion of WebCL security. Now I will say I have no real development experience with OpenCL (essentially I have read the documentation and looked at the pretty demos), but it is my understanding that I can provide OpenCL with a specific piece of memory, in WebCL I assume an ArrayBuffer or similar, and then the kernel can compute an arbitrary index into that storage -- is that understanding correct? If so how does WebCL ensure that this behaviour is safe? In the short term, browser vendors would maintain white and black lists, so that the compromised system can have WebGL disabled until mitigation is developed. In the longer term, GPUs would provide increasingly robust security and tasking, to allow GPU to become a first-class computing platform alongside CPU. As I said above WebGL already introduces a large number of restrictions on the possible operations
Re: [webkit-dev] Thread Model in WebKit2
On Aug 29, 2011, at 12:45 AM, prince goyal wrote: Does community is having any plan for thread model or is any patch available for thread model? Early in the development of WebKit2 the thread model was working on Mac OS X and Windows. Those of us at Apple stopped maintaining and using the threaded model because we couldn’t use it on Mac OS X. We need to have WebKit1 and WebKit2 coexist there and the same copy of WebCore didn’t work in a single process as both WebKit1’s WebCore and WebKit2’s WebCore. WebKit2 makes use of WebKit1 on Mac OS X at this time, as does the Safari application, so a mode where WebKit2 worked but WebKit1 did not was not valuable to us. We at Apple might decide to make use of it again in the future if and when we have resolve those issues for ourselves and once again have contexts where we are using WebKit2 only. But that’s unlikely to happen any time soon. -- Darin ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Top Crasher: Shadow DOM and Editing Collide Again
Thanks for bringing this up Ryosuke! I looked over the problem. It seems, the issue is as follows (generalized from the specific conditions): a) When an editing command runs, it modifies DOM in discrete steps. For instance, the SplitTextNodeCommand first inserts a node, then removes data from existing node (http://codesearch.google.com/codesearch#OAMlx_jo-ck/src/third_party/WebKit/Source/WebCore/editing/SplitTextNodeCommand.cppl=98). b) Some of these operations may force style recalc. For example, modifying that existing node in SplitTextNodeCommand eventually may call FrameSelection::textWillBeReplaced (http://codesearch.google.com/codesearch#OAMlx_jo-ck/src/third_party/WebKit/Source/WebCore/editing/FrameSelection.cppl=379). c) Depending on the state of the tree, the node (or parent of the node for text nodes) that's being modified could have its style recalculated. For example, if a sibling + universal selector are at play, the whole tree is basically doomed to always have its style recalculated (see repro in bug). d) This situation produces two unwanted results: 1 -- the style is calculated in the middle of the editing command run, producing definitely incorrect results (for example, in the repro in bug, you will have style calculated for a string aa in the text area, since we first insert data, and then remove data. This is usually wall-papered over by the next style recalc, which is triggered at the end of the editing command. 2 -- the style recalc my trigger forms machinery to assume that this change is for realz and start updating its form values, and, as it happens in the repro on bug, stomp over the CharacterData we just started to update, leading to BOOM. Did I get the details right? If so, the feasible three solutions that I can imagine are: A. Ensure that any layout that's forced by an editing operation is performed in a specific order, ensuring that the forced style recalc does not find the tree in a mid-transition state. For example, this particular crash could be fixed by changing the order of operations to update character data first. B. Change editing commands to force layout only at the end of the operation, making the commands more atomic. C. Add case-specific hacks to areas of code where we know there are troubles. For example, we could add a flag to HTMLTextAreaElement to say please ignore, this is not a real style recalc, the real one is coming up. What do you think? :DG On Sun, Aug 28, 2011 at 7:16 PM, Ryosuke Niwa rn...@webkit.org wrote: Hi all, We have a nightmare of editing v.s. shadow DOM again. The WebKit bug 66241 is currently the top renderer crasher in Chromium (probably affecting Safari 5.1 as much as well). The problem is that when the shadow DOM is modified by the editing code, the shadow host's style is marked dirty and updateLayout ends up calling updateFromElement on the shadow host. RenderTextControl*::updateFromElement then recreates the children of innerTextElement, and invalidates all positions, ending selections, etc... that editing code holds, causing the crash. We can certainly add band aids in the editing code to check the nullity of positions and node ref-pointers and exit early when they are null. However, this would result in wrong behavior because editing operations will end up bailing out early in the middle of doing something. It appears to me that there are a couple of approaches we can take but none of them are promising: Avoid marking the shadow host dirty when editing code is modifying its shadow tree - This approach is a little fragile in that there's nothing that stops authors from writing selectors that matches shadow host with certain nodes in its shadow tree, in which case the problem persists. Avoid re-creating innerTextElement's contents when the shadow host's style changes - This requires a lot of work and may not be feasible in some cases because authors can override -webkit-apperance and there are certain properties such as whitespace, direction, etc... that need to propagate from the shadow host. Make editing code aware of this situation and update positions and node references as needed - As far as I can tell, this is infeasible. It'll require us creating some XPath-like objects at every other line in editing, and computing node references and positions back from those objects. Are there any clever alternatives here? Best, Ryosuke Niwa Software Engineer Google Inc. ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Top Crasher: Shadow DOM and Editing Collide Again
Thanks for the analysis, Dimitri. On Mon, Aug 29, 2011 at 12:01 PM, Dimitri Glazkov dglaz...@chromium.orgwrote: 1 -- the style is calculated in the middle of the editing command run, producing definitely incorrect results (for example, in the repro in bug, you will have style calculated for a string aa in the text area, since we first insert data, and then remove data. This isn't really unwanted. It happens everywhere in editing and we need those style recalculation in place because editing code inherently relies on renderStyle. i.e. updating styles at intermediate states are needed by editing code. 2 -- the style recalc my trigger forms machinery to assume that this change is for realz and start updating its form values, and, as it happens in the repro on bug, stomp over the CharacterData we just started to update, leading to BOOM. This is the problem. It's same thing as if mutation event listeners started modifying DOM in the middle of an editing command. A. Ensure that any layout that's forced by an editing operation is performed in a specific order, ensuring that the forced style recalc does not find the tree in a mid-transition state. I don't think this approach is feasible given that it requires us modifying hundreds of lines of editing code. B. Change editing commands to force layout only at the end of the operation, making the commands more atomic. I can safely say this is impossible because editability itself depends on style; i.e. whether a node is editable or not is determined by -the value webkit-user-modify. Nodes without renderers are treated differently than nodes with renderers in editing code. C. Add case-specific hacks to areas of code where we know there are troubles. For example, we could add a flag to HTMLTextAreaElement to say please ignore, this is not a real style recalc, the real one is coming up. As far as I'm concerned, this is the only practical solution among the three. I'm still quite skeptical as to why we'd have to re-create descendent nodes of innerTextElement upon style recalc / layout. It seems odd that the life time of the shadow DOM is tied to its host's style change. - Ryosuke ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Top Crasher: Shadow DOM and Editing Collide Again
On Mon, Aug 29, 2011 at 1:03 PM, Ryosuke Niwa rn...@webkit.org wrote: Thanks for the analysis, Dimitri. On Mon, Aug 29, 2011 at 12:01 PM, Dimitri Glazkov dglaz...@chromium.org wrote: 1 -- the style is calculated in the middle of the editing command run, producing definitely incorrect results (for example, in the repro in bug, you will have style calculated for a string aa in the text area, since we first insert data, and then remove data. This isn't really unwanted. It happens everywhere in editing and we need those style recalculation in place because editing code inherently relies on renderStyle. i.e. updating styles at intermediate states are needed by editing code. Makes sense. 2 -- the style recalc my trigger forms machinery to assume that this change is for realz and start updating its form values, and, as it happens in the repro on bug, stomp over the CharacterData we just started to update, leading to BOOM. This is the problem. It's same thing as if mutation event listeners started modifying DOM in the middle of an editing command. Right. A. Ensure that any layout that's forced by an editing operation is performed in a specific order, ensuring that the forced style recalc does not find the tree in a mid-transition state. I don't think this approach is feasible given that it requires us modifying hundreds of lines of editing code. B. Change editing commands to force layout only at the end of the operation, making the commands more atomic. I can safely say this is impossible because editability itself depends on style; i.e. whether a node is editable or not is determined by -the value webkit-user-modify. Nodes without renderers are treated differently than nodes with renderers in editing code. C. Add case-specific hacks to areas of code where we know there are troubles. For example, we could add a flag to HTMLTextAreaElement to say please ignore, this is not a real style recalc, the real one is coming up. As far as I'm concerned, this is the only practical solution among the three. I'm still quite skeptical as to why we'd have to re-create descendent nodes of innerTextElement upon style recalc / layout. It seems odd that the life time of the shadow DOM is tied to its host's style change. I just realized what's going on here. The lifetime of the shadow DOM _used_ to be tied to the HTMLTextAreaElement's RenderObjects. Kent-san changed that and now the shadow DOM's lifecycle matches that of the rest of the DOM. However, the update cycle still assumes that the shadow DOM lives on the RenderObjects, and does this really freaky thing with shuttling updated value via an extra style recalc (see http://codesearch.google.com/codesearch#OAMlx_jo-ck/src/third_party/WebKit/Source/WebCore/html/HTMLTextAreaElement.cppl=349). We should just fix that and move updating code out of updateFromElement. :DG - Ryosuke ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
Re: [webkit-dev] Top Crasher: Shadow DOM and Editing Collide Again
On Mon, Aug 29, 2011 at 1:46 PM, Dimitri Glazkov dglaz...@chromium.orgwrote: I just realized what's going on here. The lifetime of the shadow DOM _used_ to be tied to the HTMLTextAreaElement's RenderObjects. Kent-san changed that and now the shadow DOM's lifecycle matches that of the rest of the DOM. Yes! However, the update cycle still assumes that the shadow DOM lives on the RenderObjects, and does this really freaky thing with shuttling updated value via an extra style recalc (see http://codesearch.google.com/codesearch#OAMlx_jo-ck/src/third_party/WebKit/Source/WebCore/html/HTMLTextAreaElement.cppl=349 ). We should just fix that and move updating code out of updateFromElement. Right. I think making updateFromElement not call setInnerTextValue will fix this bug for good. - Ryosuke ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] (no subject)
Hello, WTF current implementation of StackBounds is not quite compatible with Windows fiber threads and/or custom stack sizes: we have successfully implemented support for Windows fiber threads in StackBounds fixed some 64 issues but we are still stuck on how to determine thread or fiber allocated stack size... From the fiber or thread context, i can only get the stack base stack current pointer but not the allocated stack size: any idea on how to get it assuming that i cannot get stack size from the executable stack size because our main app might use cooperative fiber threads with variable stack size, along with preemptive threads created from WebKit ? For now the only workaround i think about is to pass the fiber stack size as fiber data while creating the fiber in our main app get it in StackBounds with GetFiberData() using a custom define to filter with our app impl: but it means adding code specific to our app in JavacriptCore/WTF which i would like to avoid if possible. Kind regards, Jacques Quidu Graphics Software Engineer E-Mail: jqu...@hotmail.fr ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
[webkit-dev] WTF StackBounds not compatible with Windows fiber threads custom fiber or thread stack size
Hello, WTF current implementation of StackBounds is not quite compatible with Windows fiber threads and/or custom stack sizes: we have successfully implemented support for Windows fiber threads in StackBounds fixed some 64 issues but we are still stuck on how to determine thread or fiber allocated stack size... From the fiber or thread context, i can only get the stack base stack current pointer but not the allocated stack size: any idea on how to get it assuming that i cannot get stack size from the executable stack size because our main app might use cooperative fiber threads with variable stack size, along with preemptive threads created from WebKit ? For now the only workaround i think about is to pass the fiber stack size as fiber data while creating the fiber in our main app get it in StackBounds with GetFiberData() using a custom define to filter with our app impl: but it means adding code specific to our app in JavacriptCore/WTF which i would like to avoid if it is possible. Kind regards, Jacques Quidu Graphics Software Engineer E-Mail: jqu...@hotmail.fr ___ webkit-dev mailing list webkit-dev@lists.webkit.org http://lists.webkit.org/mailman/listinfo.cgi/webkit-dev
