> On Thu, Mar 12, 2026 at 11:16:41AM -0700, Erni Sri Satya Vennela wrote: > > As part of MANA hardening for CVM, clamp hardware-reported adapter > > capability values from the MANA_IB_GET_ADAPTER_CAP response before > > they are used by the IB subsystem. > > > > The response fields (max_qp_count, max_cq_count, max_mr_count, > > max_pd_count, max_inbound_read_limit, max_outbound_read_limit, > > max_qp_wr, max_send_sge_count, max_recv_sge_count) are u32 but are > > assigned to signed int members in struct ib_device_attr. If hardware > > returns a value exceeding INT_MAX, the implicit u32-to-int conversion > > produces a negative value, which can cause incorrect behavior in the > > IB core and userspace applications. > > This sentence does not make sense in the context of the Linux kernel. > The fundamental assumption is that the underlying hardware behaves correctly, > and driver code should not attempt to guard against purely hypothetical > failures. The kernel only implements such self‑protection when there is a > documented hardware issue accompanied by official errata. > > Thanks
The idea is that a malicious hardware can't corrupt and steal other data from the kernel. The assumption is that in a public cloud environment, you can't trust the hardware 100%.
