[Linux-PowerEdge] FYI: BIOS Update fails due to CONFIG_IO_STRICT_DEVMEM=y in linux kernel 4.16+

Stephen Dowdy sdowdy at ucar.edu
Thu Jul 12 17:00:01 CDT 2018


SUMMARY:
   - CONFIG_IO_STRICT_DEVMEM is culprit (not CONFIG_STRICT_DEVMEM)
   - iomem=relaxed allows Dell DUP Kits to correctly report and update some firmware that previously failed.
   - some Dell DUP Kits work fine in locked-down environment, others fail.  some fail with error reports, others silently claim to work and fail fully.
   - Dell should hopefully fix the DUP kit components to error check and work-around restrictions.


On 07/12/2018 02:40 PM, Stephen Dowdy wrote:
> Update:  adding 'iomem=relaxed' to the kernel bootparams allows 'biosie' (from the BIOS*.BIN DUPkit) to update the BIOS.

Subject line changed to reflect the accurate kernel knob (CONFIG_IO_STRICT_DEVMEM)

Ref: https://outflux.net/blog/archives/2016/09/28/security-things-in-linux-v4-5/
Ref: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=90a545e981267e917b9d698ce07affd69787db87


Okay, this (iomem=relaxed) also fixed the issue i've been having with the BCM NetExtreme (5720) firmware update DUP kits failing to report the "installed/running" version and actually REALLY updating the firmware:

     ~# ral-superinv
     [System Board]
                 Hostname : XXXXXXXX
             Manufacturer : Dell Inc.
                    Model : PowerEdge T640
                   Memory : 196608 MB
            Serial Number : XXXXXXXX
             BIOS Version : 1.3.7 (!=1.4.8)
        BMC/iDRAC Version : 3.21 {iDRAC9}
     
     [Network]
       Broadcom Adv. Dual 10GBASE-T Ethernet (BCM957416)@18:00.0    : 20.08.04.04
       Broadcom Adv. Dual 10GBASE-T Ethernet (BCM957416)@18:00.1    : 20.08.04.04
-->   Broadcom NetXtreme Gigabit Ethernet (BCM95720)@b1:00.0       : 20.6.52
-->   Broadcom NetXtreme Gigabit Ethernet (BCM95720)@b1:00.1       : 20.6.52
     [RAID/PERC] :
                     PERC H740P Adapter = 50.3.0-1022


We try to run the Broadcom NetXtreme updater (Network_Firmware_R4HKW_LN_20.8.4.BIN) to get from 20.6 to 20.8, but Dell's DUP Kit can't inventory the "Installed version".  It runs and CLAIMS it updated and wants to reboot, but on reboot, the firmware's still 20.6 :

     .../local/DellUpdates/NETW# ../dup_run_debian 14GEN_Broadcom_NetXtreme -q
     /bin/sh appears to be dash, setting it to use BASH, because Dell's sh scripts are non-POSIX and break systems
     Collecting inventory...
     ....
     Running validation...
     
     NetXtreme BCM5720 Gigabit Ethernet PCIe (enp177s0f0)
     
     The version of this Update Package is newer than the currently installed version.
     Software application name: NetXtreme BCM5720 Gigabit Ethernet PCIe (enp177s0f0)
     Package version: 20.8.4
--> Installed version:
...
     Executing update...
     WARNING: DO NOT STOP THIS PROCESS OR INSTALL OTHER PRODUCTS WHILE UPDATE IS IN PROGRESS.
     THESE ACTIONS MAY CAUSE YOUR SYSTEM TO BECOME UNSTABLE!
     ....
     The system should be restarted for the update to take effect.
     ERROR: Network_Firmware_R4HKW_LN_20.8.4.BIN execution MAY have failed, or you answered NO to reboot, sorry (return_code=2)
(my wrapper script reports return error codes, so this was not a reported error from the DUP kit, but i believe DELL uses 'returncode=2' to indicate user chose to NOT reboot after update, but i'm not going to blindly trust that given that many DUPs behave differently)

Clearly, there's some failure to do error checks and report in this particular DUP kit.

BUT, The equivalent 20.8 Broadcom NetXtreme-E Updater (Network_Firmware_3VXHM_LN64_20.08.04.04.BIN) works *flawlessly* under the same conditions. (that's why my BCM957416's are updated to 20.08).

So, *something* can be done on Dell's side to make these DUP kits actually work under these conditions.

I verified that booting with 'iomem=relaxed' allows the 'Network_Firmware_R4HKW_LN_20.8.4.BIN' to actually correctly query the installed version, *AND* update the firmware properly.  (but there's a security side-effect of running this way)

thanks,
--stephen
-- 
Stephen Dowdy  -  Systems Administrator  -  NCAR/RAL
303.497.2869   -  sdowdy at ucar.edu        -  http://www.ral.ucar.edu/~sdowdy/



More information about the Linux-PowerEdge mailing list