User:Carit

From Trusted Cloud Group
Jump to: navigation, search

Carit Zhu(朱旻)

Me.jpg
  • 虚拟机可信计算
  • Windows CE
  • 嵌入式Linux
  • MSN: caritzm@gmail.com

Contents

Contact Info.

  • Email/MSN: caritzm@gmail.com/carit@sjtu.edu.cn
  • QQ: 43800143
  • Future Work: own business


论文工作

题目

基于硬件虚拟化技术的跨平台安全保护研究

摘要

  许多操作系统被设计用来管理和控制系统资源,他们往往都具有庞大和复杂的特征,所以他们需要高等级的安全保护。但是先前的安全保护应用程序由于处于不可信的执行环境,所以不能提供足够的保护。并且不同的商业操作系统以及不同的开源操作系统,都拥有自己的设计架构和实现方法,所以传统的安全保护方法需要适应不同的操作系统。

  针对现有安全保护上的不足,本次课题采用硬件虚拟化技术来达到轻量级的有效的跨平台的系统保护。虚拟化技术可以使得虚拟机和监控层运行环境之间高度隔离,所以即使虚拟机处于不可信的执行环境也不会影响到监控程序的运行。并且虚拟机监控程序处于相对虚拟机操作系统更高的特权级,使得它能够监控虚拟机运行以及获得更多硬件资源的权利。无论恶意代码在操作系统哪个特权级下运行,监控程序都能够有探测以及阻止它们运行的权力,而处于操作系统运行的程序都无法检测到该安全监控程序的存在。

  本论文提出了一个基于硬件虚拟化并提供可信执行环境的虚拟机监控程序来监控在操作系统下各种不同的恶意行为,称为VASP。该平台主要体现了三大创新优点。首先,该保护平台是一个轻量级的低系统开销的虚拟机监控平台。利用了代码优化,最大限度地降低了虚拟机监控程序的大小,从而减小了可信计算基础的体积,使得监控层更加安全有效。并且在保护过程中尽量减少对操作系统执行过程的影响,使得监控开销降到最低。

  其次,本课题实现的保护机制提供了跨操作系统平台的支持,并且在多数保护过程中无需修改操作系统源代码。在实现过程中,VASP仅仅需要根据操作系统中调用锁机制以及内存分配机制的相关API函数进行匹配执行,其余的代码都和操作系统平台无关。在监控拦截过程中得益于x86的硬件虚拟化技术,使得拦截行为都由CPU硬件完成,无需软件参与。

  最后,VASP保护平台可以提供对多种系统保护的支持,包括I/O访问保护、系统反调试保护以及内存访问保护等。并且还可以在这个基础上通过增加系统功能的形式,扩展添加更多的系统保护机制。同时,VASP也实现了自我保护机制,即内存自透明技术。该机制可以使得虚拟机监控程序无法被虚拟机操作系统通过虚拟内存访问来发现自身的存在。

  本次论文课题的设计目的在于建立一个完全驻留于操作系统运行环境以外的极小开销的安全监控程序。通过实验可以证明基于硬件虚拟化的跨平台安全保护机制能够有效地防止某些恶意行为的侵害,并可以对不同操作系统平台,如Windows XP和Fedora Linux,提供安全保护,而且只减少了微小的系统开销。

参考文献

