hfi1_pkey_validation_pma(9)
π
hfi1_pkey_validation_pma β the pkey bouncer, but make it fashion π
okay so bestie, this one lives in the Kernel API Manual and it's lowkey one of the most "security guard at the club door" functions in the whole hfi1 driver. It's called hfi1_pkey_validation_pma and it literally validates PKEYs for incoming PMA MAD packets. No cap. π«Ά
β¨ SYNOPSIS β¨
int hfi1_pkey_validation_pma (struct hfi1_ibport *ibp , const struct
opa_mad *in_mad , const struct ib_wc *in_wc );
π¦ ARGUMENTS π¦
ibpβ the IB port data. your main character struct, fr fr.in_madβ the MAD packet, header and data included. it's giving "the whole fit".in_wcβ work completion data, like source LID, port number, etc. the little details that matter π
πΈ DESCRIPTION πΈ
so here's the tea: these are all the possible logic rules for validating a pkey. get comfy, we're going through every single one π
- If pkey is neither
FULL_MGMT_P_KEYnorLIM_MGMT_P_KEY, and it's NOT a self-originated packet: drop the MAD packet. it should always be part of the management partition unless it's a self-originated packet. like, read the room bestie π - If
pkey_index->FULL_MGMT_P_KEY, andLIM_MGMT_P_KEYis in the pkey table: the packet is coming from a management node and the receiving node is also a management node, so it's safe for the packet to go through. mutuals only, slay β¨ - If
pkey_index->FULL_MGMT_P_KEY, andLIM_MGMT_P_KEYis NOT in the pkey table: drop the packet, becauseLIM_MGMT_P_KEYshould always be in the pkey table. it could be an FM misconfiguration. not the misconfiguration era π - If
pkey_index->LIM_MGMT_P_KEYandFULL_MGMT_P_KEYis NOT in the pkey table: it's safe for the packet to go through, since a non-management node is talking to another non-management node. two regulars chatting, we love to see it π«Ά - If
pkey_index->LIM_MGMT_P_KEYandFULL_MGMT_P_KEYis in the pkey table: drop the packet, because a non-management node is talking to a management node, and it could be an attack. π¨ ngl this is the villain arc one, we do not let it in.
okay so for the implementation, these rules can be simplified to only checking for (a) and (e). there's no need to check for rule (b) as the packet doesn't need to be dropped. rule (c) is not possible in the driver as LIM_MGMT_P_KEY is always in the pkey table. so yeah β the bouncer only actually checks two things, iconic efficiency honestly π
π RETURN π
0β pkey is okay, we're so back π-EINVALβ it's a bad pkey, not invited to the function π
π SEE ALSO π
kernel file ./drivers/infiniband/hw/hfi1/mad.c, plus the whole friend group: get_pkeys(9), set_pkeys(9), tx_link_width(9), get_xmit_wait_counters(9), hfi1_process_mad(9). go follow them, iykyk π¦
and that's the whole page bestie π this one's from ./drivers/infiniband/hw/hfi1, dated October 2026, and yes it's still out here in the Kernel API Manual section 9 doing its little pkey vibe check. periodt. π
π¦ where this page comes from
- nixpkgs unstable: linux-manual 7.3.1
- π girlified by deepseek-ai/DeepSeek-V4.1-Flash-1017 on : a language model's rewrite of the original, under its terms