From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-yx1-f54.google.com (mail-yx1-f54.google.com [74.125.224.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E5D983BB40 for ; Mon, 11 May 2026 20:03:32 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=74.125.224.54 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778529814; cv=none; b=npa8FgOCQNMMM8/yK09pIdoIwSMHswFKUnPWF9Fg+F9vUPL2rCV+1a2ytGx9DK84p2RauSkZgyV9W7WNzeIGkkjxiDTz9f/tIpo8EDAP4CPj1QsjVaW/Bm8GiapmNmdPbR5FUzL7Tczq2BCl5xrWjGwRzo/LjmxSAEnV2VMCGNQ= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778529814; c=relaxed/simple; bh=/rh78K7dEQaIt4xTNNU+9/Uq8c+lZYbvjEGX+x5v/zs=; h=Date:From:To:Cc:Message-ID:In-Reply-To:References:Subject: Mime-Version:Content-Type; b=J9j1rgGqlryb0eLEhX/+VEx/lKxOE5gSruy1GAYmvSeWLXoh6k2P/bX9OlnmNV0ArpsV4K01ivHmoZbm5RrgewZtqAaGP2k3ZhPs4n7yBN70qGJGinGna5o9yamFjrMwYZ/aELwd+oTG7Num2FSEBMEeb2/K5UWOom8AIiaXWjU= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com; spf=pass smtp.mailfrom=gmail.com; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b=PgEMHgcc; arc=none smtp.client-ip=74.125.224.54 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=gmail.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="PgEMHgcc" Received: by mail-yx1-f54.google.com with SMTP id 956f58d0204a3-651d6347a69so4772712d50.0 for ; Mon, 11 May 2026 13:03:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1778529812; x=1779134612; darn=vger.kernel.org; h=content-transfer-encoding:mime-version:subject:references :in-reply-to:message-id:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=df5H5F48lqO775bsK2qtaTIF/Zsa3yd78EW7E45MHkg=; b=PgEMHgccMChTSJ8iTQEvXXMJKjF1wAVgCfKJJBHzzlutdwydePP7hRcoV4pqO1N8I7 N+HfNz1jKpOmlr/A/A8ySvca4sZvq00R4tA3Cbo9/zSCKPSDl3GpyZ+Y0Yk90Jc3pLmZ EIvOP/UyDUy5xLT1AgN0OXNGO1FHK289phyBqZ9s93zjITrZauVauyt+u+W8sjeKZql4 mu+fdRb4IX5lX9eWAocUu/8N2s81fTwlJC/JhQiU1eMtdbz05iMwtkVojG2a4tbt2cs4 rrbqAc4zRvRQ1385B9ZRkbJB6Nq54Qj//yRFTHddhzywuXxUcxAWSwX9Lkfuom7b1s6B az1g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1778529812; x=1779134612; h=content-transfer-encoding:mime-version:subject:references :in-reply-to:message-id:cc:to:from:date:x-gm-gg:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=df5H5F48lqO775bsK2qtaTIF/Zsa3yd78EW7E45MHkg=; b=DZGKlBPmMTAjhg0epau6BF7dCPa4XuezehetM3Rt2MnszlSdNVbQ+Zf58Y0Mn9mcMd OUoD8MKEUP6Q8bu0VlQJSbtdEEP5IoPQKvf6Yu1kC/Btq3etJ2HncFCHF3DPy4uqU9UR oZTaP8Zq5bJKRa5lr2hS2SGU3PY+/MW4zVIbkjOxnl4M9qI3ah6U/Ferx6wU8+xFd7kc oNYS8T8ZIaKUs2C70Mahtk0FeYS+36Hc5MGeNV1F7zvh0TME7vIPTQQEwSc+yZDBJv0e cvG4OcP/EKQGJX2YYZvg3NSTFK0r0dA7kL2yrGyv2zLGOOuU/+SHV8y5AIO+Jiy70nn8 8xMg== X-Forwarded-Encrypted: i=1; AFNElJ+PT2bEHwvubT6/j6aUn6lcMSEaKOTb3A/KN8ROo+oBSugcIzY/Tp3WsRxAfk0NqR/ukUcq4UzlY/Tlj04=@vger.kernel.org X-Gm-Message-State: AOJu0YxNNirIcNbqIq4pceiEIt4bLlpuSmOWzsb9w+YS7t5FVEaEO2Hv a+pv6XaA3hrHhg86BBWzqYLAco0TFnJ4xnet1V9mlXbjBtUJJrVdSFZm X-Gm-Gg: Acq92OHBz10DeAgpqbdx7yupyencj/SKV4Jeb7OuD/cFuvscc/GXd4egLcCiCc97G4N 0NCDAYHcdeV/g0UAw9FSfWkpG3gOP23cVJgvEvseFwiaUQ2dW/BLZk+JtDAKSlHG7rP5eQ1/c3k v1xqqmQ7h+MtNFfWZ1UwU9sn3PdQJtpZ3jSooTG7ujemAMDqy4lEUCjLN2YhPk3kkVmnim9CEIc WEegMqxzCZ5lGSu6mbB+4ZGut3cYxLsEI079dGtQlOgVJAGic/R+8ByLWfIfG8eXCffncLDyze2 zMoCPM67ZZWGNUWYvgGlHP7OjkAMB0eEZeKfltyF1VnAVQprKHlUi5XIUD+S/gpTLSBnPT+PfdP bM8p9XbTZtqgZtEdxDib078poJnjZcU9kyZ3bwUCzPfe8vXxy27jtkF9JktYGgjvPszc2jvidyF nbzRrR+6ZGm7sf1kepZtqPY7Z/nDpBJi8BQfyzBEP8G0WFiQMP7CBOUdV4QBKPIZBPbLAeQ2S7D 1T4 X-Received: by 2002:a05:690c:13:b0:7b3:b0a6:2c60 with SMTP id 00721157ae682-7c50db32344mr9885957b3.1.1778529811811; Mon, 11 May 2026 13:03:31 -0700 (PDT) Received: from gmail.com (172.235.85.34.bc.googleusercontent.com. [34.85.235.172]) by smtp.gmail.com with ESMTPSA id 00721157ae682-7bd66888cc7sm152269757b3.44.2026.05.11.13.03.31 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 11 May 2026 13:03:31 -0700 (PDT) Date: Mon, 11 May 2026 16:03:30 -0400 From: Willem de Bruijn To: Daniel Zahka , Jakub Kicinski , Andrew Lunn , "David S. Miller" , Eric Dumazet , Paolo Abeni , Willem de Bruijn Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org Message-ID: In-Reply-To: <20260508-nsim-psp-crypto-v1-3-4b50ed09b794@gmail.com> References: <20260508-nsim-psp-crypto-v1-0-4b50ed09b794@gmail.com> <20260508-nsim-psp-crypto-v1-3-4b50ed09b794@gmail.com> Subject: Re: [PATCH net-next 3/6] netdevsim: psp: move rx processing into nsim_poll() Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Daniel Zahka wrote: > nsim_do_psp() does PSP decap and skb extension creation in the tx > path. This has the slightly undesirable property of not allowing the > psp rx code to run on PSP packets cooked up in userspace and > transmitted on a packet socket from the peer dev (e.g. packetdrill). Whether this happens in the nsim_start_xmit tx side handler directly or is deferred to nsim_napi_rx is irrelevant, isn't it? > This commit instead triggers the psp rx path just based on parsing the > received skb. The current code relies on a bit of a hack to simulate > authentication with the proper key: the peer's psd->generation was > placed into the tx key, and during decap used to fill out the > extension the packet before being sent up the psp rx path. This commit > removes that hack, which creates a transient break in psp.py test > cases that rely on this behavior (e.g. data_send_bad_key). Subsequent > commits which introduce real aes-gcm crypto will restore the correct > behavior. > > Assisted-by: Claude:claude-opus-4.6 > Signed-off-by: Daniel Zahka > +/* Returns true if skb was consumed, false otherwise. */ > +bool nsim_psp_handle_rx(struct netdevsim *ns, struct sk_buff *skb) > +{ > + struct psp_dev *psd; > + struct psphdr *psph; > + struct udphdr *uh; > + int payload_len; > + u32 versions; > + int psp_off; > + bool is_udp; > + int l3_hlen; > + u8 version; > + u32 psd_id; > + int err; > + > + if (skb->protocol == htons(ETH_P_IP)) { > + struct iphdr *iph; > + > + if (!pskb_may_pull(skb, sizeof(struct iphdr))) > + return false; > + > + iph = (struct iphdr *)skb->data; > + if (iph->ihl < 5) > + return false; > + > + is_udp = iph->protocol == IPPROTO_UDP; > + l3_hlen = iph->ihl * 4; > + } else if (skb->protocol == htons(ETH_P_IPV6)) { > + struct ipv6hdr *ip6h; > + > + if (!pskb_may_pull(skb, sizeof(struct ipv6hdr))) > + return false; > + ip6h = (struct ipv6hdr *)skb->data; > + is_udp = ip6h->nexthdr == IPPROTO_UDP; > + l3_hlen = sizeof(struct ipv6hdr); > + } else { > + return false; > + } > + > + if (!is_udp) > + return false; > + > + if (!pskb_may_pull(skb, l3_hlen + sizeof(struct udphdr) + PSP_HDR_SIZE)) > + return false; > + > + uh = (struct udphdr *)(skb->data + l3_hlen); > + if (uh->dest != htons(PSP_DEFAULT_UDP_PORT)) > + return false; > + > + psph = (struct psphdr *)(uh + 1); > + version = FIELD_GET(PSPHDR_VERFL_VERSION, psph->verfl); This seems to reimplement a lot of psp_dev_rcv. Is that needed? Is it a hint that this psp driver API needs some work? > + rcu_read_lock(); > + psd = rcu_dereference(ns->psp.dev); > + if (psd) { > + versions = READ_ONCE(psd->config.versions); > + psd_id = psd->id; > + } > + rcu_read_unlock(); > + > + if (!psd || !(versions & (1 << version))) { > + skb->ip_summed = CHECKSUM_NONE; > + return false; > + } > + > + psp_off = l3_hlen + sizeof(struct udphdr); > + payload_len = skb->len - psp_off - PSP_HDR_SIZE - PSP_TRL_SIZE; > + if (payload_len < 0) > + goto drop; > + > + skb_push(skb, ETH_HLEN); > + skb->mac_len = ETH_HLEN; > + err = psp_dev_rcv(skb, psd_id, 0, false); > + if (err) > + goto drop; > + > + skb_reset_mac_header(skb); > + skb_pull(skb, ETH_HLEN); Similarly this is a bit of a hack, pushing and pulling a fake Ethernet offset. And is this skb_reset_mac_header needed? > + skb->decrypted = 1; > + > + u64_stats_update_begin(&ns->psp.syncp); > + u64_stats_inc(&ns->psp.rx_packets); > + u64_stats_add(&ns->psp.rx_bytes, payload_len); > + u64_stats_update_end(&ns->psp.syncp); > + > + return false; > + > +drop: > + kfree_skb_reason(skb, SKB_DROP_REASON_PSP_INPUT); > + return true; > +} > + > static int > nsim_psp_set_config(struct psp_dev *psd, struct psp_dev_config *conf, > struct netlink_ext_ack *extack) > > -- > 2.52.0 >