Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

XSA-108 Advisory

xenbits.xen.org

Post reply on HN
Print view View original

91–97 of 97 posts

Re: XSA-108 Advisory

#91

Post by comex »

semenko wrote: post #90
comex wrote: post #89

I wonder if Amazon or someone will take the time to make a ksplice-like system for Xen so that future security upgrades probably won't have to go through such disruptive reboot events. (Or, for that matter, whether they considered making an ad-hoc machine code patch - based on the source patch, it looks like it would probably be doable just by changing a few bytes. I guess it's a bit risky...)

Seems a little unlikely, given Ksplice's patents (now Oracle's patents) covering the area. From an older post @ https://news.ycombinator.com/item?id=2791756 The first is "Method of finding a safe time to modify code of a running computer program": http://bit.ly/ksplice-1 The second is "Method of determining which computer program functions are changed by an arbitrary source code modification": http://bit.ly/ksplice-2

Sigh. That's obnoxious - yet another example of software patents confusing proving that an idea is commercially valuable with inventing it in the first place. Anyone with the requisite skills in reverse engineering, compilers, etc. could have told you that hot patching functions in memory is possible and would take at most a few minutes to notice that this may be unsafe if some suspended thread is sitting in a function prolog. Yet "identifying a portion of executable code to be updated in a running computer program; and determining whether it is safe to modify the executable code of the running computer program without having to restart the running computer program" (an actual claim, not the abstract or title quotes that people tend to misconstrue) is now locked out for the next decade or so.

Re: XSA-108 Advisory

#92

Post by liuw »

mappu wrote: post #85

The advisory says PV is safe and HVM is dangerous. What about PV-HVM? Got a reasonably long list of VPS providers to submit tickets to.

PVHVM is HVM with PV drivers, so it's still HVM. Don't hesitate to submit your tickets.

Re: XSA-108 Advisory

#93

Post by girvo »

snowwrestler wrote: post #88
sudowhodoido wrote: post #47

Earlier quoted context omitted.

In the age of high level languages and compilers, that's exactly what they should have done, possible twice by now.

Haven't they? I thought x86 was now basically just a legacy compatibility layer on top of significantly more streamlined and optimized RISC-like operations.

I think that's true, but the problem is end-users don't have access to that layer, do they?

Re: XSA-108 Advisory

#94

Post by caf »

sudowhodoido wrote: post #25
joosters wrote: post #14

Earlier quoted context omitted.

This is just FUD and in the usual insulting De Raadt style of communicating. 'barely has correct page protection' is just a way of saying 'has correct page protection, but I want to be really snotty about it'. So, highlighting a non-problem. No-one is claiming that virtualization makes a system magically completely secure, but do people actually believe that it makes it less secure? (Compared to, running the same sof…

Not really. He's right. The memory, paging and protection model for X86 is fugly at best. It's very easy to hang yourself as demonstrated. You can be as insulting as you like if you compare X86 (and X86-64) to SPARC and POWER which is what I assume he is doing here considering he provides operating systems for multiple architectures. We're talking about an architecture that started with the 8086 and despite changes t…

This vulnerability doesn't appear to have anything to do with the "memory, paging and protection model for X86".

It's just a common-or-garden access beyond the end of an array.

Re: XSA-108 Advisory

#96

Post by soren »

comex wrote: post #89

I wonder if Amazon or someone will take the time to make a ksplice-like system for Xen so that future security upgrades probably won't have to go through such disruptive reboot events. (Or, for that matter, whether they considered making an ad-hoc machine code patch - based on the source patch, it looks like it would probably be doable just by changing a few bytes. I guess it's a bit risky...)

There's a paper on live updating Xen to be presented next month at a cloud computing security workshop: https://www.trust.informatik.tu-darmstadt.de/publications/pu...

Re: XSA-108 Advisory

#97

Post by ewams »

joosters wrote: post #14
sudowhodoido wrote: post #10

Well looks like Mr De Raadt was right again: 'x86 virtualization is about basically placing another nearly full kernel, full of new bugs, on top of a nasty x86 architecture which barely has correct page protection. Then running your operating system on the other side of this brand new pile of shit. You are absolutely deluded, if not stupid, if you think that a worldwide collection of software engineers who can't writ…

This is just FUD and in the usual insulting De Raadt style of communicating. 'barely has correct page protection' is just a way of saying 'has correct page protection, but I want to be really snotty about it'. So, highlighting a non-problem. No-one is claiming that virtualization makes a system magically completely secure, but do people actually believe that it makes it less secure? (Compared to, running the same sof…

Inherently, adding more systems creates more risk vectors. When an application is installed on an operating system, both the OS and application now have to be protected. An example would be Flash ontop of an OS. You have to defend, patch, and architect based on whether your systems have Flash or not.

With virtualization you have the hypervisor that has applications running along with it (ie: ssh, a cli, syslog, bash etc) and then you install a guest in a VM on top of the hypervisor. The OS on the VM is another vector which has applications on it (DB, web, ftp, etc).

If I have a bare metal server with just an OS installed on it and its applications on top of that, I only have to worry about that set of OS and applications and their associated risk vectors.

If I have a bare metal server with a hypervisor and then the above OS and set of applications, I have increased the number of risk vectors by however many applications are running along with the hypervisor.

“but do people actually believe that it makes it less secure?”

Just bringing a hypervisor into an environment does not of itself immediately make it less secure. I agree with you, I don’t think it makes it less secure. It does increase the risk of the environment and appropriate architecture and action must be taken to prevent your statement from being true. A large number of environments do not architect and manage properly.

Another very realistic, and happening today, example: Bare metal server with Windows OS installed. Bare metal server with a hypervisor which just happens to have bash on it (or is susceptible to this memory issue). The same Windows OS is installed as a VM. In the second instance with the hypervisor I would have, indirectly and out of my immediate control, made my environment less secure.

An increase in complexity or increase in components will increase the risk of an environment.

Post reply on HN