本文档详细介绍了如何将Open Virtualization (OV) 项目 SierraTEE 移植到Xilinx ZC702开发板上，包括网络启动和SD卡启动的环境搭建，OV编译过程中的问题及源码分析，特别是TrustZone安全内核的执行流程和启动过程。通过网络启动避免了反复更换SD卡的不便，而SD卡启动则将根文件系统设在SD卡，便于文件读写。在编译过程中，文章指出存在某些安全服务未运行的问题，以及源码中libc库的编译过程。
本文档描述将OV项目向ZC702开发板移植的过程。
第一章． 环境搭建
ZC702开发板可以通过SD卡和网络两种方式启动，但是从SD卡启动方式在每次OS内核变化时就需要替换SD卡中的旧OS内核，需要重复插拔SD卡，太过繁琐，不如从网络方式启动方便。这一章便描述如何建立ZC702的网络启动方式，方便以后修改OV内核。
网络环境搭建
ZC702板和开发主机Host按照下图进行连接。Host机是在VMware中安装的Debian 6，网卡配置为桥接方式，IP为10.10.70.101。嵌入式开发板分配IP为10.10.70.102（默认配置）。为了不影响物理机的网络，搭建网络环境如下：
Host tftp nfs环境建立
所谓网络启动方式就是ZC702上的uboot通过tftp协议从Host上获取内核镜像。这种方式需要uboot支持tftp协议，Host支持tftp服务和nfs服务。ZC702的原始uboot就支持tftp，不需要改动，只需要在Host上安装tftp和nfs即可。
Host tftp安装
首先安装tftp：apt-get install tftp tftpd xinetd
然后配置tftp：在/etc/xinet.d/目录下创建文件tftp，并添加如下内容。
service tftp
{
socket_type = dgram
protocol = udp
wait = yes
user = zhao
server =/usr/sbin/in.tftpd
server_args = /home/zhao/xilinx/tftp #替换为你的目录，注意权限
disable = no
per_source = 11
cps =1002
flags = IPv4
}
重启tftp：
#/etc/init.d/xinetdreload
#/etc/init.d/xinetdrestart
测试tftp：首先在tftp的共享文件夹下创建一个文件test，添加内容abcdefgh；然后在另外一个目录下运行
$tftp 10.10.70.101
tftp>get test
Received 10 bytes in 0.0 seconds
Host nfs安装
参考自：http://billforums.station51.net/viewtopic.php?f=1&t=17
首先安装nfs：apt-get install nfs-kernel-server portmap nfs-common
然后配置Host上的nfs服务。编辑/etc/exports文件，添加根文件系统路径(rootpath)：
/home/zhao/xilinx/tftp/fs 10.10.70.102(rw,fsid=0,insecure,no_subtree_check,async,no_root_squash)
/home/zhao/xilinx/tftp 10.10.70.102(rw,fsid=0,insecure,no_subtree_check,async)
网络方式启动OV
环境搭建好以后，就可以通过网络方式启动OV了。首先将编译好的SierraTEE.bin复制到tftp服务器的目录/home/zhao/xilinx/tftp/，然后在ZC702启动后在uboot上运行如下命令：
tftp 0x3c000000SierraTEE.bin; go 0x3c000000;
这样就将SierraTEE.bin启动了。
SD卡启动OV并且使用SD做根设备
OV自带的N world Linux内核引导器将内核启动的命令行参数写在 里，启动方式为虚拟盘作根文件系统。若改为SD卡分区作根文件系统，需要以下改动
1. 给SD卡重新分区(之前需备份SD内容)：使用fdisk命令给SD卡分区，分为fat32(500M)+ext2(其余SD卡空间)两个分区，fat32为第一个分区，供boot_rom读取boot.in(fsbl+uboot)和uboot读取sierratee.bin;第二个ext2分区作根文件系统，将OV提供的根文件系统内容复制到该分区。使用如下命令:
fdisk /dev/mmcblk0;
n(新建分区)
p(主分区)
1(主分区号1)
11(起始位置11柱面)
+500M(分区大小)
第二个分区类似建立
mkdosfs /dev/mmcblk0p1 (第一个分区格式化为fat32类型)
把boot.bin和sierratee.bin等启动必须得文件(sd卡中原来的所有内容)拷贝到第一个分区
mkfs.ext2 /dev/mmcblk0p2(第二个分区格式化为ext2类型)
将虚拟盘中内容拷贝至该分区
2. 由于引导器的内核启动参数已经写死在程序里，无法修改，因此对内核编译配置项进行修改，设置自己的启动参数，并忽略引导器传递过来的启动参数，将根文件系统从虚拟盘改成SD卡的ext2分区。
修改Xilinx_dir/kernel/first/linux-xlnx/arch/arm/configs/zynq_base_trd_defconfig配置文件的CONFIG_CMDLINE配置项：
CONFIG_CMDLINE="console=tty0 console=ttyPS0,115200 noinitrd root=179:2rw ip=192.168.0.91:::255.255.255.0:ZC702:eth0 earlyprintk mem=512Mmemmap=128M$0x30000000 vmalloc=256M"
设置CONFIG_CMDLINE_FORCE项，使内核强制使用上面的启动参数，忽略引导器传递的阐述
CONFIG_CMDLINE_FORCE=y
重新执行Xilinx_dir下的build.sh，生成新的sierratee.bin,放入sd卡的fat32分区中
启动开发板，走到uboot shell界面下，运行下面的命令
mmcinfo
fatload mmc 0 0x3c000000 sierratee.bin
go 0x3c000000
之后ov启动，至N world的LINUX系统启动，此时的文件系统位于sd卡的ext2分区中，文件读写均会实际保存到sd卡中。
第二章． 编译OV项目
编译方式主要依据OV代码中的README文档。但是此README写的太过简略，甚至有的地方还有错误。本章主要简略描述OV的编译流程以及与README文档编译过程不同的步骤。本此编译正常世界只有一个Guest OS的情况。
Sierraware公司提供的适用于ZC702板的OV源代码编译过程主要受build.sh脚本控制，这个脚本主要有如下几个功能：
1. 编译Linux内核，编译过程中打上TrustZone补丁。
2. 将1的内核加上一个引导器，使其可以被TEE的安全OS引导。
3. 编译TEE，即Monitor软件和TEE OS，然后利用2编译的Linux内核镜像共同生成能够在ZC702上运行的二进制代码。此外，这一步还生成了一些可信应用客户端，用于测试TEE OS的安全服务。
4. 生成根文件系统，生成过程会将3生成的可信应用客户端放入根文件系统中的/root/otz/目录下。
5. 利用4新生成的根文件系统重新生成Linux内核。
6. 利用4新生成的根文件系统重新生成运行在ZC702上的二进制文件。
除了按照README文档修改以外，还需要对trustzone/tzone_sdk目录下的Makefile做如下修改：
1. 修改根文件系统目录，指向OV提供的ZC702专用根文件系统：
ROOT_FILE_SYSTEM_IMAGE:= /home/zhao/xilinx/Xilinx_dir/filesystem/first/ramdisk8M.image.gz
#ROOT_FILE_SYSTEM_IMAGE:= $(SDK_PATH)/../otz_linux/armv5t_min_EB_V6_V7.image
2. 修改板子参数：
#export BOARD:= VE
export BOARD:= zynq7
export ARM_CPU:=CORTEX_A9
#export ARM_CPU:=CORTEX_A15
完成上述修改就可以运行buid.sh生成运行在板子上的二进制代码了。所有生成的二进制代码都放在trustzone/tzone_sdk/bin目录下，主要包括SierraTEE.bin和一些安全客户端应用程序。下图是开发板上列出的客户端应用程序，和一些运行结果。
存在问题
OV生成了很多个客户端，可以在cp_bin1.sh中将其他的客户端app放入根文件系统。但是在普通世界OS中调用这些客户端都没有任何反应。应该是此OV版本的TEE OS没有运行安全服务。
cp -f$TRUSTZONE_DIR/tzone_sdk/bin/otz_test_app.elf $TMP_MNT1/mnt/root/otz/
cp -f$TRUSTZONE_DIR/tzone_sdk/bin/otz_user_app.elf $TMP_MNT1/mnt/root/otz/
cp -f$TRUSTZONE_DIR/tzone_sdk/bin/otz_virtual_keyboard.elf $TMP_MNT1/mnt/root/otz/
cp -f$TRUSTZONE_DIR/tzone_sdk/bin/otz_play_media.elf $TMP_MNT1/mnt/root/otz/
cp -f$TRUSTZONE_DIR/tzone_sdk/otz_api/build/libotzapi.so $TMP_MNT1/mnt/lib/
第三章． 源码分析
编译文件
build.sh负责总的调度，包括内核、TEE OS以及根文件系统的生成。在此主要分析TEE OS部分。buish.sh与trustzone中Makefile的设置使得trustzone目录中本质执行如下MAKE命令：
$(MAKE) -C $(SDK_PATH)/sierratee
sudo rm -rf sierratee/mmc_fs
boot:
$(MAKE) -C$(SDK_PATH)/sierratee boot
ENABLE_LIBCRYPT：是否产生openssl
TrustZone执行流程
此次编译没有让安全内核运行在单独的一个物理内核上，安全世界与正常世界共同使用CPU。下面是OV系统的启动流程：
CPU：CPU.S进行一些初始化操作，然后跳转到C语言的Secure_main函数。
|
Secure_main（Main_Secure.C）：这个函数可以看作是安全内核的入口，首先进行一些系统初始化工作，然后将libc.o库以及用户的安全服务（）映射到安全世界的内存空间（技术细节有待学习）：
/*Load 'C' library to memory */
load_libc_to_memory();
load_user_app_to_memory();
然后通过sa_create_entry_point创建dispatcher（OTZ_SVC_GLOBAL）和linux服务（OTZ_SVC_LINUX，不知道这个服务是干什么的，以后学习），成为S世界第一次运行的服务。linux_task会调用invoke_ns_kernel将CPU切换到N世界。Invoke_ns_kernel函数将寄存器r0设置为INVOKE_NON_SECURE_KERNEL，然后调用SMC指令进入Monitor模式。Monitor模式执行下面的宏定义代码，然后跳转到正常世界。
.macro mon_switchto_nsworld_ctx
GET_CORE_CONTEXTs_sys_current
bl save_context
GET_CORE_CONTEXTns_sys_current
bl restore_context
@clear local monitor
@-------------------
clrex
.endm
|
之后N、S世界通过SMC指令调用互相转换。
开机后的引导过程
通过阅读ug585-Zynq-7000-TRM.pdf和ug821-zynq-7000-swdev.pdf两篇技术文档，可知开发板加电开机之后至安全内核启动共分三部分:boot_rom,第一阶段引导程序fsbl,第二阶段引导程序(uboot)
1.首先执行片上rom中的boot_rom引导程序，引导模式由板子上的strapping
Pins决定，引导模式包括Quad-SPI, SD card, NANDFlash,NOR Flash,JTAG.四种，决定boot_rom从哪种设备上加载用户自定义的引导程序。
2.boot_rom根据boot_mode从相应设备上加载boot_image，boot_image包含第一，第二阶段引导程序(fsbl和uboot)。boot_image必须包含一个满足特定格式，能够被boot_rom识别的boot header。根据说明文档，厂商提供了一个boot_image的生成工具boot_gen和一个fsbl模板程序的源代码，并已经烧写到板子的flash中，具体的boot_image生成过程和boot_image的文件格式请参考上面两篇说明文档，由于flash中已存在厂商提供的boot_image，不用自己生成,细节不再深究。Boot_rom根据boot_header,首先将fsbl加载至片上ram(OCM)中，并将控制权移交给fsbl
3.fsbl加载第二阶段引导程序至ddr内存中，厂商提供的boot_image中使用的第二阶段引导程序是uboot，由于boot_image已经烧写进flash中，因此我们开机后会直接走到uboot界面，之后在uboot下启动OV。
libc库编译过程
OV的编译工具提供了一个标准C库的静态库libc.a（还有数学库libm.a，以及一个不知道干什么用的libg.a库）。OV利用此库还有自身编写的一些底层C函数为运行在安全世界中的安全服务提供了C库的支持，极大的方便了开发者开发自己的安全服务。下面描述OV对libc的编译过程，可以借用他们的方法编译其他的函数库或者密码学库。
下面的Makefile语句就是编译libc库的基本过程，大体可以分为如下几个步骤：
1. 统计OV自身提供的libc库二进制文件（.o文件）。其实这些文件最初已经在src/lib/usr, kernel和common目录中的objects.mk文件统计了，下面的Makefile语句只是将这些二进制文件统计到变量libc-objs-y中。libc-objs-y记录了需要编译的二进制libc文件。
libc-objs-y = $(foreachobj,$(lib-common-objs-y),$(libc_build_dir)/lib/common/$(obj))
libc-objs-y += $(foreachobj,$(lib-user-objs-y),$(libc_build_dir)/lib/user/$(obj))
libc-objs-y +=$(foreach obj, $(ulib-cpu-objs-y), $(libc_build_dir)/arch/arm/$(ARCH_DIR)/$(obj))
2. 编译libc-objs-y记录的二进制文件。
a) 首先为每个.o文件生成.deps文件，即.o文件所依赖的源文件（包括.c和.s文件），可能是为了调试使用。下面Makefile语句的意思就是为$(src_dir)中的每个.S和.c文件在相应的$(libc_build_dir)目录中产生.dep文件。$@以及$<等自动化变量的解释参考附录A。
$(libc_build_dir)/%.dep:$(src_dir)/%.S
@echo"gen libc-dep file"
$(V)mkdir -p `dirname $@`
$(if$(V), @echo " (as-dep) $(subst$(libc_build_dir)/,,$@)")
$(V)echo-n `dirname $@`/ > $@
最低0.47元/天 解锁文章
扫一扫
3529
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
