Joseph Reynolds wrote: > 1. Security impacts of enabling kexec (load and optionally execute new > kernel) in the BMC's production kernel.  How does this work and play > with secure boot and with IMA? > 2. What are the security impacts of having the proc file system file > /proc/sysrq-triggerwhich can cause kernel panics which can cause the > BMC to terminate processing? > 3. In general, how can you (an operator or the BMC's host system) > recover a BMC which has become unresponsive, for example, because its > kernel processing has failed.  A design introduces using > /proc/sysrq-triggertogether with a recovery kernel installed by kexec. This tussle between locking down the system against all intrusions, vs being able to fix stuff when in trouble is a serious debate. (Based upon how easily random alien technology takes over the Enterprise, we know which way Starfleet engineers went.) So I suggest that in most cases, the secure boot process should disable kexec (and sysrq-trigger!), but that this should be an tunable attribute under control of the secure boot process. For the majority of data center, business and home users of systems, the risk of malware in the bootpath of the BMC exceeds the risk of BMC failures, and the cost remediation (taking a machine out of commission when there is a BMC problem). Having said that, there is a Right-to-Repair concern, and I really hope that manufacturers will provide for a hardware jumper, and for installation of new trust anchors. But, there is a variety of ways to do that from kernel cmdlines, to being able to boot alternate kernels, and perhaps this could be punted down the road for the operator that needs (#3). Perhaps, coming back to my (humour) above, it will in fact be Mars Rover missions or Starlink satellites that need it, and probably, they can afford to do that work. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works | IoT architect [ ] mcr@sandelman.ca http://www.sandelman.ca/ | ruby on rails [