1. [SOSP'2003 Xen and the art of virtualization]
2. [OSDI'2010 The turtles project: Design and implementation of nested virtualization]
3. [DASC'2007 iKernel: Isolating buggy and malicious device drivers using hardware virtualization support]
4. [SOSP'2007 SecVisor: A tiny hypervisor to provide lifetime kernel code integrity for commodity OSes]
5. [S&P'2010 TrustVisor: Efficient TCB Reduction and Attestation]
6. [OSDI'2006 Splitting interfaces: Making trust between applications and operating systems configurable]
7. [IBM J. Res. Dev'1983 System/370 extended architecture: design considerations]
8. [DSN'2008 Towards an understanding of anti-virtualization and anti-debugging behavior in modern malware]
9. [ASPLOS'2008 Overshadow: a virtualization-based approach to retrofitting protection in commodity operating systems]
10.[VEE'2009 BitVisor: a thin hypervisor for enforcing i/o device security]

个人答辩资料

开题报告相关(ftp目录:paper/2011/1080379036_朱旻/开题)

中期报告相关(ftp目录:paper/2011/1080379036_朱旻/中期检查)

毕业答辩PPT(ftp目录:paper/2011/1080379036_朱旻/毕业答辩PPT)

已发表论文(ftp目录:paper/2011/1080379036_朱旻/发表论文)

毕业论文(ftp目录:paper/2011/1080379036_朱旻/毕业论文)

Related Links

虚拟机与可信计算
history work record of ZhuMin
BIOS中断向量表查询
Zion开发文档
嵌入式开发学习记录
RedHat Enterprise Linux 5
脑电蓝牙传输项目文档

Laboratory Work

Memory Management

  1. 功能:
  2. 详细分析参见


Zion VMOS

  • 终极目标:在X86(Intel VT-x支持)的机器上搭建Virtualization System,把Windows XP起起来。
  • 初级阶段目标:先将一个Linux起起来。
  • 阶段任务:
1. 在BIOS之后,配置CPU属性,载入hypervisor。
2. hypervisor进行虚拟化管理,重点是CPU虚拟和内存虚拟。
  • 在初级阶段,由于只起一个OS,因此其余的设备让其透明访问。
3. 由hypervisor创建VM,让guest OS起起来。

Zion开发文档

Papers I have read

USENIX 08 Bridging the Gap between Software and Hardware Techniques
VEE 08 Using Hypervisor to Provide Data Secrecy for User Applications

对MSR寄存器的访问

  • MSR寄存器其实是一组或者说一堆寄存器,所以手册上的MSR address是指该MSR寄存器在这个MSR寄存器组中的ID编号,而访问的时候需要使用指令RDMSR、WRMSR进行读写操作。而读写前设置ECX来确定是对哪个MSR寄存器进行操作,指令说明:

RDMSR 0F 32 不影响标志位 把ECX指定的模型专用寄存器内容送EDX:EAX RDMSR
WRMSR 0F 30 不影响标志位 把EDX:EAX的内容写入ECX指定的模型专用寄存器 WRMSR
实例代码如下:
mov ecx, MSR_DEBUGCTL
RDMSR

mov ecx,MSR_DEBUGCTL
mov eax,0x1c
WRMSR

讨厌的gedit备份文件

用GNOME的人都知道,gedit打开文档后都会产生一个原文件名后缀一个~的新文件。如果用gedit久了,估计到处都会有它的踪迹了!

1,这个问题可以用vi来代替解决,而gedit本身也可以设置:
"Preference"-->"Editor"去掉每次打开产生备份文件的选项就可以了

2,删除已经产生的这种文件,可是又不知道在哪里,可以用bash脚本实现:
[root@workstation:/home/leeyee]$find / -name "*~" -print -exec rm -f {} \;

在latex中加下划线

发现latex不能直接使用“_”,会出现编译错误,而直接使用"\_"的效果又不好,今天发现一个不错的解决方案:
使用\rule[-2pt]{0.2cm}{0.5pt}, 第一个参数表示下划线下沉尺寸;第二个表示线长;第三个表示线粗。

嵌入式Linux学习

发生异常时系统的处理顺序(转载)

  • 1.系统首先判断异常是否应发送给目标程序的异常处理例程,如果决定应该发送,并且目标程序正在被调试,则系统

挂起程序并向调试器发送EXCEPTION_DEBUG_EVENT消息.呵呵,这不是正好可以用来探测调试器的存在吗?

  • 2.如果你的程序没有被调试或者调试器未能处理异常,系统就会继续查找你是否安装了线程相关的异常处理例程,如果

你安装了线程相关的异常处理例程,系统就把异常发送给你的程序seh处理例程,交由其处理.

  • 3.每个线程相关的异常处理例程可以处理或者不处理这个异常,如果他不处理并且安装了多个线程相关的异常处理例程,

可交由链起来的其他例程处理.

  • 4.如果这些例程均选择不处理异常,如果程序处于被调试状态,操作系统仍会再次挂起程序通知debugger.
  • 5.如果程序未处于被调试状态或者debugger没有能够处理,并且你调用SetUnhandledExceptionFilter安装了最后异

常处理例程的话,系统转向对它的调用.

  • 6.如果你没有安装最后异常处理例程或者他没有处理这个异常,系统会调用默认的系统处理程序,通常显示一个对话框,

你可以选择关闭或者最后将其附加到调试器上的调试按钮.如果没有调试器能被附加于其上或者调试器也处理不了,系统 就调用ExitProcess终结程序.

  • 7.不过在终结之前,系统仍然对发生异常的线程异常处理句柄来一次展开,这是线程异常处理例程最后清理的机会.

Linux中的3种timer(转载)

  • Linux中有3种timer:
  • 1、Real Time Clock(RTC):real-time clock (RTC) is a computer clock (most often in the form of an integrated circuit) that keeps track of the current time.
  • 2、Programmalbe Interval Timer(PIT):Programmable Interval Timer (PIT) is a counter which triggers an interrupt when it reaches the programmed count.
  • 3、Time Stamp Counter.(TSC):The Time Stamp Counter is a 64-bit register present on all x86 processors since the Pentium. It counts the number of ticks since reset
其中RTC是位于CMOS中的,其频率范围是2HZ--8192HZ.
PIT主要由8254时钟芯片实现的
TSC的主体是位于CPU里面的一个64位的TSC寄存器。每个CPU时钟周期其值加一。
  • 但这三者的具体联系介绍一下:
  • RTC是PC主板上的晶振及相关电路组成的时钟电路的生成脉冲,RTC经过8254电路的频产生一个频率较低一点的OS(系统)时钟TSC,系统时钟每一个cpu周期加一,每次系统时钟在系统初起时通过RTC初始化。8254本身工作也需要有自己的驱动时钟(PIT),可以参考一些单片机方面的书籍。
  • 8254本身只是一个定时/计数器,他本身要正常工作需要一个晶振的支持,就好像一个将1mA的电流放大到1A的放大器本身工作也需要一个驱动电流一样,4.194304MHz应该就是你的8254的工作晶振,4.194304MHz不是RTC,RTC是输入给8254的脉冲,经过分频产生os时钟,linux每个系统时钟周期10ms,cpu本身工作(处理指令,数据)也有自己的指令周期,他们是不同的。
Personal tools
Namespaces
Variants
Actions
Navigation
Upload file
Toolbox