<html><head><style>body{font-family:Helvetica,Arial;font-size:13px}</style></head><body style="word-wrap:break-word"><div id="bloop_customfont" style="font-family:Helvetica,Arial;font-size:13px;color:rgba(0,0,0,1.0);margin:0px;line-height:auto"><br></div> <br> <div id="bloop_sign_1490476884916890112" class="bloop_sign"></div> <br><p class="airmail_on">On March 25, 2017 at 10:24:23 AM, Elijah Johnson (<a href="mailto:ejrx7753@gmail.com">ejrx7753@gmail.com</a>) wrote:</p> <div><blockquote type="cite" class="clean_bq" style="font-family:Helvetica,Arial;font-size:13px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><span><div style="word-wrap:break-word"><div><br class="Apple-interchange-newline"><br><div id="bloop_sign_1490451116213062912" class="bloop_sign"></div><br><p class="airmail_on">On March 23, 2017 at 12:01:48 PM, Joe Groff (<a href="mailto:jgroff@apple.com">jgroff@apple.com</a>) wrote:</p><div><blockquote type="cite" class="clean_bq" style="font-family:Helvetica,Arial;font-size:13px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div class="" style="word-wrap:break-word"><div><div><blockquote type="cite" class=""><div class=""><span><br class="Apple-interchange-newline">On Mar 22, 2017, at 7:25 PM, Elijah Johnson &lt;<a href="mailto:ejrx7753@gmail.com" class="">ejrx7753@gmail.com</a>&gt; wrote:</span></div><span><br class="Apple-interchange-newline"></span><div class=""><div id="bloop_customfont" class="" style="font-family:Helvetica,Arial;font-size:13px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;margin:0px"><span>On March 22, 2017 at 8:41:25 PM, Joe Groff (<a href="mailto:jgroff@apple.com" class="">jgroff@apple.com</a>) wrote:</span></div><div class="" style="font-family:Helvetica,Arial;font-size:13px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><blockquote type="cite" class="clean_bq" style="font-family:Helvetica,Arial;font-size:13px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><div class=""><div class=""></div><div class=""><span><span class=""><br class="">&gt; On Mar 22, 2017, at 4:07 PM, Elijah Johnson &lt;<a href="mailto:ejrx7753@gmail.com" class="">ejrx7753@gmail.com</a>&gt; wrote:<span class="Apple-converted-space"> </span><br class="">&gt;<span class="Apple-converted-space"> </span><br class="">&gt; Hi,<span class="Apple-converted-space"> </span><br class="">&gt;<span class="Apple-converted-space"> </span><br class="">&gt; Note that this thread has branched off a bit, so my latest proposal and the “head” of this thread can be found at<span class="Apple-converted-space"> </span><a href="https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170320/034189.html" class="">https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170320/034189.html</a><span class="Apple-converted-space"> </span><br class="">&gt;<span class="Apple-converted-space"> </span><br class="">&gt;<span class="Apple-converted-space"> </span><br class="">&gt;<span class="Apple-converted-space"> </span><br class="">&gt; Can you give an example of this corruption which would be exploitable in a web server context? An example where, having caught the force-unwrap or other precondition fatalError, that the web server would face more danger from continued execution that it would loose by crashing?<span class="Apple-converted-space"> </span><br class="">&gt;<span class="Apple-converted-space"> </span><br class="">&gt; The optional has been triggered, the request has been stopped, and incoming requests are going to a new process, but there are a few threads open still finishing what they were doing - I’d like to see a good example of the danger caused by a real “inconsistency”. Lets assume also that all objects shared between threads are Swift objects and not “UnsafePointers”, which is a very fair assumtion for a web server. Java even allows native access and they don’t even crash there.<span class="Apple-converted-space"> </span><br class=""><br class="">When considering security threats, we have to take the presence of an exploit as given until we prove otherwise. A precondition failure indicates a logic error somewhere in the program, and while safe Swift abstractions are intended not to lead to memory unsafety in the face of precondition failures, there&#39;s plenty of relatively young, unsafe code below the hood in the implementations of those abstractions, written by humans who make mistakes. Whatever lurking security bugs there may be, they&#39;re more likely to be exploitable if you&#39;re already in a situation where assumptions have been violated.<span class="Apple-converted-space"> </span><br class=""><br class="">&gt; I’m sorry, but I completely fail to grasp the danger as being &gt; crashing.<span class="Apple-converted-space"> </span><br class=""><br class="">Crashing is inconvenient. The user may have to retry their request or relaunch their app. Security breaches or data corruption are disasters that can have unbounded impact and cost—you can&#39;t undisclose sensitive data.<span class="Apple-converted-space"> </span><br class=""><br class="">&gt; I’d be interested to know who these web server developers (ex. Kitura, Vapor) are targeting without any form of crash handling and if they read these threads. It really limits the pool of developers more so than on apps because a single crash on the app ie equivelant to a failed request, not a crashed web server. I realize you are not competing with Java, but I do not see yet the compelling reason for no crash handling.<span class="Apple-converted-space"> </span><br class="">&gt;<span class="Apple-converted-space"> </span><br class="">&gt; The “actors” with thread pool and proccesses is one idea, but I think these servers are aiming also for speed and scaleability - don’t know if they would accept this model. I know that it does get used, and do work for a company that uses it on their backend (just plain Java, not sep. processes). Their front-end probably runs like a pre-fork server, but Java is so stable that there is simply no need for that.<span class="Apple-converted-space"> </span><br class=""><br class="">You can use processes for fault isolation today, and that will have some cost. At Swift&#39;s current maturity level, that&#39;s really probably the only responsible isolation strategy. The goal of &quot;actors&quot; would be to get most of the benefits of processes through language-level isolation without paying the full cost of processes.<span class="Apple-converted-space"> </span><br class=""><br class="">-Joe</span></span></div></div></blockquote></div><p class="" style="font-family:Helvetica,Arial;font-size:13px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"><br class=""></p><p class="" style="font-family:Helvetica,Arial;font-size:13px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">I have no personal objection to actors or processes or anything else. I would just emphasize that the webservers in existence for Swift (and quite well funded) are right now on a “crash the whole thing” model AFAIK. I don’t know if they will be able to get by with catching all the precondition failures in testing - maybe they will - maybe not, but I see people either wisely turning down Swift for web development or getting their first crash as a “zero-day” system down event where some guy has to ssh in and actually start the server back up.</p></div></blockquote>I haven&#39;t worked directly with server people that much personally, but on the opportunities when I have been able to talk to people working in this space, it sounds like they definitely want something better.<br class=""><blockquote type="cite" class=""><div class=""><p class="" style="font-family:Helvetica,Arial;font-size:13px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">But whatever the fix is, or nothing, they (developers of Perfect, Kitura, Vapor, etc) will have to like it and implement it. If they’re not interested, I’m not starting a development company to compete.</p></div></blockquote><div>I don&#39;t see a problem with people developing frameworks to the best of the platform&#39;s ability today and refining their approach as new capabilities get developed.</div><blockquote type="cite" class=""><div class=""><p class="" style="font-family:Helvetica,Arial;font-size:13px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px">And also the development time is so short on my idea that you basically just have to approve it and the development time for it is hours not months or years. Just add a fatalError function override and any c developer could have it done in minutes like this guy <a href="https://github.com/ankurp/unsafe-swift" class="">https://github.com/ankurp/unsafe-swift</a> (not endorsing the post, just showing evidence that setjmp and longjmp work fine with swift).</p><div class="" style="font-family:Helvetica,Arial;font-size:13px;font-style:normal;font-variant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px"></div></div></blockquote></div>setjmp and longjmp do *not* work well with Swift since they need compiler support to implement their semantics, and since Swift does not provide this support, setjmp-ing from Swift is undefined behavior. Empirical evidence that small examples appear to work is not a good way of evaluating UB, since any changes to Swift or LLVM optimizations may break it. Ease of implementation is also not a good criterion for designing things. *Supporting* a trap hook is not easy; it still has serious language semantics and runtime design issues, and may limit our ability to do something better.<div class=""><br class=""></div><div class="">-Joe</div></div></div></blockquote></div><p><br></p><p>Yeah, I suppose. Sounds like it is still about 2-3 years off.</p></div></div></span></blockquote></div><p><br></p><p>But…. what happens when a shared or shared sub-process trips? If something about the process was shared, then it will end up tripping every other process except some master process which will re-generate them.</p><p>Concerning longjmp, it is possible to call from Swift into C, and then from C into Swift (not in the example, but in general). Therefore, assuming that the execution state of the C function is still on the stack at the moment that the exception trips, the jump won’t necessarily involve the Swift runtime or compiler at all, so far as I can see, aside from leaked memory. Granted I don’t know that much about the runtime, but an example might be useful.</p><p>The linked example is was done inline, so a bit different than I was thinking.</p><p>BTW, not sure why no one mentioned it, but apparently the whole idea proposed is already possible without any proposal actually needed. A bit too complex for me and dangerous looking, but heres a nice post with it already done.</p><p><a href="https://www.cocoawithlove.com/blog/2016/02/02/partial-functions-part-two-catching-precondition-failures.html#setting-up-a-mach-exception-handler">https://www.cocoawithlove.com/blog/2016/02/02/partial-functions-part-two-catching-precondition-failures.html#setting-up-a-mach-exception-handler</a></p><div></div></body></html>