Linux相关的功能安全考量
user application，shell or programs tools，and kenel，then computer source inside file system across all.
1.通讯，可以在硬件资源上布置以太网等高传输介质，而在kernel需要实现类似autosar os功能，优先级，更有效率的排布而非抢占式，以及子系的管理。
策略上需要实现好的除了优先级，也有执行算法的完整性，特别在大型复杂系统上，执行路径及选择是更重要的问题，vw用微软衍生系而tesla用linux衍生系，这都是未来的方向，唯一的一点是qnx或因价格问题，需要进行调整在未来继续保持市占率。
扯远了，通讯涉及的computer source，kernel，及user application，在这边看待的是成千上万个command，以及适配到对应的硬件资源，难度在于按不同通讯安全等级做不同安全状态，过多的话，整体复杂度太高，性能优化是个难题。如果单纯研发level3，还需要加入command window以及与人交互的其他变量，雪上加霜。
2.io负担，这个问题在于tesla与vw整车大os中，定制化os，说更细一点，未来的io资源是整车性能最重要最稀缺的资源，甚至比file aystem更重要，原因在于数据的出入口基本在此。
io难度在于优先级，阻塞程度，是否受限管控，同内存的访问权限量，作为interface同外部security问题，这不是单纯26262能解决的。
感兴趣的，可以看一下4600中的初步描述，基本有一个框架，数据安全，信息安全，限制条件等，在此不展开。
3.文件管理。每一份被涉及的函数功能后面都隐藏着一份文件，文件管理也涉及虚拟技术。
在此的文件读取可以直接从user application直到source，这样的后果是我们在cockpit，可以直接读取，速度优良，难度是我们实际从command window用物理方式触碰或输入指令等，实质经过了多道防线，从最开始的hypervisor，虚拟锁，以及统一的权限检验，这里面涉及的安全问题，涉及功能安全的，在于内部反应机理是否够state of art，不是绝对安全而是相对安全。这里面有更深层次的问题，例如，大家都知道的security functionality和safety function都需要在这里更详细定义边界，参与的指令，需要更多的信息，而这样的mechanism甚多，我们可以后续一起探讨。
4.内存虚拟化。利用hypervisor进行的更多技术，hypervisor类似于独立的内存管理+访问控制+硬件资源优化+虚拟化接口管控。此处的safety需要考虑的hypervisor更多是
（1）虚拟化后与实体memory的共存问题，不同ASIL级别在虚拟化中怎么实现partition，而这与硬件又有关系。双重设定
（2）虚拟化后memory的大小及访问控制问题，此类问题，介于safety与security之间，采用的integrity算法不会太复杂，DES即可，而此处的访问控制列表及ACL需要牢牢存储，故问题在于后续如何进行沟通和发展。
- 用户评论
