Password Hardening Feature by davidpil2002 · Pull Request #1 · davidpil2002/sonic-buildimage

davidpil2002 · 2022-02-23T11:15:03Z

Why I did it

New security feature for enforcing strong passwords when login or changing passwords of existing users into the switch.

How I did it

Using mainly Linux pkg named cracklib that support the enforcement of user passwords, The daemon named hostcfgd, will support add/modify password policies that enforce and strengthen the user passwords.

How to verify it

Manually -

Enable the feature, using the new sonic-cli command or manually add the password hardening table like show in HLD.
Change password policies using the new sonic-cli commands (Added in sonic-utilities repo) or modify manually the Redis table according HLD.
Create a new user (using "adduser" command) or modify an existing password by using "passwd" command in the terminal. And it will now request a strong password instead of default linux policies.

Unitest:
The P.R contain unitest that cover:

test default init values of the feature in PAM files
test all the types of classes policies supported by the feature in PAM files
test aging policy configuration in PAM files

Which release branch to backport (provide reason below if selected)

The feature should be released in May, currently will be pushed to master

Description for the changelog

A picture of a cute animal (not mandatory but encouraged)

dgsudharsan · 2022-02-26T04:26:51Z

Can you please change the hostcfgd based on configdbconnector. Below is the optimization we did which will be raised to the community shortly

alexrallen#31

davidpil2002

done

davidpil2002

done

davidpil2002

done

…mit: 2919b48

…ning class

…e/sonic-buildimage/pull/10323/files about verification when reading files and add exception

…net#10291) #### Why I did it Fix issue: Non compliant leaf list in config_db schema: sonic-net#9801 #### How I did it The basic flow of DPB is like: 1. Transfer config db json value to YANG json value, name it “yangIn” 2. Validate “yangIn” by libyang 3. Generate a YANG json value to represent the target configuration, name it “yangTarget” 4. Do diff between “yangIn” and “yangTarget” 5. Apply the diff to CONFIG DB json and save it back to DB The fix: • For step #1, If value of a leaf-list field string type, transfer it to a list by splitting it with “,” the purpose here is to make step#2 happy. We also need to save <table_name>.<key>.<field_name> to a set named “leaf_list_with_string_value_set”. • For step#5, loop “leaf_list_with_string_value_set” and change those fields back to a string. #### How to verify it 1. Manual test 2. Changed sample config DB and unit test passed

…nic-net#10919)

Signed-off-by: Guohan Lu <lguohan@gmail.com>

…cts sonic-net#10972 Why I did it Fix the target directory not empty issue when publishing artifacts. Some of the artifacts are published to $(Build.ArtifactStagingDirectory)/target/ before source code checked out.

…wnload debian

- Why I did it To improve ASIC FW upgrade logging and have information about the cause of FW update failure in the log. - How I did it Added syslog logger support In case the FW update has failed the update tool will give the cause of the failure in the output in the last line, starting with "Fail". When running the tool, in case of a failed update, we will parse the output to retrieve the cause and log it. Device #1: ---------- Device Type: ConnectX6DX Part Number: MCX623106AN-CDA_Ax Description: ConnectX-6 Dx EN adapter card; 100GbE; Dual-port QSFP56; PCIe 4.0/3.0 x16; PSID: MT_0000000359 PCI Device Name: /dev/mst/mt4125_pciconf0 Base GUID: 0c42a103007d22d4 Base MAC: 0c42a17d22d4 Versions: Current Available FW 22.32.0498 22.32.0498 PXE 3.6.0500 3.6.0500 UEFI 14.25.0015 14.25.0015 Status: Forced update required --------- Found 1 device(s) requiring firmware update... Device #1: Updating FW ... FSMST_INITIALIZE - OK Writing Boot image component - OK Fail : The Digest in the signature is wrong - How to verify it mlnx-fw-upgrade.sh --upgrade

