On Mon, Mar 16, 2026 at 08:50:39PM +0000, Long Li wrote: > > 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%.
You cannot separate functionality and claim that one line of code is trusted while another is not. Thanks
