Skip to content

Commit 829cd83

Browse files
authored
HLD of SONiC FIPS POST support (#2034)
1 parent 7382cb1 commit 829cd83

File tree

5 files changed

+101
-0
lines changed

5 files changed

+101
-0
lines changed

doc/fips/SONiC-SAI-POST.md

Lines changed: 101 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,101 @@
1+
# SONiC SAI POST support for MACSec
2+
3+
## Revision
4+
| Rev | Date | Author | Change Description |
5+
|:---:|:-----------:|:------------------:|--------------------|
6+
| 1 | Jul-7 2025 | Song Yuan (Arista Networks) | Initial Version |
7+
8+
## Table of Contents
9+
* [Overview](#Overview)
10+
* [Design requirements](#Design-requirements)
11+
* [Deisgn details](#Design-details)
12+
* [State DB](#State-DB)
13+
* [Enabling POST in SAI switch init](#Enabling-POST-in-SAI-switch-init)
14+
* [Enabling POST in SAI MACSec init](#Enabling-POST-in-SAI-MACSec-init)
15+
* [Checking SAI POST status](#Checking-SAI-POST-status)
16+
* [Handling SAI POST failure](#Handling-SAI-POST-failure)
17+
* [Enforcing FIPS compliance](#Enforcing-FIPS-compliance)
18+
19+
## Overview
20+
21+
This document describes SONiC design for Federal Information Processing Standards (FIPS) 140-3 standard compliance. Especially, the focus of the document is to trigger MACSec Pre-Operational Self-Test (POST) in SONiC and also ensure SONiC’s behavior is compliant to FIPS standard after POST.
22+
23+
## Design requirements
24+
25+
The design must meet the following requirements:
26+
- In order to accommodate different forwarding ASIC architecture or SAI implementation, the design should support enabling POST at either switch level (during switch init) or at MACSec engine level (during MACSec engine init).
27+
- SONiC MACSec configuration must be processed only after POST passes.
28+
- POST failure must not affect the operation of non-MACSec ports.
29+
- Explicit visibility must be provided if POST fails, for example, in syslog. The syslog message must include the details of the failure. For example, SAI object Id of ports that fail POST and the corresponding MACSec engine.
30+
31+
## Deisgn details
32+
33+
The following figure depicts the data flow and SONiC components in the design. Orchagent is responsible for triggering POST via SAI calls and publishing POST status in State DB. MACSec container, precisely MACSecMgr, is enhanced to be POST aware and only process MACSec configuration after POST has passed.
34+
35+
![](images/fips-post-overview.png)
36+
37+
### State DB
38+
39+
The following table is added to State DB to track MACSec POST status, including SAI POST result/status.
40+
```
41+
FIPS_MACSEC_POST_TABLE
42+
43+
;Store MACSec POST status
44+
45+
key = FIPS_MACSEC_POST_TABLE|sai
46+
status = "switch-level-post-in-progress" ; SAI switch level POST is in-progress.
47+
"macsec-level-post-in-progress" ; SAI MACsec level POST will be triggered or in-progress.
48+
"pass" ; SAI POST passed.
49+
"fail" ; SAI POST failed.
50+
"disabled" ; SAI POST is disabled.
51+
52+
```
53+
54+
### Enabling SAI POST
55+
56+
SAI POST is enabled only when FIPS is enabled in SONiC. FIPS can be configured via either sonic-installer, i.e., set-fips option, or config file, i.e.,/etc/sonic/fips.json. Enabling FIPS requires switch reboot, and FIPS config will be populated in FIPS_STATS table in State DB after reboot. However, there may be a latency to populate FIPS config in State DB. Therefore, checking FIPS config in State DB is reliable because Orchagent may start before FIPS config is populated. Instead, Orchagent will directly check FIPS config in the following files:
57+
- /proc/cmdline : When FIPS is configured via sonic-installer, the result, e.g., sonic_fips=1, is written in this file.
58+
- /etc/fips/fips_enable : If FIPS is configured via config file /etc/sonic/fips.json, /etc/fips/fips_enable is updated accordingly.
59+
60+
Orchagent will trigger SAI POST if FIPS is enabled in either of the above files.
61+
62+
### Enabling POST in SAI switch init
63+
64+
Orchagent enables POST when creating SAI switch regardless of whether the MACSec feature is supported or enabled. This can avoid triggering POST after SAI switch creation, e.g., MACSec feature is enabled later. The below flow chart depicts the process.
65+
66+
![](images/fips-post-switch-init.png)
67+
68+
Orchagent enables POST when creating SAI switch. After SAI switch is created, Orchagent queries SAI POST capability. If POST is supported in switch init, Orchagent sets POST status to in-progress and waits for POST completion callback. Otherwise, if POST is supported only in MACSec init, Orchagent sets POST status to not-started, which informs MACSecOrch of performing POST in its initialization.
69+
70+
If POST is not supported in either switch or MACSec init, then SAI does not support POST. In this case, Orchagent sets POST status to fail if FIPS is enabled in SONiC.
71+
72+
### Enabling POST in SAI MACSec init
73+
74+
POST is performed by MACSecOrch when POST is supported only in MACSec init. The following flow chart demonstrates the process.
75+
76+
![](images/fips-post-macsec-init.png)
77+
78+
POST is triggered in MACSecOrch initialization. Since POST is enabled via SAI MACSec create API, SAI MACSec object may be created proactively and before any MACSec port is configured.
79+
80+
### Checking SAI POST status
81+
82+
Since SAI supports POST completion callback, a callback or notification function is provided when enabling POST in SAI switch or MACSec creation. Once being invoked, the callback function sets POST status in State DB accordingly based on the POST status returned by SAI.
83+
84+
### Handling SAI POST failure
85+
86+
If SAI POST fails, MACSecOrch reads POST status of all MACSec ports and finds out which port has failed in POST. MACSecOrch then adds the details of the failure in syslog. The following syslog is added to report SAI POST failure.
87+
88+
Swith level POST failure
89+
```
90+
Switch MACSec POST failed
91+
```
92+
MACSec level POST failure
93+
```
94+
MACSec POST failed: oid <macsec-oid>, direction ingress|egresss
95+
```
96+
97+
### Enforcing FIPS compliance
98+
99+
In order to be compliant to FIPS, SONiC should process MACSec configuration only after POST passes. This is achieved by enhancing MACSecMgr, running in MACSec container, to check POST status published in State DB before processing any MACSec configuration, as shown in the flow chart below:
100+
101+
![](images/fips-post-compliance.png)
18.9 KB
Loading
16.9 KB
Loading
23.3 KB
Loading
25.9 KB
Loading

0 commit comments

Comments
 (0)