Chinaunix首页 | 论坛 | 博客
  • 博客访问: 196788
  • 博文数量: 77
  • 博客积分: 1749
  • 博客等级: 上尉
  • 技术积分: 810
  • 用 户 组: 普通用户
  • 注册时间: 2011-03-28 18:27
文章分类
文章存档

2012年(28)

2011年(49)

分类: LINUX

2012-10-22 20:18:21

P. Karger and D. Safford. I/O for virtual machine monitors: Security and performance issues.
IEEE Security and Privacy, 6(5):16–23, 2008.

The primary reason to believe that a VMM can create stronger isolation between processes is that the VMM can be much smaller and simpler than the OS.
Moving the large, complex, and sometimes proprietary device drivers out of the VMM(in order t okeep it small) may cause inherent trade-offs in complexity, security, and perfoemance.
1. the size and complexity of the software needed to handle the I/O, which impacts system security;
2. the I/O's performance, which impacts all hypervisors, regardless of their security requirements.
First commercially available VMM, called CP-67 used channel programs.
A channel is essentially a special-purpose stored-program computer that's optimized for high-performance I/O;
When a device driver wishes to perform I/O, it writes a channel program that can perform many I/O operations, including conditional operations, all triggered by a single privileged SIO(Start I/O) instruction.
For computers that have not channels, this doesn't work.
In modern I/O architectures, there are several different ways. e.g. Xen, but the inclusion of full OSs in the special privileged I/O partitions reduces its security.
three issues concerns:
1. are device drivers shared?
2. are they trusted?
3. where are they located?
solutions:
1. pure isolation hypervisor, e.g. PR/SM, MILS, Xen with I/O MMU support
VMM be high assurance, but it can be a simple, small code base.
unable to protect side-channel attacks on processor cache or branch predication units
MILS isolates each level of security and doesn't permit sharing across levels.
low performace because of context switching between hypervisor and between the guest partitions.
Incompatibility.
Difficulty of composite evaluation.
If a hypervisor user needs sharing applications, then it would be better to select a sharing hypervisor, rather than trying to implement the sharing on top of an isolation hypervisor.
2. sharing hypervisors on a server
no need to deal with display and keyboard problems, but still do need to handle shared network and storage devices.
If the guest encrypts all traffic for the network device, the nthe device driver can't leak data directly, but there are still covert timing channel and traffic flow analysis channels possible.
3. sharing hypervisors on a client
by far, the most difficult use case for a hypervisor is a client in which all devices must be shared.
4. Special privileged I/O partitions
Xen dom0 or PHYP VIOS
have to ensure security sharing, particularly with respect to issues such as side and covert channels and thus must remain trusted.
There is a fundamental limitation of protection ring systems. MIT-LCS-TR-104 shows how a protection ring system can't suport mutually suspicious subsystems in a single process. This is because all programs in a given protection ring must trust one another, and the hierarchic nature of rings means that they can't be used for mutual suspicion.


阅读(1310) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~