安全技术体系
信息安全、功能安全、预期功能安全均属于汽车操作安全的一个部分，同时这三项安全技术也一起并成为智能网联汽车操作安全性的“安全三剑客”。
- 信息安全
指的是规避重要信息泄露、被篡改、盗窃或遗失。信息安全同样属于智能网联汽车技术的一部分，对应的标准为ISO/SAE 21434和SAE J3061。
- 功能安全
功能安全指的是不存在由电子电气系统的功能异常表现引起的危害而导致不合理的风险。功能安全是在汽车电子电气技术基础上发展而来的一项安全技术，对应的标准为ISO 26262。
- 预期功能安全
预期功能安全指的是规避由于功能不足、或可合理预见的人员误用所导致的人身危害。预期功能安全技术属于智能网联汽车技术的一部分，对应的标准为ISO 21448。
功能安全与信息安全的关系：
信息安全（Information Security）和功能安全（Functional Safety）是两个不同的概念，它们在目的、应用范围和关注点上有所区别。
信息安全：
信息安全是指保护数据和信息系统不受未经授权的访问、使用、披露、破坏、修改或破坏的一系列战略和措施。它关注的是数据的保密性（Confidentiality）、完整性（Integrity）和可用性（Availability），通常缩写为CIA三原则。信息安全的主要目的是保护数据免受各种网络的安全威胁，例如黑客、间谍软件、内部失误等。
功能安全：
功能安全是指系统或设备在一定的环境下按照既定设计正常运作，即使发生故障也能够达成预期的安全性能。功能安全更关注产品或系统的安全性能和可靠性，确保在软硬件故障或操作失误等情况下，系统能够进入或维持在一个安全状态或最小化潜在危险。关注的是产品和系统在生命周期中的所有方面，包括设计、制造、操作和维护。功能安全频繁应用于汽车、工业控制、医疗和其他需要管理安全临界操作的领域。
区别总结：
- 目标不同：信息安全注重保护数据不受到非法破坏和访问；功能安全注重保证产品或系统即使在出现故障时仍能维持安全状态。
- 应用领域不同：信息安全主要应用于保护电子数据和网络通讯；功能安全主要应用于产品和实体系统的安全性能保护，比如汽车、飞机、医疗设备等。
- 方法和措施不同：信息安全通常涉及到加密、权限管理、网络防火墙等技术手段；功能安全通常考虑故障的检测、诊断、纠正和容错措施。
两者并非互相独立，随着技术的融合发展，例如在汽车行业中的智能网联汽车，信息安全和功能安全越来越需要结合考虑，以确保整体的系统安全。
功能安全与预期功能安全的关系：
随着智能网联汽车技术的发展，人们发现并不是所有的车辆安全问题都源于系统错误和失效，而是很多时候来源于环境影响或系统本身的功能/性能不足。因系统功能不满足预期而导致的安全风险就是预期功能安全要解决的问题。
功能安全用于解决电子电气失效对人造成的危害，而预期功能安全用于解决系统非故障原因对人造成的危害。ISO 26262标准中对电子电气系统的标称功能及性能没有要求，预期功能安全的存在弥补了这部分遗憾。
Linux 安全机制
安全机制
安全机制的定义是：为了维持预期功能或达到/保持某种安全状态，由电子电气系统的功能/要素或其他技术来实施的技术解决方案，以探测故障/减轻故障或控制/规避失效。
在相关项中实施安全机制的目的是避免故障导致单点失效或减少残余失效，并防止故障潜伏。安全机制可以是能够使相关项过渡到或保持在安全状态；或能够向驾驶员发出提醒以控制失效的影响。
SELinux
定义：
SELinux(Security-Enhanced Linux-安全增强型Linux)，是一个在Linux内核中实践的强制存取控制安全性机制，也是Linux的一个安全子系统。
基本概念：
SELinux 主要由以下四个部分组成：
- Subject - 系统中运行的程序，每个Subject都有安全属性通过Security Context表示
- Object - 系统中各种资源，如文件、网络等，每个Object都有安全属性通过Security Context表示
- Policy & Rule - 进程主体需要如何管制以及如何管制都有Policy定义
- Security Context - SeLinux核心。运行在Linux系统内核中。根据Selinux策略，检查Subjects的安全属性与Objects的安全属性是否匹配，从而决定Subjects是否能够访问objects
工作模式：
SELinux有三种工作模式
- enforcing - 强制模式 -违反规则的行为被阻止将被记录到日志中
- permissive - 宽容模式- 违反规则的行为只会记录到日志中去
- disabled - 关闭SELinux
工作流程：
一个主体要访问一个对象，Linux内核会首先检查主体权限，来决定是否能访问文件。如果文件的属性不允许执行访问则拒绝，不再检查SELinux上下文。如果该文件属性运行执行访问，那么SELinux会先读取进程和文件的上下文，查询相应规则，并按照规则执行，将访问错误的信息记录到日志中去。
Linux 功能安全设计
Linux作为域控、自动驾驶控制器标准化OS，具有广阔的应用前景。提供平台化Linux 安全机制解决方案，可以在满足实时性的基础上为系统安全带来保证，解决快速部署量产项目和过标难题，并支持系统满足ASIL B等级安全要求。本文档主要描述基于汽车电子功能安全开发和设计要求，构建了Linux的功能安全架构方案，通过系统安全策略、流程体系、编译/开发工具形成一个较为完整的安全体系。
Linux 功能安全开发过程：
在Linux功能安全开发过程中，会涉及的主要部分为：（1）Part 2：功能安全管理；（2）Part 3：概念阶段（依据Linux功能安全需求获取方式进行适当裁剪）；（3）Part 4：产品开发：系统层面（依据Linux功能安全需求获取方式进行适当裁剪）；（4）Part 6：产品开发：软件层面；（5）Part 8：支持过程；（6）Part 9：以汽车安全完整性等级为导向和以安全为导向的分析。
在涉及的各个部分中，均对软件组件的功能安全开发提出了明确要求，并且规定了相应输出物和成果，可以用来指导Linux功能安全的开发。具体内容请参考ISO26262:2018对应章节。从Linux功能安全开发的⻆度看，涉及的主要开发阶段如下图所示：
Linux 功能安全开发过程示意图
Linux 功能安全开发需求：
层级产品开发的参考阶段模型
Linux软件架构边界示意图如下所示，其中包含了未考虑功能安全要求情况下的Linux核心模块。
Linux 软件架构边界示意图
Linux架构包含：Hardware层、OS(rootfs、Kernel)层、Service层、Appliction层、Buildtools\Development tools。
- Hardware层：包含芯片控制器、外部硬件模块（Camera、Ser/r/Des、Pmic、eMMC、UFS）等；
- Kernel 层：包含系统内核模块、外设驱动、诊断框架等；
- Rootfsfs文件系统：负责存储系统lib、运行应用进程、配置文件、产生临时数据、Usr层和Kernel层交互；Service层：包含系统运行的服务如：（Timesync、systeminfo、PowerManager、ProcessManager、OTATA、LOG）；
- APP层：包含自动驾驶感知、识别的应用；- Build tools：包含代码环境的编译工具(gcc/g++、Make);
- Development tools:开发环境包含 代码编辑工具(vim/vscode)、调试器JTATAG、芯片刷写工具、长裤管理git、BUG管理Jira、构建工具Jenkins。
更新后Linux软件架构示意图如下所示：
Linux软件架构示意图
Linux功能安全架构边界示意图所示， Scope功能块主要描述基于正常Linux 框架的基础上增加可实施Safety功能及开发体系，通过稳定内核版本、安全框架、安全措施、流程体系来支撑后续Linux 版本可平台化功能安全建设。
功能安全
概念:不存在因E/E系统故障行为造成的危害而导致的不合理风险；“不合理不可接受的过度”风险的定义损害概率和程度的组合。Linux安全机制调研
汽车功能安全属于汽车操作安全体系下的人身安全，它关注的危害单指因E/E系统的故障行为引起的，对驾驶员或者路人或周边车辆内人员（注意不仅是驾驶员）的人身危害。也就是说，功能安全开发的目的是避免伤人，而不是避免伤车。
功能安全的意义
为什么需要功能安全：
- 人不是完美的 => 系统性失效
汽车开发工程师在汽车E/E系统开发中，包括软件和控制器硬件，不可避免地存在人为疏忽或错误，引起系统功能功能失效，进而导致故障并产生危害。这部分人为疏忽导致的失效为系统性失效。
- 物不是完美的 => 随机硬件失效
控制器硬件，由于自身老化，外部环境因素等引发功能失效，导致相应故障并产生危害。硬件失效带有随机性，符合一定概率分布，因此称为硬件随机失效。
功能安全如何解决问题：
- 除通常质量管理(QM)外，对汽车E/E系统软硬件全生命周期安全开发流程，方法等进行约束和规范(主要是通过ASIL)，尽可能降低人为结构性的系统失效
- 对控制器硬件部分进行概率化度量，尽可能降低随机硬件失效
- 除过程约束外，设定安全状态，一旦系统发生故障，在故障容错时间内将系统导入安全状态，避免对人身、财产造成伤害
特点：
- 系统，软件，硬件开发遵循各自V模型，都是从需求，到架构，再到设计实现，最后验证及系统确认(确认只有在系统层面)。
- 旨在尽可能避免由系统功能异常导致的危害，不是为了提高系统原有功能或非安全性能(如动力性)或避免系统本身功能不足导致的危害(属预期功能安全)
- 不关注本质安全(即通过消除危险的原因确保安全的方式)
功能安全ASIL分解
ASIL分解是功能安全设计的必要阶段。
功能安全需求继承了安全目标的ASIL等级。如果一个安全需求可以分解为两个安全需求，那么原来安全需求的ASIL等级可以分解到这两个安全需求上。
这个分解的结果是需求ASIL等级下降，但是本质是功能安全需求的分解，最终都是实现相同ASIL等级的安全目标。下图给出了ASIL分解的原则，分解后的ASIL等级后面括号里是指明原始安全需求的ASIL等级，因为集成和需求的验证仍然依据原始的ASIL等级。ASIL等级的分解可以在功能安全活动的多个阶段进行，比如概念设计、系统设计、硬件设计和软件设计阶段。而且ASIL分解可以分多次进行，比如ASILD=ASILC(D)+ASILA(D)，其中ASILC(D)还可以继续分解为ASILB(D)+ASILA(D)。
Linux作为域控、自动驾驶控制器标准化OS，具有广阔的应用前景。提供平台化Linux安全机制解决方案，可以在满足实时性的基础上为系统安全带来保证，解决快速部署量产项目和过标难题，并支持满足ASIL B等级安全要求。
ISO26262
ISO 26262概念：
《道路车辆功能安全》国际标准是针对总重不超过3.5吨八座乘用车，以安全相关电子电气系统的特点所制定的功能安全标准，基于IEC 61508《安全相关电气/电子/可编程电子系统功能安全》制定，在2011年11月15日正式发布。
ISO 26262是史上第一个适用于大批量量产产品的功能安全（Functional Safety）标准。特别需要注意的是，ISO 26262仅针对安全相关电子电气系统，包含电机、电子与软件零件，不应用于非电子电气系统（如机械、液压等）。
功能安全之设计议题在汽车领域已被重视，因其关系人员安全与公司商誉等问题，透过危害分析与风险评估（Hazard Analysis & Risk Assessment，HARA）及V模型设计架构，使功能安全需求等级得到一致性的分析结果，以利汽车电子系统之生命周期考虑到所需失效防止技术与管理要求，并借由设计开发、查证（Verification）及确认（Validation）等能力成熟度模型集成（CMMI-DEV）流程加以实现，使得产品之功能安全符合所需汽车安全完整性等级（ASIL）。
ISO 26262简介：
ISO26262是从电子、电气及可编程器件功能安全基本标准IEC61508派生出来的，主要定位在汽车行业中特定的电气器件、电子设备、可编程电子器件等专门用于汽车领域的部件，旨在提高汽车电子、电气产品功能安全的国际标准。
ISO 26262应用：
- 提供了汽车生命周期（管理，研发，生产，运行，服务，拆解）和生命周期中必要的改装活动。
- 提供了决定风险等级的具体风险评估方法（汽车安全综合等级，ASILs）
- 使用ASILs方法来确定获得可接受的残余风险的必要安全要求。
- 提供了确保获得足够的和可接受的安全等级的有效性和确。