…bors over iBGP Session (sonic-net#16705) What I did: Enable Sending BGP Community over internal neighbors over iBGP Session Microsoft ADO: 25268695 Why I did: Without this change BGP community send by e-BGP Peers are not carry-forward to other e-BGP peers. str2-xxxx-lc1-2# show bgp ipv6 20c0:a801::/64 BGP routing table entry for 20c0:a801::/64, version 52141 Paths: (1 available, best #1, table default) Not advertised to any peer 65000 65500 2603:10e2:400::6 from 2603:10e2:400::6 (3.3.3.6) Origin IGP, localpref 100, valid, internal, best (First path received) Last update: Tue Sep 26 16:08:26 2023 str2-xxxx-lc1-2# show ip bgp 192.168.35.128/25 BGP routing table entry for 192.168.35.128/25, version 52688 Paths: (1 available, best #1, table default) Not advertised to any peer 65000 65502 3.3.3.6 from 3.3.3.6 (3.3.3.6) Origin IGP, localpref 100, valid, internal, best (First path received) Last update: Tue Sep 26 15:45:51 2023 After the change str2-xxxx-lc2-2(config)# router bgp 65100 str2-xxxx-lc2-2(config-router)# address-family ipv4 str2-xxxx-lc2-2(config-router-af)# neighbor INTERNAL_PEER_V4 send-community str2-xxxx-lc2-2(config-router-af)# exit str2-xxxx-lc2-2(config-router)# address-family ipv6 str2-xxxx-lc2-2(config-router-af)# neighbor INTERNAL_PEER_V6 send-community str2-xxxx-lc1-2# show bgp ipv6 20c0:a801::/64 BGP routing table entry for 20c0:a801::/64, version 52400 Paths: (1 available, best #1, table default) Not advertised to any peer 65000 65500 2603:10e2:400::6 from 2603:10e2:400::6 (3.3.3.6) Origin IGP, localpref 100, valid, internal, best (First path received) **Community: 1111:1111** Last update: Tue Sep 26 16:10:19 2023 str2-xxxx-lc1-2# show ip bgp 192.168.35.128/25 BGP routing table entry for 192.168.35.128/25, version 52947 Paths: (1 available, best #1, table default) Not advertised to any peer 65000 65502 3.3.3.6 from 3.3.3.6 (3.3.3.6) Origin IGP, localpref 100, valid, internal, best (First path received) **Community: 1111:1111** Last update: Tue Sep 26 16:10:09 2023 Signed-off-by: Abhishek Dosi <abdosi@microsoft.com>

…kernel 6.1 and bookworm (sonic-net#16954) * sonic-platform-modules-cel: broadcom: adapt for kernel 6.1 and bookworm The i2c_driver->remove API declaration has been updated to return void instead of int, as part of cleanup patches in 6.1. More details can be referred from here: [1]. Update the remove API definition in the modules accordingly and cleanup variables that go unused from the remove API. Update python build commands for bookworm. The packaging based on calling setup.py is deprecated and using build module/pip utility is the recommended method for python packaging/installation. Further details can be referred to from here: [2], [3]. The build module is picky about the package information file, which needs to be either setup.py or pyproject.toml. Additionally, fix formatting inconsistencies in debian/changelog reported by `dh_installchangelogs` during the build. Tested the changes by compiling the changes as below: make sonic-slave-bash NOBUSTER=1 NOBULLSEYE=1 sudo dpkg -i target/debs/bookworm/linux-headers-6.1.0-11-2-*.deb cd platform/broadcom/sonic-platform-modules-cel KVERSION=6.1.0-11-2-amd64 dpkg-buildpackage Also verified the python scripts under the sonic-platform-modules-cel with pyflakes to ensure no new errors are flagged (with exception of unused modules). References: [1] - torvalds/linux@ed5c2f5f [2] - https://blog.ganssle.io/articles/2021/10/setup-py-deprecated.htm [3] - 0b20a48 (Update Python build commands for Bookworm, 2023-09-07) Signed-off-by: Ramasamy Chandramouli <rachandr@celestica.com> * platform/pddf: i2c: adapt for kernel 6.1 and bookworm * Fixup i2c_driver->remove API due to changes in the function prototype (ref: [1]). * Cleanup `MODULE_SUPPORTED_DEVICE` macros that were cleaned up in the upstream (ref: [2]). * Sanitize python packaging and installation using the `build` module instead of calling the setup.py directly (ref: [3]. [4]). Tested the changes by compiling pddf module as below: make sonic-slave-bash NOBUSTER=1 NOBULLSEYE=1 sudo dpkg -i target/debs/bookworm/linux-headers-6.1.0-11-2-*.deb cd platform/pddf/i2c KVERSION=6.1.0-11-2-amd64 dpkg-buildpackage References: [1] - torvalds/linux@ed5c2f5f [2] - torvalds/linux@6417f031 [2] - https://blog.ganssle.io/articles/2021/10/setup-py-deprecated.htm [3] - 0b20a48 (Update Python build commands for Bookworm, 2023-09-07) Signed-off-by: Ramasamy Chandramouli <rachandr@celestica.com> * platform/broadcom: include platform-modules-cel in builds With pddf modules patched for 6.1, platform-modules-cel can be compiled and included in the final image. Testing by building sonic-broadcom.bin/sonic-broadcom-dnx.bin. Signed-off-by: Ramasamy Chandramouli <rachandr@celestica.com> * pddf/i2c: revert correct rootdir for pip install The pip install directory has been set to test-pkg1/ for testing the build and incorrectly retained as is. Revert this to the correct path $(PACKAGE_PRE_NAME). Signed-off-by: Ramasamy Chandramouli <rachandr@celestica.com> * platform/broadcom: include pddf/modules-cel in the base package Without this change, the modules were built but not packaged in the final .bin. The final sonic-broadcom.bin has been tested for bootup on Celestica's Silverstone platform. admin@sonic:~$ uname -a Linux sonic 6.1.0-11-2-amd64 #1 SMP PREEMPT_DYNAMIC Debian 6.1.38-4 (2023-08-08) x86_64 GNU/Linux admin@sonic:~$ show platform summary Platform: x86_64-cel_silverstone-r0 HwSKU: Silverstone ASIC: broadcom ASIC Count: 1 Serial Number: R4009B2F062504LK200024 Model Number: N/A Hardware Revision: N/A admin@sonic:~$ show version | head SONiC Software Version: SONiC.g0aad6c67c-rachandr SONiC OS Version: 12 Distribution: Debian 12.2 Kernel: 6.1.0-11-2-amd64 Build commit: 0aad6c67c Build date: Thu Oct 26 07:13:47 UTC 2023 Built by: rachandr@AZUHPS14 Platform: x86_64-cel_silverstone-r0 Signed-off-by: Ramasamy Chandramouli <rachandr@celestica.com> --------- Signed-off-by: Ramasamy Chandramouli <rachandr@celestica.com>

…bors over iBGP Session (sonic-net#16705) What I did: Enable Sending BGP Community over internal neighbors over iBGP Session Microsoft ADO: 25268695 Why I did: Without this change BGP community send by e-BGP Peers are not carry-forward to other e-BGP peers. str2-xxxx-lc1-2# show bgp ipv6 20c0:a801::/64 BGP routing table entry for 20c0:a801::/64, version 52141 Paths: (1 available, best #1, table default) Not advertised to any peer 65000 65500 2603:10e2:400::6 from 2603:10e2:400::6 (3.3.3.6) Origin IGP, localpref 100, valid, internal, best (First path received) Last update: Tue Sep 26 16:08:26 2023 str2-xxxx-lc1-2# show ip bgp 192.168.35.128/25 BGP routing table entry for 192.168.35.128/25, version 52688 Paths: (1 available, best #1, table default) Not advertised to any peer 65000 65502 3.3.3.6 from 3.3.3.6 (3.3.3.6) Origin IGP, localpref 100, valid, internal, best (First path received) Last update: Tue Sep 26 15:45:51 2023 After the change str2-xxxx-lc2-2(config)# router bgp 65100 str2-xxxx-lc2-2(config-router)# address-family ipv4 str2-xxxx-lc2-2(config-router-af)# neighbor INTERNAL_PEER_V4 send-community str2-xxxx-lc2-2(config-router-af)# exit str2-xxxx-lc2-2(config-router)# address-family ipv6 str2-xxxx-lc2-2(config-router-af)# neighbor INTERNAL_PEER_V6 send-community str2-xxxx-lc1-2# show bgp ipv6 20c0:a801::/64 BGP routing table entry for 20c0:a801::/64, version 52400 Paths: (1 available, best #1, table default) Not advertised to any peer 65000 65500 2603:10e2:400::6 from 2603:10e2:400::6 (3.3.3.6) Origin IGP, localpref 100, valid, internal, best (First path received) **Community: 1111:1111** Last update: Tue Sep 26 16:10:19 2023 str2-xxxx-lc1-2# show ip bgp 192.168.35.128/25 BGP routing table entry for 192.168.35.128/25, version 52947 Paths: (1 available, best #1, table default) Not advertised to any peer 65000 65502 3.3.3.6 from 3.3.3.6 (3.3.3.6) Origin IGP, localpref 100, valid, internal, best (First path received) **Community: 1111:1111** Last update: Tue Sep 26 16:10:09 2023 Signed-off-by: Abhishek Dosi <abdosi@microsoft.com>

#### Why I did it Dropping control character (message sent when XSUB connects to XPUB as part of ZMQ Proxy setup to notify that subscription has been made) in do capture has been flaky since control character is not guaranteed to be the first message sent if there are events (like event-down-ctr) being published to XSUB. Scenarios 1) Control character is sent and is first message when starting capture service `eventd#eventd#eventd: :- heartbeat_ctrl: Set heartbeat_ctrl pause=1` `eventd#eventd#eventd: :- do_capture: Received subscription message when XSUB connects to XPUB` 2) Events like event-down ctr is sent before control character `eventd#eventd#eventd: :- run: Dropping Message: 22 serialization::archive 18 17 sonic-events-host` `eventd#eventd#eventd: :- run: Dropping Message: 22 serialization::archive 18 0 0 4 0 0 0 1 d 103 {"sonic-events-host:event-stopped-ctr":{"ctr_name":"EVENTD","timestamp":"2024-08-27T00:02:51.407518Z"}} 1 r 36 3357542f-bae1-458f-a804-660e620d21f5 1 s 1 9 1 t 19 1724716971407591080` `heartbeat_ctrl: Set heartbeat_ctrl pause=1` `do_capture: Received subscription message when XSUB connects to XPUB` 3) Control character is not sent at all `eventd#eventd#eventd: :- heartbeat_ctrl: Set heartbeat_ctrl pause=1` 4) Control character is delayed and not caught when starting capture service, but is then caught after causing deserialize error. `do_capture: Receiving event from source: 22 serialization::archive 18 17 sonic-events-host, will read second part of event` `deserialize: deserialize Failed: input stream errorstr[0:64]:(#1) data type: std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >&` `zmq_read_part: Failed to deserialize part rc=-2` `zmq_read_part: last:errno=11` `zmq_message_read: Failure to read part1 rc=-2` `zmq_message_read: last:errno=11` We can cover these scenarios by just dropping the control character inside zmq_message_read as part of events_common in swsscommon (different PR). In this PR we will remove such handling logic and make sure that empty events that will be sent by control character are ignored. ##### Work item tracking - Microsoft ADO **(number only)**:28728116 #### How I did it Remove logic for handling control character #### How to verify it UT and sonic-mgmt test cases.

…et#21095) Adding the below fix from FRR FRRouting/frr#17297 This is to fix the following crash which is a statistical issue [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1". Core was generated by `/usr/lib/frr/zebra -A 127.0.0.1 -s 90000000 -M dplane_fpm_nl -M snmp'. Program terminated with signal SIGABRT, Aborted. #0 0x00007fccd7351e2c in ?? () from /lib/x86_64-linux-gnu/libc.so.6 [Current thread is 1 (Thread 0x7fccd6faf7c0 (LWP 36))] (gdb) bt #0 0x00007fccd7351e2c in ?? () from /lib/x86_64-linux-gnu/libc.so.6 #1 0x00007fccd7302fb2 in raise () from /lib/x86_64-linux-gnu/libc.so.6 #2 0x00007fccd72ed472 in abort () from /lib/x86_64-linux-gnu/libc.so.6 #3 0x00007fccd75bb3a9 in _zlog_assert_failed (xref=xref@entry=0x7fccd7652380 <_xref.16>, extra=extra@entry=0x0) at ../lib/zlog.c:678 #4 0x00007fccd759b2fe in route_node_delete (node=<optimized out>) at ../lib/table.c:352 #5 0x00007fccd759b445 in route_unlock_node (node=0x0) at ../lib/table.h:258 #6 route_next (node=<optimized out>) at ../lib/table.c:436 #7 route_next (node=node@entry=0x56029d89e560) at ../lib/table.c:410 #8 0x000056029b6b6b7a in if_lookup_by_name_per_ns (ns=ns@entry=0x56029d873d90, ifname=ifname@entry=0x7fccc0029340 "PortChannel1020") at ../zebra/interface.c:312 #9 0x000056029b6b8b36 in zebra_if_dplane_ifp_handling (ctx=0x7fccc0029310) at ../zebra/interface.c:1867 sonic-net#10 zebra_if_dplane_result (ctx=0x7fccc0029310) at ../zebra/interface.c:2221 sonic-net#11 0x000056029b7137a9 in rib_process_dplane_results (thread=<optimized out>) at ../zebra/zebra_rib.c:4810 sonic-net#12 0x00007fccd75a0e0d in thread_call (thread=thread@entry=0x7ffe8e553cc0) at ../lib/thread.c:1990 sonic-net#13 0x00007fccd7559368 in frr_run (master=0x56029d65a040) at ../lib/libfrr.c:1198 sonic-net#14 0x000056029b6ac317 in main (argc=9, argv=0x7ffe8e5540d8) at ../zebra/main.c:478

…dating udevd rules (sonic-net#26343) - Why I did it On SONiC SmartSwitch platforms with DPUs, systemd-udevd crashes with SIGABRT on every reboot when DPU firmware initialization is slow. During the initramfs boot phase, a standalone systemd-udevd daemon is started to handle device discovery. If DPU firmware takes longer than the 60-second udevadm settle timeout (BlueField-3 DPUs can take 120 seconds each in the failure case when they are stuck), the initramfs cannot stop this udevd before switch_root. The stale process survives into the real system but is never chrooted into the overlayfs root, leaving it with a broken filesystem view. When dpu-udev-manager.sh writes udev rules, the stale udevd detects the change and crashes on an assertion in systemd's chase() path resolution (assert(path_is_absolute(p)) at chase.c:648), because dir_fd_is_root() returns false for a process whose root still points to the initramfs rootfs rather than the overlayfs. This triggers a systemd issue : systemd/systemd#29559 which maintainers doesn't consider as a bug from systemd side. Raising this fix for our usecase. Core was generated by `/usr/lib/systemd/systemd-udevd --daemon --resolve-names=never'. Program terminated with signal SIGABRT, Aborted. #0 0x00007f29fe7f695c in ?? () from /lib/x86_64-linux-gnu/libc.so.6 (gdb) bt #0 0x00007f29fe7f695c in ?? () from /lib/x86_64-linux-gnu/libc.so.6 #1 0x00007f29fe7a1cc2 in raise () from /lib/x86_64-linux-gnu/libc.so.6 #2 0x00007f29fe78a4ac in abort () from /lib/x86_64-linux-gnu/libc.so.6 #3 0x00007f29fea50c11 in ?? () from /usr/lib/x86_64-linux-gnu/systemd/libsystemd-shared-257.so #4 0x00007f29feb94a8b in chase () from /usr/lib/x86_64-linux-gnu/systemd/libsystemd-shared-257.so #5 0x00007f29feb956e2 in chase_and_opendir () from /usr/lib/x86_64-linux-gnu/systemd/libsystemd-shared-257.so #6 0x00007f29feb9a609 in conf_files_list_strv () from /usr/lib/x86_64-linux-gnu/systemd/libsystemd-shared-257.so #7 0x00007f29fea913e8 in config_get_stats_by_path () from /usr/lib/x86_64-linux-gnu/systemd/libsystemd-shared-257.so #8 0x0000559f295519cf in ?? () #9 0x0000559f29553a77 in ?? () sonic-net#10 0x00007f29fec36055 in ?? () from /usr/lib/x86_64-linux-gnu/systemd/libsystemd-shared-257.so sonic-net#11 0x00007f29fec3668d in sd_event_dispatch () from /usr/lib/x86_64-linux-gnu/systemd/libsystemd-shared-257.so sonic-net#12 0x00007f29fec394a8 in sd_event_run () from /usr/lib/x86_64-linux-gnu/systemd/libsystemd-shared-257.so sonic-net#13 0x00007f29fec396c7 in sd_event_loop () from /usr/lib/x86_64-linux-gnu/systemd/libsystemd-shared-257.so sonic-net#14 0x0000559f29545820 in ?? () sonic-net#15 0x00007f29fe78bca8 in ?? () from /lib/x86_64-linux-gnu/libc.so.6 sonic-net#16 0x00007f29fe78bd65 in __libc_start_main () from /lib/x86_64-linux-gnu/libc.so.6 sonic-net#17 0x0000559f29545c51 in ?? () - How I did it Added a kill_stale_udevd() function to dpu-udev-manager.sh that runs before writing the udev rules. It identifies the systemd-managed udevd PID via systemctl show, then kills any other systemd-udevd --daemon process that doesn't match -- these are leftover initramfs instances. If no stale process exists (e.g. DPUs are healthy and the initramfs udevd exited cleanly), the function is a no-op. - How to verify it Deploy the image on a SmartSwitch with DPUs in a state where firmware initialization times out (>60s per DPU) by stopping image installation before firmware install step Reboot the switch Verify no new systemd-udevd coredumps in /var/core/ Verify the stale process was killed: journalctl -b 0 | grep dpu-udev-manager should show killing stale initramfs udevd PID (systemd udevd is PID ) Verify systemd-udevd.service is healthy: systemctl status systemd-udevd should show active (running) Verify DPU udev rules were written: cat /etc/udev/rules.d/92-midplane-intf.rules should contain the DPU interface naming rules Signed-off-by: Hemanth Kumar Tirupati <tirupatihemanthkumar@gmail.com>

…26549) - Why I Did It Bug: Powering DPUs off at runtime via dpuctl leaves stale MST PCI device entries on the host. Subsequent mst status / mlxfwmanager calls then hang for ~50 seconds while MST tries to talk to the now-absent DPU PCI devices. Root cause: MST was started globally at boot via the mlnx-fw-manager.service systemd unit (ExecStartPre=/usr/bin/mst start --with_i2cdev) and left running. So MST always saw the DPU PCI devices, even after they were powered off, and any tool that walked them stalled. This was already fixed on 202511 — see sonic-net#25575 and sonic-net#26131. This PR ports the same fix to master/202605. - How I Did It Move MST lifecycle out of the global systemd unit and into the firmware-update paths that actually need MST. The host then runs without MST loaded, so DPU power-off no longer leaves stale entries that hang mst/mlxfwmanager. mlnx-fw-manager.service — Drop ExecStartPre=/usr/bin/mst start --with_i2cdev and ExecStop=/usr/bin/mst stop, so the unit no longer leaves MST running globally. Add an ExecCondition that skips the unit during SONIC_BOOT_TYPE=fastfast. mellanox_fw_manager (ASIC firmware upgrade) — FirmwareCoordinator now owns the MST lifecycle: _start_mst() runs mst start --with_i2cdev before the upgrade. _stop_mst() runs mst stop in a finally block, so MST is always stopped on exit. New ignore_mst_start_failure flag (CLI: -m / --ignore-mst-start-failure in main.py) lets callers continue when MST can't start — used by the BlueField installer where DPUs may be off. BlueField installer (install.sh.j2) — Remove the explicit chroot ... mst start and call mlnx-fw-manager -m --nosyslog --verbose so install doesn't abort if MST start fails. DPU FPGA upgrade (sonic_platform/component.py) — ComponentFPGADPU._install_firmware() now runs cpldupdate inside a new _mst_context() context manager that does mst start before and mst stop after, even on failure. ComponentCPLD.__get_mst_device() is also rewritten to use asic_detect.sh -p instead of scanning the MST device path, so it no longer depends on MST being globally loaded. Unit tests — Updated for the new __get_mst_device contract, the new ignore_mst_start_failure plumbing, and _start_mst/_stop_mst patching in coordinator tests. - How to Verify It 1. MST no longer loaded globally; DPU power-off doesn't hang host tools ✅ # dpuctl dpu-power-off --all ... # time mst status MST modules: ------------ MST PCI module is not loaded MST PCI configuration module is not loaded PCI Devices: ------------ 06:00.0 real 0m0.091s user 0m0.041s sys 0m0.068s # time mlxfwmanager Querying Mellanox devices firmware ... Device #1: ---------- Device Type: Spectrum3 ... real 0m0.176s user 0m0.013s sys 0m0.134s 2. ASIC firmware upgrade at boot still works ✅ mlnx-fw-manager starts MST, performs the upgrade, and stops MST. Verified end-to-end at boot time. 3. DPU FPGA upgrade still works ✅ cpldupdate runs inside the new _mst_context; MST is started/stopped only for the duration of the update. 4. BlueField installer ✅ Installer-time firmware upgrade succeeds with mlnx-fw-manager -m, including when DPUs are powered off and MST can't start. 5. Unit tests ✅ pytest platform/mellanox/mlnx-platform-api/tests/test_component.py pytest platform/mellanox/platform-utils/tests/ Signed-off-by: Yizhen Zhang <evazha@nvidia.com>

davidpil2002 force-pushed the dev-password-hardening branch 3 times, most recently from 6724ff2 to f645338 Compare February 24, 2022 08:11

dgsudharsan suggested changes Feb 25, 2022

View reviewed changes

Comment thread files/build_templates/init_cfg.json.j2 Outdated

Comment thread files/build_templates/init_cfg.json.j2 Outdated

Comment thread files/build_templates/init_cfg.json.j2 Outdated

Comment thread rules/config Outdated

Comment thread src/sonic-host-services/scripts/hostcfgd Outdated

dgsudharsan suggested changes Feb 25, 2022

View reviewed changes

dgsudharsan suggested changes Feb 26, 2022

View reviewed changes

davidpil2002 force-pushed the dev-password-hardening branch 4 times, most recently from 78852c4 to 1842bc8 Compare March 1, 2022 15:11

Password Hardening Feature

2a59875

davidpil2002 force-pushed the dev-password-hardening branch from 1842bc8 to 2a59875 Compare March 1, 2022 16:59

dgsudharsan suggested changes Mar 2, 2022

View reviewed changes

davidpil2002 added 4 commits March 2, 2022 12:16

fix password hardening comments from the pull request

440307d

Merge branch 'master' into dev-password-hardening

fb5764e

small fix about passw hardening P.R

7a7fc90

move init_cfg.json.j2 changes to separate pull request with YANG model

9563886

davidpil2002 force-pushed the dev-password-hardening branch from d78afa5 to 9563886 Compare March 8, 2022 15:44

dgsudharsan suggested changes Mar 10, 2022

View reviewed changes

Comment thread src/sonic-host-services/tests/hostcfgd/test_passwh_vectors.py Outdated

modify age calculation & fix some values in the common-password.j2 file

49d1195

dgsudharsan suggested changes Mar 15, 2022

View reviewed changes

Comment thread src/sonic-host-services/scripts/hostcfgd Outdated

fix digits class name case

eff356a

davidpil2002 commented Mar 20, 2022

View reviewed changes

Comment thread src/sonic-host-services/scripts/hostcfgd Outdated

Comment thread src/sonic-host-services/tests/hostcfgd/test_passwh_vectors.py Outdated

davidpil2002 commented Mar 20, 2022

View reviewed changes

dgsudharsan approved these changes Mar 22, 2022

View reviewed changes

davidpil2002 added 3 commits March 24, 2022 12:58

fix unitest hostcfgd_passwh_test.py by adding enable_digits_class sample

5ab7c2b

Merge branch 'master' into dev-password-hardening

a5959f5

add mock table to passw hardening unitest in result of changes in com…

a4d452b

…mit: 2919b48

davidpil2002 and others added 8 commits March 28, 2022 13:47

fix credit disabled, by setting 0 instead to be clear

93072bd

removed unused import

3a8b5fd

Merge branch 'master' into dev-password-hardening

424bf9b

passw-hardening, fix unitest mocks tables

e9c9edf

Merge branch 'master' into dev-password-hardening

b611fa1

[passw-hardening] remove misstype line in hostcfgd

8e507e8

[password-hardening] move passw logic from AaaCfg class to PasswHarde…

e4bface

…ning class

[password-hardening]fix few comments from PR: https://github.com/Azur…

458691c

…e/sonic-buildimage/pull/10323/files about verification when reading files and add exception

davidpil2002 and others added 7 commits May 29, 2022 10:48

Merge branch 'Azure:master' into dev-password-hardening

3b5f7a1

Merge branch 'Azure:master' into dev-password-hardening

010e023

[ci] Publish logs when building image job is canceled by timeout. (so…

eb977ca

…nic-net#10919)

[CODEOWNERS]: update code owners for various repos (sonic-net#10980)

0f423af

Signed-off-by: Guohan Lu <lguohan@gmail.com>

[password-hardening]install cracklib from debian repo list instead do…

2967247

…wnload debian

Merge branch 'master' into dev-password-hardening

a2ec817

Conversation

davidpil2002 commented Feb 23, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Why I did it

How I did it

How to verify it

Which release branch to backport (provide reason below if selected)

Description for the changelog

A picture of a cute animal (not mandatory but encouraged)

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

dgsudharsan commented Feb 26, 2022

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

davidpil2002 left a comment

Choose a reason for hiding this comment

Uh oh!

davidpil2002 left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

davidpil2002 left a comment

Choose a reason for hiding this comment

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

5 participants

davidpil2002 commented Feb 23, 2022 •

edited

Loading