Re: [FRIAM] [EXTERNAL] Re: unikernels?

ing Applied Complexity Coffee Group Subject: Re: [FRIAM] [EXTERNAL] Re: unikernels? Thanks! Fascinating. -- Owen On Tue, Aug 11, 2015 at 4:37 PM, Parks, Raymond mailto:rcpa...@sandia.gov> > wrote: The original articles/blogs are from the U of Cambridge Xen folks and a somew

Re: [FRIAM] [EXTERNAL] Re: unikernels?

ct: Re: [FRIAM] [EXTERNAL] Re: unikernels? Thanks! Fascinating. -- Owen On Tue, Aug 11, 2015 at 4:37 PM, Parks, Raymond mailto:rcpa...@sandia.gov> > wrote: The original articles/blogs are from the U of Cambridge Xen folks and a somewhat buzzword lovin' sysadmin. The curre

Re: [FRIAM] [EXTERNAL] Re: unikernels?

riday 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 (no

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 fin

Re: [FRIAM] [EXTERNAL] Re: unikernels?

Thanks! Fascinating. -- Owen On Tue, Aug 11, 2015 at 4:37 PM, Parks, Raymond 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 LInu

Re: [FRIAM] [EXTERNAL] Re: unikernels?

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

Re: [FRIAM] [EXTERNAL] Re: unikernels?

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 wrote: > > OK. But what I'm still missing is this: if unikernels are more domain- > and/or task-specific, then the dev

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 me

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-for

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 vi

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 SC

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 i

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 e

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 e

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

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

Re: [FRIAM] [EXTERNAL] Re: unikernels?

ymond 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-8

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.gov SIPR: rcpar...@sandia.doe.sgov.gov