Hi Gab,

Fine for me to skip today’s meeting.

By the way, I sent to you a message with some remarks / questions (probably also got posted in the work group forum) about the presentation you and Daniel made during the last workshop.

It would be good if you would check and see if you would have any comments. Thanks.

Best regards,

ZHANG Haipeng

发件人: safety-architecture@... [mailto:safety-architecture@...] 代表 Gabriele Paoloni
发送时间: 2022年4月26日 17:04
收件人: safety-architecture@...
主题: [ELISA Safety Architecture WG] cancelling today's meeting

邮件免责申明

Email Disclaimer

本邮件仅供本邮件指定收件人使用，其所载内容可能因含有保密信息或其它原因而不得披露。除本公司及本邮件指定收件人外，任何人不得公开、传播、分发、复制、印刷或使用本邮件之任何部分或其所载之任何内容。如您误收到本邮件，请立即通知本公司，并将原始邮件、附件及其所有复本从系统中删除，切勿使用。

This email is for the use of the designated receivers only，and the content is not allowed to be disclosed due to the confidential information or other reasons. Except for the Company and the designated receivers of this email, no one shall disclose, disseminate, distribute, copy, print or use any part of this email or any content contained therein. If you receive this email by mistake, please notify the Company immediately, and delete the original email, attachments and all copies from the system. Do not use it.

网络通信可能含有计算机病毒或其它缺陷，可能无法准确和/或及时送达其它系统，亦可能受阻而不为本公司或本邮件指定收件人所知。本公司对此类错误或遗漏以及任何因使用本邮件而引致之任何损失概不承担责任。

Network communication may contain computer viruses or other defects, which may not be delivered to other systems accurately and / or in time, or may be blocked by the Company or the designated receivers of this email. The Company shall not be liable for such errors or omissions and for any loss arising from this email.

本邮件所载任何内容仅作为业务层面交流与参考，除非明确说明，本公司不对邮件所载内容之准确性、完整性或公平性等承担任何法律责任。

Any contents contained in this email are only for the purpose of business communication and reference only. Unless explicitly stated otherwise, the Company shall not assume any legal responsibility for the accuracy, completeness or fairness of the content contained in the email.

本邮件指定收件人应特别注意：本邮件所载任何内容不构成本公司对本邮件指定收件人和/或其所属商业实体的任何要约、要约邀请或承诺，任何权利义务皆以双方签字盖章的书面文件为准。除经本公司以签字盖章的书面文件确认外，收件人和/或其所属商业实体不得以本邮件所载任何内容作为其向本公司主张任何权利或利益的正式依据。

The designated receivers should pay special attention to the fact that nothing contained in this email shall constitute an offer, invitation or acceptance by the Company to the designated receivers of this email and/or its affiliated business entities, and any rights and obligations are subject to the written documents signed and sealed by both parties. Except from the written document signed ,sealed and confirmed by the Company, the receivers and / or its affiliated business entity shall not rely on anything contained in this email as the formal basis for claiming any rights or interests to the Company.

Dear Gab, Daniel,

The presentation in the ELISA workshop was interesting and informative. Thanks again for that.

Some more questions are attached below for my clarity and to see if it helps for the further evolution towards a more general-purpose design.

The Requirements Decomposition:

1. Here, I have the impression that the top level safety requirements look a bit broader than the requirements specially for the kernel (e.g.: for the 1^st requirement, to my understanding, the programming of the watchdog timeout is initiated by the safety application). By introducing the approach of having the monitor in the kernel to relax some kernel modules from having to be safety compliant, I think we expected that the safety requirement decomposition would happen within the scope of kernel. If that is the case, I think the requirement decomposition should probably be performed based on some safety requirements at the kernel level (effectively concerning the VFS / Watchdog Driver / etc. as a whole), and it may possibly be worded like “The kernel (modules) shall ensure the watchdog control to follow the requests from the safety application” or something like that, which is to eliminate the specifics which are actually executed by the application.

2. For the decomposed requirements on the right side, I would wish the correctness of the watchdog timeout setting to be part of the monitoring, because that is part of the intended function of the related kernel modules and can otherwise cause a safety problem if violated. And that may drive my next question (which might be touched a little bit during the workshop presentation) which is how can the proposed RVM based monitoring be scaled / extended to support the monitoring of numerical characteristics of the kernel in addition to the finite enumerative states. The watchdog timeout setting (as one straight forward numerical characteristic) is naturally less dynamic, but how feasible (most difficult aspect might be to model such complicated kernel behavior in the formal notations with respect to lots of factors which have influences over that numerical kernel behavior, and especially the concern of integrity of those influencing factors as the inputs of the in-kernel monitor) is it to scale / extend the RVM to cover the rest of the kernel (as far as used in the typical safety critical applications) in terms of numerical characteristics if the kernel would possibly exhibit and have safety implications?

