hfi1_pkey_validation_pma(9)

πŸ“¦ version 7.3.1, in nixpkgs unstable

πŸ’… 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 πŸ“

  1. If pkey is neither FULL_MGMT_P_KEY nor LIM_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 πŸ’€
  2. If pkey_index -> FULL_MGMT_P_KEY, and LIM_MGMT_P_KEY is 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 ✨
  3. If pkey_index -> FULL_MGMT_P_KEY, and LIM_MGMT_P_KEY is NOT in the pkey table: drop the packet, because LIM_MGMT_P_KEY should always be in the pkey table. it could be an FM misconfiguration. not the misconfiguration era 😭
  4. If pkey_index -> LIM_MGMT_P_KEY and FULL_MGMT_P_KEY is 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 🫢
  5. If pkey_index -> LIM_MGMT_P_KEY and FULL_MGMT_P_KEY is 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