Re: [FRIAM] [EXTERNAL] Re: unikernels?
Dear FRIAM, I apologize for this REPLY TO ALL error. I was actually reaching out to Owen about an old private argument concerning what was appropriate for FRIAM. I hope you all will forgive me. Nick Nicholas S. Thompson Emeritus Professor of Psychology and Biology Clark University http://home.earthlink.net/~nickthompson/naturaldesigns/ http://home.earthlink.net/~nickthompson/naturaldesigns/ From: Nick Thompson [mailto:nickthomp...@earthlink.net] Sent: Tuesday, August 11, 2015 9:58 PM To: 'The Friday Morning Applied Complexity Coffee Group' friam@redfish.com Subject: RE: [FRIAM] [EXTERNAL] Re: unikernels? Hi Owen, How’s your summer. I note that not only can glen and company participate in a conversation with me that bores the living crap out of you, but they can also participate in a conversation with you that bores the living crap out of me. But I am not threatening to pick up my marbles and go home. I think it’s in the nature of things. They are multitalented bores. Polybores, we might call them. I guess being a polybore is the other side of being a polymath. Nick Nicholas S. Thompson Emeritus Professor of Psychology and Biology Clark University http://home.earthlink.net/~nickthompson/naturaldesigns/ http://home.earthlink.net/~nickthompson/naturaldesigns/ From: Friam [mailto:friam-boun...@redfish.com] On Behalf Of Owen Densmore Sent: Tuesday, August 11, 2015 7:41 PM To: The Friday Morning Applied Complexity Coffee Group friam@redfish.com Subject: Re: [FRIAM] [EXTERNAL] Re: unikernels? Thanks! Fascinating. -- Owen On Tue, Aug 11, 2015 at 4:37 PM, Parks, Raymond rcpa...@sandia.gov mailto:rcpa...@sandia.gov wrote: The original articles/blogs are from the U of Cambridge Xen folks and a somewhat buzzword lovin' sysadmin. The current trend in using someone else's computer (SEC, more commonly called cloud) is LInux containers and docker. The articles predict that the future is unikernels. A unikernel is application specific, like containers, but in the form of a monolithic VM that includes the specific application and necessary kernel services for that app. At least two of the current unikernel projects use functional languages - OCaml and Haskell. The Xen model is for a developer to specify the kernel services they need, develop the application code, develop the configuration code, and the whole thing gets turned into a monolithic VM that runs in the Xen hypervisor. In theory, this makes for greater efficiency and less chance of the tail wagging the dog. By that latter, I mean that one of the major issues in securing computer systems of systems is that one gets all of a system one includes (i.e DNS Bind) even though one uses one small feature. That means all of the vulnerabilities as well as all the features that are not used. As I said in a previous post, this is a reinvention (for hypervisors) of IBM VM and CSM - the latter being a minimalist kernel with, usually, a single application. The downside of monolithic VMs is that any change requires a complete rebuild of the VM - even minor configuration changes that are the equivalent of environment variables. In a SEC environment, for example, adding a static or CDN to the list of sources for a web server will require a rebuild. Alternatively, of course, one could simply allow the web-server unikernel to invoke scripts from any web-site recursively - but then an attacker simply inserts an advertisement that invokes malware and we're no better off than before. The idea of unikernels is not bad nor is it new - but the benefits will probably not be as great as the current promises. The UX will not be different for the end-user although it might be somewhat better for the content provider. It's not clear to me that the visionaries have thought about this outside of the WWW. For example, I recently read an article about how NetFlix worked hard to be able to provide streaming video with SSL encryption. They started with their standard server and added SSL - the performance hit made that impractical. Eventually, they found a configuration of VMs and infrastructure that made the performance hit acceptable. A unikernel that only served SSL-encrypted video would be more efficient than their current VMs running a general-purpose OS plus video streaming software. But configuration changes (newly added caching locations, links that are down, et cetera) would be the bane of a unikernel NetFlix. Each time BGP reports a change, either the video streaming unikernel would need to be rebuilt or there would need to be another layer of unikernel that dispatches requests to the video streaming unikernel VMs. But that dispatcher would either need to be reconfigured or there would need to be another unikernel that tracks network connectivity changes and informs the dispatcher - and now we still have
Re: [FRIAM] [EXTERNAL] Re: unikernels?
OK. But there are 2 types of commands (that may not crash): 1) those that are ill-formed and 2) those that are well-formed but not expected/predicted by the developers. Ill-formed commands that still don't crash may have partial effects, right? For example, in a lazy language, if the ill-formed part occurs later in the expression, then the well-formed first part is still executed. In the context of a deployable that is configured (constrained to a sub-region of it's possible behavior), we need some way of ensuring the crispness of the boundary: these commands are allowed, these other one's are not. Could these be loopholes in strong but non-strict languages? The usual problem that occurs in non-strict languages are thunk leaks.I plan to plan to plan to plan ... to do something.. Delayed failure can occur too, but for me it is much less common then, say, ad-hoc type handling in a dynamically-typed language. I think it just comes down to the degree to which the developer articulates the constraints on the context as types, and then whether the language has the property of really enforcing those types.Also there's the problem of what happens when the developer just can't get across what they want in the types. Either because they can't be bothered or because the type system isn't versatile enough. I think these security issues come down to limitations in human attention. Tools and languages can help with that, but obsessiveness is needed too. Marcus FRIAM Applied Complexity Group listserv Meets Fridays 9a-11:30 at cafe at St. John's College to unsubscribe http://redfish.com/mailman/listinfo/friam_redfish.com
Re: [FRIAM] [EXTERNAL] Re: unikernels?
OK. But what I'm still missing is this: if unikernels are more domain- and/or task-specific, then the dev environment will branch, perhaps quite a bit. I.e. one dev environment for many deployables. We end up with not just the original (false?) dichotomy between config and compiled, but meta-config and, perhaps, meta-compiled. And that may even have multiple layers, meta-meta. So, while I agree pwning the devop role allows the attacker to infect the deployables, the attacks have to be sophisticated enough to survive that branching to eventually achieve the attacker's objective. I.e. closeness in terms of automation doesn't necessarily mean closeness in terms of total cost of attack. It just seems that the more objective-specific the deployable(s), the less likely a hacked devops process will give the desired result. I'd expect a lot more failed integration/deployment attempts if my devops process was modified. But this is all too abstract, of course. The devil is in the particulars. On 08/11/2015 01:13 PM, Parks, Raymond wrote: I would expect the dev environment to be closer if not actually in the same hypervisor. It's almost like the web-site we once attacked by using the java compiler on the web-site's computer sytem to modify the code in the web-site. Right now, with devops, the dev environment is probably not in the cloud/hypervisor. And, for unikernels that may also be true. But to deploy quickly in both devops and unikernel, there has to be a direct channel from dev to cloud. In more traditional environments, there's a dev server in a separate space, a testing server in its own environment (sometimes shared with production but not touching production data), and a production server. While traditional environments don't always follow the process well, in theory the flow is developers develop on a development network with the dev server, roll their system into the testing server which runs alongside the production server with a copy of the production data and processing real or test transactions, and finally install the tested version on the production server. From my standpoint, that means I can attack the production server directly or the development server on a separate network. There has to be connectivity, but it's likely to be filtered, if only to prevent the development server from affecting the production environment. In devops and in future unikernel systems, the pace of change is, of necessity, much faster and the three roles are collapsed into one VM. The VM image is modified in place, given a new name so that rollback is possible, and the management software is told to use the new image instead of the old. One of the principles of cyberwarfare (as formulated in our paper of that name) is that some entity, somewhere, has the privileges to do whatever the attacker wants to do and the attacker's goal is to become that entity. In the case of devops and unikernel, that entity is the developer(s) who make(s) the changes to the VM. In traditional environments, the attacker might need to assume the privileges of several entities. -- glen ep ropella -- 971-255-2847 FRIAM Applied Complexity Group listserv Meets Fridays 9a-11:30 at cafe at St. John's College to unsubscribe http://redfish.com/mailman/listinfo/friam_redfish.com
Re: [FRIAM] [EXTERNAL] Re: unikernels?
Hi Owen, How’s your summer. I note that not only can glen and company participate in a conversation with me that bores the living crap out of you, but they can also participate in a conversation with you that bores the living crap out of me. But I am not threatening to pick up my marbles and go home. I think it’s in the nature of things. They are multitalented bores. Polybores, we might call them. I guess being a polybore is the other side of being a polymath. Nick Nicholas S. Thompson Emeritus Professor of Psychology and Biology Clark University http://home.earthlink.net/~nickthompson/naturaldesigns/ http://home.earthlink.net/~nickthompson/naturaldesigns/ From: Friam [mailto:friam-boun...@redfish.com] On Behalf Of Owen Densmore Sent: Tuesday, August 11, 2015 7:41 PM To: The Friday Morning Applied Complexity Coffee Group friam@redfish.com Subject: Re: [FRIAM] [EXTERNAL] Re: unikernels? Thanks! Fascinating. -- Owen On Tue, Aug 11, 2015 at 4:37 PM, Parks, Raymond rcpa...@sandia.gov mailto:rcpa...@sandia.gov wrote: The original articles/blogs are from the U of Cambridge Xen folks and a somewhat buzzword lovin' sysadmin. The current trend in using someone else's computer (SEC, more commonly called cloud) is LInux containers and docker. The articles predict that the future is unikernels. A unikernel is application specific, like containers, but in the form of a monolithic VM that includes the specific application and necessary kernel services for that app. At least two of the current unikernel projects use functional languages - OCaml and Haskell. The Xen model is for a developer to specify the kernel services they need, develop the application code, develop the configuration code, and the whole thing gets turned into a monolithic VM that runs in the Xen hypervisor. In theory, this makes for greater efficiency and less chance of the tail wagging the dog. By that latter, I mean that one of the major issues in securing computer systems of systems is that one gets all of a system one includes (i.e DNS Bind) even though one uses one small feature. That means all of the vulnerabilities as well as all the features that are not used. As I said in a previous post, this is a reinvention (for hypervisors) of IBM VM and CSM - the latter being a minimalist kernel with, usually, a single application. The downside of monolithic VMs is that any change requires a complete rebuild of the VM - even minor configuration changes that are the equivalent of environment variables. In a SEC environment, for example, adding a static or CDN to the list of sources for a web server will require a rebuild. Alternatively, of course, one could simply allow the web-server unikernel to invoke scripts from any web-site recursively - but then an attacker simply inserts an advertisement that invokes malware and we're no better off than before. The idea of unikernels is not bad nor is it new - but the benefits will probably not be as great as the current promises. The UX will not be different for the end-user although it might be somewhat better for the content provider. It's not clear to me that the visionaries have thought about this outside of the WWW. For example, I recently read an article about how NetFlix worked hard to be able to provide streaming video with SSL encryption. They started with their standard server and added SSL - the performance hit made that impractical. Eventually, they found a configuration of VMs and infrastructure that made the performance hit acceptable. A unikernel that only served SSL-encrypted video would be more efficient than their current VMs running a general-purpose OS plus video streaming software. But configuration changes (newly added caching locations, links that are down, et cetera) would be the bane of a unikernel NetFlix. Each time BGP reports a change, either the video streaming unikernel would need to be rebuilt or there would need to be another layer of unikernel that dispatches requests to the video streaming unikernel VMs. But that dispatcher would either need to be reconfigured or there would need to be another unikernel that tracks network connectivity changes and informs the dispatcher - and now we still have configuration changes and a complex system of unikernels that exist to make it possible. The Internet is a dynamic system that constantly changes - and any system that uses the Internet needs to adapt to constant change. The two ways to do that with unikernels are to have the meta on meta layers I imagine in the previous paragraph or to change the VM unikernels on the fly so the user will eventually get directed to a correctly configured unikernel. That latter means there will be performance hits - how bad those will be is TBD. Ray Parks Consilient Heuristician/IDART Old-Timer V: 505-844-4024 tel:505-844-4024 M: 505-238-9359 tel
Re: [FRIAM] [EXTERNAL] Re: unikernels?
But this isn't just about virtual machines. It's about using type-safe languages so that hardware protection mechanisms are simply not needed.By virtue of it compiling at all, it can be shown to be safe to run. From: Friam [mailto:friam-boun...@redfish.com] On Behalf Of Parks, Raymond Sent: Tuesday, August 11, 2015 1:07 PM To: The Friday Morning Applied Complexity Coffee Group Subject: Re: [FRIAM] [EXTERNAL] Re: unikernels? And, like so many trends in computers, we return to the past. This time, to VM and CMS. Ray Parks Consilient Heuristician/IDART Old-Timer V: 505-844-4024 M: 505-238-9359 P: 505-951-6084 NIPR: rcpa...@sandia.govmailto:rcpa...@sandia.gov SIPR: rcpar...@sandia.doe.sgov.govmailto:rcpar...@sandia.doe.sgov.gov (send NIPR reminder) JWICS: dopa...@doe.ic.govmailto:dopa...@doe.ic.gov (send NIPR reminder) On Aug 11, 2015, at 11:38 AM, Marcus Daniels wrote: And don't overlook the fine work done in the Northwest.. http://galois.com/project/halvm/ ..and in fact going back some time.. http://www-spin.cs.washington.edu/ -Original Message- From: Friam [mailto:friam-boun...@redfish.com] On Behalf Of glen ep ropella Sent: Tuesday, August 11, 2015 11:32 AM To: Complexity Coffee Group Subject: [FRIAM] unikernels? Life in a Post-Container World and Why Linux Will Play a Diminished Role http://thenewstack.io/life-post-container-world/ Unikernels: Rise of the Virtual Library Operating System http://queue.acm.org/detail.cfm?id=2566628 Luckily, Marcus introduced me to ocaml a long time ago, otherwise I'd feel even more out of touch than I already do. -- glen ep ropella -- 971-255-2847 FRIAM Applied Complexity Group listserv Meets Fridays 9a-11:30 at cafe at St. John's College to unsubscribe http://redfish.com/mailman/listinfo/friam_redfish.com FRIAM Applied Complexity Group listserv Meets Fridays 9a-11:30 at cafe at St. John's College to unsubscribe http://redfish.com/mailman/listinfo/friam_redfish.com FRIAM Applied Complexity Group listserv Meets Fridays 9a-11:30 at cafe at St. John's College to unsubscribe http://redfish.com/mailman/listinfo/friam_redfish.com
Re: [FRIAM] [EXTERNAL] Re: unikernels?
And, like so many trends in computers, we return to the past. This time, to VM and CMS. Ray Parks Consilient Heuristician/IDART Old-Timer V: 505-844-4024 M: 505-238-9359 P: 505-951-6084 NIPR: rcpa...@sandia.govmailto:rcpa...@sandia.gov SIPR: rcpar...@sandia.doe.sgov.govmailto:rcpar...@sandia.doe.sgov.gov (send NIPR reminder) JWICS: dopa...@doe.ic.govmailto:dopa...@doe.ic.gov (send NIPR reminder) On Aug 11, 2015, at 11:38 AM, Marcus Daniels wrote: And don't overlook the fine work done in the Northwest.. http://galois.com/project/halvm/ ..and in fact going back some time.. http://www-spin.cs.washington.edu/ -Original Message- From: Friam [mailto:friam-boun...@redfish.com] On Behalf Of glen ep ropella Sent: Tuesday, August 11, 2015 11:32 AM To: Complexity Coffee Group Subject: [FRIAM] unikernels? Life in a Post-Container World and Why Linux Will Play a Diminished Role http://thenewstack.io/life-post-container-world/ Unikernels: Rise of the Virtual Library Operating System http://queue.acm.org/detail.cfm?id=2566628 Luckily, Marcus introduced me to ocaml a long time ago, otherwise I'd feel even more out of touch than I already do. -- glen ep ropella -- 971-255-2847 FRIAM Applied Complexity Group listserv Meets Fridays 9a-11:30 at cafe at St. John's College to unsubscribe http://redfish.com/mailman/listinfo/friam_redfish.com FRIAM Applied Complexity Group listserv Meets Fridays 9a-11:30 at cafe at St. John's College to unsubscribe http://redfish.com/mailman/listinfo/friam_redfish.com FRIAM Applied Complexity Group listserv Meets Fridays 9a-11:30 at cafe at St. John's College to unsubscribe http://redfish.com/mailman/listinfo/friam_redfish.com
Re: [FRIAM] [EXTERNAL] Re: unikernels?
The security improvements of unikernels may be overstated. Look at the announcement, last week, of installing malware on LTE/3G modems built into laptops and tablets [1]. As Rich Murray pointed out in his comment on the subject in SANS Newsbites - these modems are a thing, an appliance, in the Internet of Things. The ability to fix these things is necessary to the developers of the things. Unikernels, with configuration baked in, will have similiar needs. In the case of unikernels, editing of configuration inputs and recompiling/linking will be required instead of a manufacturer's backdoor to update firmware. The development environment to make those configuration changes must be virtually close to the hypervisor runtime environment of the unikernel. That means the development environment will be a target. Of course, the real target will be the unikernel VMs that are poorly configured. The unikernel is the ultimate reaction to the exploit - but it does nothing for attacks that simply use the system as designed to do the attacker's bidding. [1] http://www.computerworld.com/article/2968274/security/internal-lte3g-modems-can-be-hacked-to-help-malware-survive-os-reinstalls.html Ray Parks Consilient Heuristician/IDART Old-Timer V: 505-844-4024 M: 505-238-9359 P: 505-951-6084 On Aug 11, 2015, at 1:06 PM, Parks, Raymond wrote: And, like so many trends in computers, we return to the past. This time, to VM and CMS. Ray Parks Consilient Heuristician/IDART Old-Timer V: 505-844-4024 M: 505-238-9359 P: 505-951-6084 NIPR: rcpa...@sandia.gov SIPR: rcpar...@sandia.doe.sgov.gov (send NIPR reminder) JWICS: dopa...@doe.ic.gov (send NIPR reminder) On Aug 11, 2015, at 11:38 AM, Marcus Daniels wrote: And don't overlook the fine work done in the Northwest.. http://galois.com/project/halvm/ ..and in fact going back some time.. http://www-spin.cs.washington.edu/ -Original Message- From: Friam [mailto:friam-boun...@redfish.com] On Behalf Of glen ep ropella Sent: Tuesday, August 11, 2015 11:32 AM To: Complexity Coffee Group Subject: [FRIAM] unikernels? Life in a Post-Container World and Why Linux Will Play a Diminished Role http://thenewstack.io/life-post-container-world/ Unikernels: Rise of the Virtual Library Operating System http://queue.acm.org/detail.cfm?id=2566628 Luckily, Marcus introduced me to ocaml a long time ago, otherwise I'd feel even more out of touch than I already do. -- glen ep ropella -- 971-255-2847 FRIAM Applied Complexity Group listserv Meets Fridays 9a-11:30 at cafe at St. John's College to unsubscribe http://redfish.com/mailman/listinfo/friam_redfish.com FRIAM Applied Complexity Group listserv Meets Fridays 9a-11:30 at cafe at St. John's College to unsubscribe http://redfish.com/mailman/listinfo/friam_redfish.com FRIAM Applied Complexity Group listserv Meets Fridays 9a-11:30 at cafe at St. John's College to unsubscribe http://redfish.com/mailman/listinfo/friam_redfish.com smime.p7s Description: S/MIME cryptographic signature FRIAM Applied Complexity Group listserv Meets Fridays 9a-11:30 at cafe at St. John's College to unsubscribe http://redfish.com/mailman/listinfo/friam_redfish.com
Re: [FRIAM] [EXTERNAL] Re: unikernels?
If I understand what you're saying, you're still admitting that the attack has to happen at a greater distance from the target, right? Even if the dev env is virtually close, it's still at least 1 step removed from the deployed thing. On 08/11/2015 12:28 PM, Parks, Raymond wrote: The security improvements of unikernels may be overstated. Look at the announcement, last week, of installing malware on LTE/3G modems built into laptops and tablets [1]. As Rich Murray pointed out in his comment on the subject in SANS Newsbites - these modems are a thing, an appliance, in the Internet of Things. The ability to fix these things is necessary to the developers of the things. Unikernels, with configuration baked in, will have similiar needs. In the case of unikernels, editing of configuration inputs and recompiling/linking will be required instead of a manufacturer's backdoor to update firmware. The development environment to make those configuration changes must be virtually close to the hypervisor runtime environment of the unikernel. That means the development environment will be a target. Of course, the real target will be the unikernel VMs that are poorly configured. The unikernel is the ultimate reaction to the exploit - but it does nothing for attacks that simply use the system as designed to do the attacker's bidding. [1] http://www.computerworld.com/article/2968274/security/internal-lte3g-modems-can-be-hacked-to-help-malware-survive-os-reinstalls.html -- glen ep ropella -- 971-255-2847 FRIAM Applied Complexity Group listserv Meets Fridays 9a-11:30 at cafe at St. John's College to unsubscribe http://redfish.com/mailman/listinfo/friam_redfish.com
Re: [FRIAM] [EXTERNAL] Re: unikernels?
On 08/11/2015 12:21 PM, Marcus Daniels wrote: But this isn't just about virtual machines. It's about using type-safe languages so that hardware protection mechanisms are simply not needed.By virtue of it compiling at all, it can be shown to be safe to run. On 08/11/2015 10:32 AM, glen ep ropella wrote: Unikernels: Rise of the Virtual Library Operating System http://queue.acm.org/detail.cfm?id=2566628 What I found most interesting was this blurb: Configuration is a considerable overhead in managing the deployment of a large cloud-hosted service. The traditional split between the compiled (code) and interpreted (configuration) is unnecessary with unikernel compilation. Application configuration is code—perhaps in an embedded domain-specific language—and the compiler can analyze and optimize across the whole unikernel. This (false?) dichotomy keeps arising in almost every conversation I have. And I don't yet have a trunk/root conception of how they all fit together. But my intuition tells me they fit together. Some recent examples: o open-ended evolution (and/or evolution of evolution), broached at ECAL -- the answer I kept giving, that nobody really responded to, includes self-hosted languages (simple circularity) and cycles in hosting (L_0 hosts L_1 which then hosts L_0). o families of models, as opposed to those well- or over-fitted to a given context -- here I'm talking mostly about mathematical vs. agent-based (or other discrete or hybrid) biological models, but it relates to any domain-specificity. o the gen-phen map, polyphenism and neutrality/degeneracy -- the context being the importance of the developmental (configuration/interpretation) path from gene(compiled)-phene and, again, any circularity due to downward causation. -- glen ep ropella -- 971-255-2847 -- ⇔ glen FRIAM Applied Complexity Group listserv Meets Fridays 9a-11:30 at cafe at St. John's College to unsubscribe http://redfish.com/mailman/listinfo/friam_redfish.com
Re: [FRIAM] [EXTERNAL] Re: unikernels?
I would expect the dev environment to be closer if not actually in the same hypervisor. It's almost like the web-site we once attacked by using the java compiler on the web-site's computer sytem to modify the code in the web-site. Right now, with devops, the dev environment is probably not in the cloud/hypervisor. And, for unikernels that may also be true. But to deploy quickly in both devops and unikernel, there has to be a direct channel from dev to cloud. In more traditional environments, there's a dev server in a separate space, a testing server in its own environment (sometimes shared with production but not touching production data), and a production server. While traditional environments don't always follow the process well, in theory the flow is developers develop on a development network with the dev server, roll their system into the testing server which runs alongside the production server with a copy of the production data and processing real or test transactions, and finally install the tested version on the production server. From my standpoint, that means I can attack the production server directly or the development server on a separate network. There has to be connectivity, but it's likely to be filtered, if only to prevent the development server from affecting the production environment. In devops and in future unikernel systems, the pace of change is, of necessity, much faster and the three roles are collapsed into one VM. The VM image is modified in place, given a new name so that rollback is possible, and the management software is told to use the new image instead of the old. One of the principles of cyberwarfare (as formulated in our paper of that name) is that some entity, somewhere, has the privileges to do whatever the attacker wants to do and the attacker's goal is to become that entity. In the case of devops and unikernel, that entity is the developer(s) who make(s) the changes to the VM. In traditional environments, the attacker might need to assume the privileges of several entities. Ray Parks Consilient Heuristician/IDART Old-Timer V: 505-844-4024 M: 505-238-9359 P: 505-951-6084 On Aug 11, 2015, at 1:50 PM, glen ep ropella wrote: If I understand what you're saying, you're still admitting that the attack has to happen at a greater distance from the target, right? Even if the dev env is virtually close, it's still at least 1 step removed from the deployed thing. On 08/11/2015 12:28 PM, Parks, Raymond wrote: The security improvements of unikernels may be overstated. Look at the announcement, last week, of installing malware on LTE/3G modems built into laptops and tablets [1]. As Rich Murray pointed out in his comment on the subject in SANS Newsbites - these modems are a thing, an appliance, in the Internet of Things. The ability to fix these things is necessary to the developers of the things. Unikernels, with configuration baked in, will have similiar needs. In the case of unikernels, editing of configuration inputs and recompiling/linking will be required instead of a manufacturer's backdoor to update firmware. The development environment to make those configuration changes must be virtually close to the hypervisor runtime environment of the unikernel. That means the development environment will be a target. Of course, the real target will be the unikernel VMs that are poorly configured. The unikernel is the ultimate reaction to the exploit - but it does nothing for attacks that simply use the system as designed to do the attacker's bidding. [1] http://www.computerworld.com/article/2968274/security/internal-lte3g-modems-can-be-hacked-to-help-malware-survive-os-reinstalls.html -- glen ep ropella -- 971-255-2847 FRIAM Applied Complexity Group listserv Meets Fridays 9a-11:30 at cafe at St. John's College to unsubscribe http://redfish.com/mailman/listinfo/friam_redfish.com smime.p7s Description: S/MIME cryptographic signature FRIAM Applied Complexity Group listserv Meets Fridays 9a-11:30 at cafe at St. John's College to unsubscribe http://redfish.com/mailman/listinfo/friam_redfish.com
Re: [FRIAM] [EXTERNAL] Re: unikernels?
Glen writes: o open-ended evolution (and/or evolution of evolution), broached at ECAL -- the answer I kept giving, that nobody really responded to, includes self-hosted languages (simple circularity) and cycles in hosting (L_0 hosts L_1 which then hosts L_0). Let's say a device managing a SCSI disk drive. A Unikernel based on a strongly typed language would ensure that illegal or poorly formed SCSI command blocks simply could not be formed.Whether or not a L_1 language hosts a L_0 with a similar virtual device doesn't matter, there's still no way to bypass the typing in the L_0 implementation. In a language like C, it is trivial matter to bypass typing. It's just best-effort by the developer. Marcus FRIAM Applied Complexity Group listserv Meets Fridays 9a-11:30 at cafe at St. John's College to unsubscribe http://redfish.com/mailman/listinfo/friam_redfish.com
Re: [FRIAM] [EXTERNAL] Re: unikernels?
On 08/11/2015 12:21 PM, Marcus Daniels wrote: But this isn't just about virtual machines. It's about using type-safe languages so that hardware protection mechanisms are simply not needed.By virtue of it compiling at all, it can be shown to be safe to run. On 08/11/2015 10:32 AM, glen ep ropella wrote: Unikernels: Rise of the Virtual Library Operating System http://queue.acm.org/detail.cfm?id=2566628 What I found most interesting was this blurb: Configuration is a considerable overhead in managing the deployment of a large cloud-hosted service. The traditional split between the compiled (code) and interpreted (configuration) is unnecessary with unikernel compilation. Application configuration is code—perhaps in an embedded domain-specific language—and the compiler can analyze and optimize across the whole unikernel. This (false?) dichotomy keeps arising in almost every conversation I have. And I don't yet have a trunk/root conception of how they all fit together. But my intuition tells me they fit together. Some recent examples: o open-ended evolution (and/or evolution of evolution), broached at ECAL -- the answer I kept giving, that nobody really responded to, includes self-hosted languages (simple circularity) and cycles in hosting (L_0 hosts L_1 which then hosts L_0). o families of models, as opposed to those well- or over-fitted to a given context -- here I'm talking mostly about mathematical vs. agent-based (or other discrete or hybrid) biological models, but it relates to any domain-specificity. o the gen-phen map, polyphenism and neutrality/degeneracy -- the context being the importance of the developmental (configuration/interpretation) path from gene(compiled)-phene and, again, any circularity due to downward causation. -- glen ep ropella -- 971-255-2847 FRIAM Applied Complexity Group listserv Meets Fridays 9a-11:30 at cafe at St. John's College to unsubscribe http://redfish.com/mailman/listinfo/friam_redfish.com
Re: [FRIAM] [EXTERNAL] Re: unikernels?
On 08/11/2015 01:18 PM, Marcus Daniels wrote: Let's say a device managing a SCSI disk drive. A Unikernel based on a strongly typed language would ensure that illegal or poorly formed SCSI command blocks simply could not be formed.Whether or not a L_1 language hosts a L_0 with a similar virtual device doesn't matter, there's still no way to bypass the typing in the L_0 implementation. In a language like C, it is trivial matter to bypass typing. It's just best-effort by the developer. OK. But there are 2 types of commands (that may not crash): 1) those that are ill-formed and 2) those that are well-formed but not expected/predicted by the developers. Ill-formed commands that still don't crash may have partial effects, right? For example, in a lazy language, if the ill-formed part occurs later in the expression, then the well-formed first part is still executed. In the context of a deployable that is configured (constrained to a sub-region of it's possible behavior), we need some way of ensuring the crispness of the boundary: these commands are allowed, these other one's are not. Could these be loopholes in strong but non-strict languages? -- ⇔ glen FRIAM Applied Complexity Group listserv Meets Fridays 9a-11:30 at cafe at St. John's College to unsubscribe http://redfish.com/mailman/listinfo/friam_redfish.com
Re: [FRIAM] [EXTERNAL] Re: unikernels?
Thanks! Fascinating. -- Owen On Tue, Aug 11, 2015 at 4:37 PM, Parks, Raymond rcpa...@sandia.gov wrote: The original articles/blogs are from the U of Cambridge Xen folks and a somewhat buzzword lovin' sysadmin. The current trend in using someone else's computer (SEC, more commonly called cloud) is LInux containers and docker. The articles predict that the future is unikernels. A unikernel is application specific, like containers, but in the form of a monolithic VM that includes the specific application and necessary kernel services for that app. At least two of the current unikernel projects use functional languages - OCaml and Haskell. The Xen model is for a developer to specify the kernel services they need, develop the application code, develop the configuration code, and the whole thing gets turned into a monolithic VM that runs in the Xen hypervisor. In theory, this makes for greater efficiency and less chance of the tail wagging the dog. By that latter, I mean that one of the major issues in securing computer systems of systems is that one gets all of a system one includes (i.e DNS Bind) even though one uses one small feature. That means all of the vulnerabilities as well as all the features that are not used. As I said in a previous post, this is a reinvention (for hypervisors) of IBM VM and CSM - the latter being a minimalist kernel with, usually, a single application. The downside of monolithic VMs is that any change requires a complete rebuild of the VM - even minor configuration changes that are the equivalent of environment variables. In a SEC environment, for example, adding a static or CDN to the list of sources for a web server will require a rebuild. Alternatively, of course, one could simply allow the web-server unikernel to invoke scripts from any web-site recursively - but then an attacker simply inserts an advertisement that invokes malware and we're no better off than before. The idea of unikernels is not bad nor is it new - but the benefits will probably not be as great as the current promises. The UX will not be different for the end-user although it might be somewhat better for the content provider. It's not clear to me that the visionaries have thought about this outside of the WWW. For example, I recently read an article about how NetFlix worked hard to be able to provide streaming video with SSL encryption. They started with their standard server and added SSL - the performance hit made that impractical. Eventually, they found a configuration of VMs and infrastructure that made the performance hit acceptable. A unikernel that only served SSL-encrypted video would be more efficient than their current VMs running a general-purpose OS plus video streaming software. But configuration changes (newly added caching locations, links that are down, et cetera) would be the bane of a unikernel NetFlix. Each time BGP reports a change, either the video streaming unikernel would need to be rebuilt or there would need to be another layer of unikernel that dispatches requests to the video streaming unikernel VMs. But that dispatcher would either need to be reconfigured or there would need to be another unikernel that tracks network connectivity changes and informs the dispatcher - and now we still have configuration changes and a complex system of unikernels that exist to make it possible. The Internet is a dynamic system that constantly changes - and any system that uses the Internet needs to adapt to constant change. The two ways to do that with unikernels are to have the meta on meta layers I imagine in the previous paragraph or to change the VM unikernels on the fly so the user will eventually get directed to a correctly configured unikernel. That latter means there will be performance hits - how bad those will be is TBD. Ray Parks Consilient Heuristician/IDART Old-Timer V: 505-844-4024 M: 505-238-9359 P: 505-951-6084 On Aug 11, 2015, at 3:25 PM, Owen Densmore wrote: I'm so outta this conversation! Could one of us give a brief explanation of unikernels and the related tech being discussed? On Tue, Aug 11, 2015 at 2:49 PM, glen ep ropella g...@tempusdictum.com wrote: OK. But what I'm still missing is this: if unikernels are more domain- and/or task-specific, then the dev environment will branch, perhaps quite a bit. I.e. one dev environment for many deployables. We end up with not just the original (false?) dichotomy between config and compiled, but meta-config and, perhaps, meta-compiled. And that may even have multiple layers, meta-meta. So, while I agree pwning the devop role allows the attacker to infect the deployables, the attacks have to be sophisticated enough to survive that branching to eventually achieve the attacker's objective. I.e. closeness in terms of automation doesn't necessarily mean closeness in terms of total cost of attack. It just seems
Re: [FRIAM] [EXTERNAL] Re: unikernels?
s/abuse/use/ For about the last 30 years or so, I've been dealing with various sorts of sysadmins who care more about control and ease of administration than they do about making sure the systems are flexible and powerful.For me, bare on the hardware unikernels would be about building the system around apps rather than the other way around. But it is not just security concerns or technical limitations that prevent this from happening.. From: Friam friam-boun...@redfish.com on behalf of glen ep ropella g...@tempusdictum.com Sent: Tuesday, August 11, 2015 5:56 PM To: The Friday Morning Applied Complexity Coffee Group Subject: Re: [FRIAM] [EXTERNAL] Re: unikernels? Well, of course, I'm actually looking for the inverse problem: what is the minimum hole we need to see interesting abuse, e.g. whole new ecosystems of behavior. It seems like strongly typed, lazy (not just non-strict) eval languages capable of higher order logic are the right platform for finding minimal holes of maximal interestingness. On 08/11/2015 02:05 PM, Marcus Daniels wrote: The usual problem that occurs in non-strict languages are thunk leaks.I plan to plan to plan to plan ... to do something.. Delayed failure can occur too, but for me it is much less common then, say, ad-hoc type handling in a dynamically-typed language. I think it just comes down to the degree to which the developer articulates the constraints on the context as types, and then whether the language has the property of really enforcing those types.Also there's the problem of what happens when the developer just can't get across what they want in the types. Either because they can't be bothered or because the type system isn't versatile enough. I think these security issues come down to limitations in human attention. Tools and languages can help with that, but obsessiveness is needed too. -- glen ep ropella -- 971-255-2847 FRIAM Applied Complexity Group listserv Meets Fridays 9a-11:30 at cafe at St. John's College to unsubscribe http://redfish.com/mailman/listinfo/friam_redfish.com FRIAM Applied Complexity Group listserv Meets Fridays 9a-11:30 at cafe at St. John's College to unsubscribe http://redfish.com/mailman/listinfo/friam_redfish.com
Re: [FRIAM] [EXTERNAL] Re: unikernels?
Well, of course, I'm actually looking for the inverse problem: what is the minimum hole we need to see interesting abuse, e.g. whole new ecosystems of behavior. It seems like strongly typed, lazy (not just non-strict) eval languages capable of higher order logic are the right platform for finding minimal holes of maximal interestingness. On 08/11/2015 02:05 PM, Marcus Daniels wrote: The usual problem that occurs in non-strict languages are thunk leaks.I plan to plan to plan to plan ... to do something.. Delayed failure can occur too, but for me it is much less common then, say, ad-hoc type handling in a dynamically-typed language. I think it just comes down to the degree to which the developer articulates the constraints on the context as types, and then whether the language has the property of really enforcing those types.Also there's the problem of what happens when the developer just can't get across what they want in the types. Either because they can't be bothered or because the type system isn't versatile enough. I think these security issues come down to limitations in human attention. Tools and languages can help with that, but obsessiveness is needed too. -- glen ep ropella -- 971-255-2847 FRIAM Applied Complexity Group listserv Meets Fridays 9a-11:30 at cafe at St. John's College to unsubscribe http://redfish.com/mailman/listinfo/friam_redfish.com