High Level Failure Mode Analysis / Failure Mode 1 – Failure in the VFS

About the fault detection measure, the safety application retrieves an internal state of the in-kernel monitor which appears that the safety application acts partially as the monitor of the in-kernel monitor (typically in case of kernel error), which is probably supportive in this case because maybe no other means are available to ensure the runtime correctness of the RVM, although the RVM itself can be engineered to a high integrity during its construction phase due to the use of formal notations and tools (which can be qualified offline). However, that brings the architecting question which is how feasible could the safety application (not necessarily the one for the Tell-Tale use case, but could be other possible applications) be developed with some level of the knowledge about the in-kernel monitor and the achievable diagnostic coverage of the monitoring at the application level against the in-kernel monitor the complexity of which can be linear to the kernel functions to be monitored.

Thank you.

张海鹏 Zhang Haipeng

)  +86 13817693438

*  zhanghaipeng02@...

基础软件平台 | Basic Software Platform

上海汽车集团股份有限公司零束软件分公司

SAIC Motor Z-ONE Software Company

上海市嘉定区汽车·创新港 | 安研路201号

Auto Innovation Park | 201 Anyan Road, Jiading, Shanghai

邮件免责申明

Email Disclaimer

本邮件仅供本邮件指定收件人使用，其所载内容可能因含有保密信息或其它原因而不得披露。除本公司及本邮件指定收件人外，任何人不得公开、传播、分发、复制、印刷或使用本邮件之任何部分或其所载之任何内容。如您误收到本邮件，请立即通知本公司，并将原始邮件、附件及其所有复本从系统中删除，切勿使用。

This email is for the use of the designated receivers only，and the content is not allowed to be disclosed due to the confidential information or other reasons. Except for the Company and the designated receivers of this email, no one shall disclose, disseminate, distribute, copy, print or use any part of this email or any content contained therein. If you receive this email by mistake, please notify the Company immediately, and delete the original email, attachments and all copies from the system. Do not use it.

网络通信可能含有计算机病毒或其它缺陷，可能无法准确和/或及时送达其它系统，亦可能受阻而不为本公司或本邮件指定收件人所知。本公司对此类错误或遗漏以及任何因使用本邮件而引致之任何损失概不承担责任。

Network communication may contain computer viruses or other defects, which may not be delivered to other systems accurately and / or in time, or may be blocked by the Company or the designated receivers of this email. The Company shall not be liable for such errors or omissions and for any loss arising from this email.

本邮件所载任何内容仅作为业务层面交流与参考，除非明确说明，本公司不对邮件所载内容之准确性、完整性或公平性等承担任何法律责任。

Any contents contained in this email are only for the purpose of business communication and reference only. Unless explicitly stated otherwise, the Company shall not assume any legal responsibility for the accuracy, completeness or fairness of the content contained in the email.

本邮件指定收件人应特别注意：本邮件所载任何内容不构成本公司对本邮件指定收件人和/或其所属商业实体的任何要约、要约邀请或承诺，任何权利义务皆以双方签字盖章的书面文件为准。除经本公司以签字盖章的书面文件确认外，收件人和/或其所属商业实体不得以本邮件所载任何内容作为其向本公司主张任何权利或利益的正式依据。

The designated receivers should pay special attention to the fact that nothing contained in this email shall constitute an offer, invitation or acceptance by the Company to the designated receivers of this email and/or its affiliated business entities, and any rights and obligations are subject to the written documents signed and sealed by both parties. Except from the written document signed ,sealed and confirmed by the Company, the receivers and / or its affiliated business entity shall not rely on anything contained in this email as the formal basis for claiming any rights or interests to the Company.

Christoffer will be joining us once again, to continue the technical discussion on his document. 

Just to remind you, here is the link to his doc in github   https://github.com/challfre/wg-lfscs/blob/main/address_space_integrity/address_space_integrity.md

Some suggestions, but will be opened to other ideas as well:

1. Clarify all assumptions, the explicit ones which we discussed already (MMU support by HW architecture, reduced privilege / non-root execution by user space application), as well as any others.   And their implications.
2. Virtual memory management, boot time vs run time:  what can be expected at each stage, what are the implications for safety.
3. Kernel configurations, pros and cons of those which he listed + any others

Thanks, Christoffer, and looking forward to a productive discussion tomorrow.

Regards

Elana