背景
本文将介绍NXP的AHAB
和HAB
机制以及差异,详细说明如何一步步使用CST
工具对镜像进行签名以及验签的过程。
thinking all the time
secure boot
是基于数字签名认证。在启动流程中,第一部分去认证第二部分,以此类推,从而建立信任链。每个组件都使用其数字签名
和public key
验证前面一部分的有效性。
以下使用i.MX平台进行说明。public key
可以存到One-Time-Programmable (OTP) fuses
里面,或者也可以将public key
hash化后(srk fuse)使其size减小并存到OTP
中。在boot启动的时候,ROM code
将存在bootloader中未hash化(srk table)的public key
hash化,然后与OTP
中hash化过的public key
进行比较(因为hash不可逆),如果相等,使用bootloader中未hash化的public key
对已签名的bootloader进行校验。以此类推。如下是i.MX6(i.MX8没有CSF)平台安全启动的流程:
在上图中:
1、在安全的环境中对SW Image
内容hash化生成摘要A
,然后使用private key
对摘要A
进行签名(采用RSA算法),得到SW Image
和Signature
;
2、将该SW Image
和Signature
烧录到flash中后去启动;
3、在启动的时候会将SW Image
内容hash化生成摘要B
(如果SW Image
没有被修改过,摘要A
和摘要B
肯定相等),使用Fuse中的public key
进行对Signature
进行验签得到摘要C
,如果摘要B
和摘要C
相等,表示认证成功,就去启动OS。
注意,这里i.MX处理器中芯片存储的是SRK
,而不是hash化后的值,所以该SRK
可以直接进行验签。
新冠疫情期间在家里无事可做,奈何手上没有现成的开发板,又想调试学习linux内核,于是就有了这一系列的文章。本系列文章包含以下内容:
buildroot的正常操作是下载一个tar包,解压缩,配置,编译和安装tar包里面的软件组件。源码文件展开到output/build/<package>-<version>
路径下,这是一个临时的目录。当执行make clean
的命令后,这个目录将整个被删掉。当下次执行make
命令的时候,该目录又会被重新创建。即使将Git或Subversion存储库用作包源代码的输入,Buildroot也会从中创建一个tar包,然后像对待tar包一样正常工作。
以我们的uboot为例,当我们执行make
的时候,会从 https://gitee.com/wowothink/u-boot.git 仓库上下载uboot到dl/
目录中,然后将其打包到dl/uboot/uboot-v2017.01.tar.gz
的tar包,之后再解压该tar包到output/build/uboot-v2017.01/
目录,之后就编译该目录。
按照上述的行为,我们不能在dl/
目录下修改源码,因为该源码会从远程仓库下载,我们也不能修改output/build/
目录下的源码,因为当我们执行clean
的时候,这个目录就没了。很明显,buildroot这样做使用起来很不方便。buildroot的初衷是用作集成工具来构建和集成嵌入式Linux系统的所有组件,也就是希望尽量的稳定和减少修改。
buildroot针对此情形提供了一种特定的机制:<pkg>_OVERRIDE_SRCDIR
机制,Buildroot读取_override_
文件,该文件允许用户告诉buildroot某些软件包的源位置。当buildroot发现给定软件包已经定义了<pkg>_OVERRIDE_SRCDIR
时,它将不再尝试下载,提取和给软件包打patch。相反,它将直接使用指定目录中可用的源代码,并且make clean
不会触及该目录。这允许将buildroot指向你自己的目录,该目录可以由Git,Subversion或任何其他版本控制系统进行管理。为此,buildroot将使用_rsync_
将组件的源代码从指定的<pkg>_OVERRIDE_SRCDIR
复制到output/build/<package>-custom/
目录。接下来我们就使用该机制,来进行uboot、kernel源码位置的重新指定。
新冠疫情期间在家里无事可做,奈何手上没有现成的开发板,又想调试学习linux内核,于是就有了这一系列的文章。本系列文章包含以下内容:
为啥要用QEMU模拟Versatile Express开发板呢?主要是由于网上使用QEMU模拟Versatile Express开发板的资料比较多,于是乎就用这个开发板了。既然使用这块开发板,那么就要了解相关的信息:比如说SOC、板级硬件、原理图、memorymap等。本文就是详细介绍该开发板的一些资料,对于后续使用这块开发板大概有个认识,本文不是重点。
新冠疫情期间在家里无事可做,奈何手上没有现成的开发板,又想调试学习linux内核,于是就有了这一系列的文章。本系列文章包含以下内容:
在前面的文章中,我们分别下载编译uboot、下载编译kernel、下载busybox制作ramdisk、下载toolchain、制作SD卡等。这些步骤比较繁琐,有没有一种方法一键生成所需的镜像并且打包到一起呢?我们先看一下嵌入式系统编译的输入和输出,输入源码,输出二进制镜像。其中就需要Embedded Linux build system
来整合这些步骤,一键就需要依赖这里的build system(编译系统)来实现。目前的编译系统有Yocto/OpenEmbedded, PTXdist, Buildroot, OpenWRT。回想一下,SOC厂商发布BSP的时候,不可能一个个给你发布uboot、kernel的,而是将整个编译系统发布出来,据我所知NXP/MTK是通过Yocto发布,Pana通过Buildroot发布。
本文将使用buildroot作为编译系统,将我们之前使用qemu搭建的虚拟开发环境统一起来,实现一键编译打包。在这之前,我们先介绍一下buildroot。
新冠疫情期间在家里无事可做,奈何手上没有现成的开发板,又想调试学习linux内核,于是就有了这一系列的文章。本系列文章包含以下内容:
在前面的文章中,我们简单的编译一个kernel,然后使用qemu-system-arm -kernel
指定启动一个特定的linux kernel,在虚拟开发板上可以这么做。但是在实际的开发板中,启动是一个很复杂的东西。在启动kernel之前,通常有个小的引导程序(本文使用u-boot),引导程序需要事先存储在某些存储介质上,比如SD、eMMC、Flash、USB。当启动的时候,会有RomCode去初始化某些关键外设并且拷贝引导程序到DDR上。现在某些SOC支持ATF和TEE的功能,启动会变得更加的复杂。本文不讨论启动流程,本文只介绍在qemu环境下使用uboot通过sd卡去启动linux。
新冠疫情期间在家里无事可做,奈何手上没有现成的开发板,又想调试学习linux内核,于是就有了这一系列的文章。本系列文章包含以下内容:
注意:这只是一个入门的文章,介绍自己如何一步步搭建qemu环境以及启动虚拟开发板。如果想要用现成的环境,可以去查看吴章金大牛发起的Linux lab 项目,那个项目做得非常的棒。
作为嵌入式软件工程师,经常需要板子才能开发然后验证某些内容,这些东西在公司很容易实现。但是一回到家里,就没有这样的开发环境。因此,有没有这样一种仿真环境,支持某个虚拟的开发板,可以在上面跑uboot、linux kernel,从而进行uboot或kernel的调试而不必关心具体的外设器件。
在之前的2篇文章来介绍并验证usb gadget configfs,为啥呢?因为现在主流配置usb gadget都是采用configfs通过用户空间进行配置,而不是像之前使用hardcode方式专门有个内核模块来配置,来看一下Linux usb gadget的发展历程:
但是上述还存在一个问题,就是还在自定义的内核模块中,将各个功能各个用例绑定在一起不够便利。因此,在Linux 3.11版本引入usb gadget configfs,支持一系列API,用户层可以通过该API定义任意功能和配置,从用户空间定义特定于应用程序的usb复合设备。
在Androidadb驱动实现原理这篇文章中,我们使用传统的hardcode方式来创建一个android adb的usb复合设备。在usb gadget configfs 验证文章中,我们使用usb gadget configfs方式创建一个mass storage的usb复合设备。无论是使用哪种方式,都是为了创建一个usb复合设备。本文将详细介绍通过usb gadget configfs创建usb复合设备的原理。
按照上一篇文章对gadget_configfs.txt的翻译,以imx8qxp mek的板子做为验证,配置为mass storage进行验证。