> On 23 Mar 2017, at 02:25, Elijah Johnson via swift-evolution > <swift-evolution@swift.org> wrote: > > On March 22, 2017 at 8:41:25 PM, Joe Groff (jgr...@apple.com > <mailto:jgr...@apple.com>) wrote: >> >> > On Mar 22, 2017, at 4:07 PM, Elijah Johnson <ejrx7...@gmail.com >> > <mailto:ejrx7...@gmail.com>> wrote: >> > >> > Hi, >> > >> > Note that this thread has branched off a bit, so my latest proposal and >> > the “head” of this thread can be found at >> > https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170320/034189.html >> > >> > <https://lists.swift.org/pipermail/swift-evolution/Week-of-Mon-20170320/034189.html> >> > >> > >> > >> > >> > 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? >> > >> > 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. >> >> 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'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're more likely >> to be exploitable if you're already in a situation where assumptions have >> been violated. >> >> > I’m sorry, but I completely fail to grasp the danger as being > crashing. >> >> 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't undisclose sensitive data. >> >> > 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. >> > >> > 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. >> >> You can use processes for fault isolation today, and that will have some >> cost. At Swift's current maturity level, that's really probably the only >> responsible isolation strategy. The goal of "actors" would be to get most of >> the benefits of processes through language-level isolation without paying >> the full cost of processes. >> >> -Joe > > > 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. > > 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. 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 https://github.com/ankurp/unsafe-swift > <https://github.com/ankurp/unsafe-swift> (not endorsing the post, just > showing evidence that setjmp and longjmp work fine with swift). >
This might be a better discussion to have on the swift-server-dev list at https://lists.swift.org/mailman/listinfo/swift-server-dev <https://lists.swift.org/mailman/listinfo/swift-server-dev> where people involved with the web frameworks are discussing such issues in relation to server uptime. At the moment, it is impossible to have Swift code that doesn't contain potentially segfaulting code (even when the developer of such a framework goes out of their way to ensure that the framework doesn't) and so the only way of ensuring that this doesn't occur is with a cgi-bin style model, with fresh processes on each request or a pool of worker processes, and a load balancer in front of the instances, each only handling a single connection at a time. It also becomes necessary to store any session state out-of-process in a data store/cache, so that the server processes are seen as temporary disposable instances. An advantage of that model is that it becomes easier to scale out to a distributed system because all of the pieces that are present are there. Alex
_______________________________________________ swift-evolution mailing list swift-evolution@swift.org https://lists.swift.org/mailman/listinfo/swift-evolution
