From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-qv1-f46.google.com (mail-qv1-f46.google.com [209.85.219.46]) (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 CA91D35CB6F for ; Mon, 11 May 2026 23:55:08 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.219.46 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778543710; cv=none; b=ZhBoWG9XRpy+pkUiRr8Zssuxv7JU9Ar8SZ6uGeCzuMFQA4qAczZ39PQih7LOTkmAdNVvg3zuPVadi5ADPKllg3pmFdU570OZEmrKSk4DdwPVLRteIdT5h2VxKnO6OZiQIv9D7jdtM3HtWdQUoSsvVmAOVzMsPgGs5KurTsmGy6E= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778543710; c=relaxed/simple; bh=c5c6VJYFxr4gXyMsdf0CD90gzBTH/ae8/+dU8nI90Rw=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=qOFBmi3L5bSfqiEJG7FNGJ+DrI+LwpsU6g81PAXxPX/O5GyDzHf3ptmBDeC0rnSLSXlebHsmBhnDohdZv+/XkJgEGd3n6hoyYP/aYLlYLJWa8KZgDAfVfJowWwjTQ2Cvdi8qu1HmwymC8B1KyL3NlqxoTEj5XtKu09VigPAzsiU= 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=QkUImqkp; arc=none smtp.client-ip=209.85.219.46 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="QkUImqkp" Received: by mail-qv1-f46.google.com with SMTP id 6a1803df08f44-8b6ea7716bfso54100156d6.0 for ; Mon, 11 May 2026 16:55:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1778543708; x=1779148508; darn=vger.kernel.org; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :from:to:cc:subject:date:message-id:reply-to; bh=YVKiv42ea4PUaZatWHgrj9fNebioiFzvGiQqzihY2NE=; b=QkUImqkpSBJd2ai15eRu22u66AYK7cOY/6QqFNJLiwuwet5Sqcv/wEFz6+KD+U9kyp Fra9WlqQYnkwmhOUQ4toh1OqxmstDmQERqyt2MBcLNSuEB0ENr+nWE/csrx8e+8ptW+K mmJfDMaiaRxe8IatqdCpHed2JLdr8c2WGLga27fzMcwZUqmphiOwSSzSsgbMP5rcMJ4O 5O9WGMsI2pOjlHhMJ/kQoUb28oYylwrtkdqCesVEbfdTFICdM0/9jHQmKbpbhmbEKvol 7ps9/N8oourt04XLQUIQ1F1WQCVyhjqC+FIf2mmsUEJa1tEPk6LHHpZ1/SUVUrIUn3XW /iTw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1778543708; x=1779148508; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-gg:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=YVKiv42ea4PUaZatWHgrj9fNebioiFzvGiQqzihY2NE=; b=dz3EhT9jYOPCT8q1l8rPqzEvk+1q9kV2ulgRofPri/HooazLNDmhdCkApbZCsMYjPX HUCQaemPY5Va7s4AYBJbTqxqnsU69Uu6aiFKUAfZEqvq9hsxYPkUAYvx2FnW3WBJt2LU zjaeYZj+dm7rEXqAZ/iNkRcL1CmrrdYHVH+uHYbNh9l/R9l25w1jjP90RbYp1WuahUtW qSpnz6uiJR0ZMQ15Ln9uUPh1yNpYPoXCQ1NSaNCPY8O68qXcAHnM8Mxg0YYaQc18Q2jB eUnBsz6iQtcC83qM06I9mvSHs/9iUZr9DuFTu2UwswjvZweJTEfXrMSN8n+MDNGwH2q8 se6Q== X-Forwarded-Encrypted: i=1; AFNElJ/i1WYCCoVfxM5Rpy4y8cBk5W1sA49N/u5gQe1PZ1bj0dxuI/z8clJg51q4i5vg4tO7kmMFG04BcemdX2U=@vger.kernel.org X-Gm-Message-State: AOJu0Yy2nFTwQqFvMCIZSFxvdiwF13USuuP4sIOqY65zjPkLsn2ZX4ir h+RvQaku1A2ERccW/nZaq6ZNKOM7geTaXsyZvqk5i9mE1Yb1g4f27tmT X-Gm-Gg: Acq92OHIZTD9bt6tBOi/nTXc5a9qO2+CsN+NNQkaQz6gRA41JhyfaH7dZ6/Hq1oz5fP JwyvADIJ7G8WW0UzqedbjWje2Yk3z8sNNC7YaaBGqYxcv8k04pr74sSAWuuF/oN6rpNPyz6ZYv2 Ltjz9Xs/rlgQ5Y81yPP/onQwv1RkwJes0KRsBGfLxhzfb6ZotIPFUH3RQzWs91JMWAgOatmMcHD sAnn0/pZOjPBzhafVRT1cBwzuH60H909/gWg9LPQoD1pbrqIx3A7bjnXH3XiF96XgDC8X2el0w1 KnK4nC9SRqWqRTuDQ12/a8TqUCIXV55rvG2KR0w+hCh82+74pJMAYrQnlvGplFBWEzGzBLW26Kk /IjMoDHz2MaoFkIOg0nDoTdyW0NkopD9/6Zeb82u347rGLXjJ3vu6fWryLIBjYvrAwRHUgkYmWJ 5p9VZRZ0z/5Sww/6L56uQEHemO0g0BIjd9iABJJqM0EYVFvhp2tdhmp2Jy5F8ojv1gBWQCSg== X-Received: by 2002:a05:6214:810a:b0:8ac:732b:6cf1 with SMTP id 6a1803df08f44-8c1a824b04fmr165374996d6.24.1778543707652; Mon, 11 May 2026 16:55:07 -0700 (PDT) Received: from ?IPV6:2620:10d:c0a8:11d1::1011? ([2620:10d:c091:400::5:9448]) by smtp.gmail.com with ESMTPSA id 6a1803df08f44-8bf39c7e032sm108169106d6.32.2026.05.11.16.55.06 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 11 May 2026 16:55:07 -0700 (PDT) Message-ID: <08750de2-77d4-44c1-b16a-33603c3100dc@gmail.com> Date: Mon, 11 May 2026 19:55:05 -0400 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH net-next 4/6] netdevsim: psp: implement kdf from psp spec To: Willem de Bruijn , Jakub Kicinski , Andrew Lunn , "David S. Miller" , Eric Dumazet , Paolo Abeni Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org References: <20260508-nsim-psp-crypto-v1-0-4b50ed09b794@gmail.com> <20260508-nsim-psp-crypto-v1-4-4b50ed09b794@gmail.com> Content-Language: en-US From: Daniel Zahka In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 5/11/26 3:49 PM, Willem de Bruijn wrote: > Daniel Zahka wrote: >> Implement the PSP key derivation function (KDF) per the PSP >> Architecture Spec. >> >> The kdf is used to generate spi + session key pairs, and will also be > Text is a bit ambiguous here: the kdf does not generate the spi. It > derives a session key from the master key and spi. > >> used in the rx path to re-derive the tx key used by the peer. >> >> Also, remove support for psd->generation, as it is not needed for >> netdevsim after removing the fake authentication hack. > Is psd->generation only used inside driver code, not by the core PSP > stack? Else it should be set to !!(ns->psp.spi & PSP_SPI_KEY_PHASE) on > key rotation. If only used by the driver, no need to reset it on each > rotation. Core tries to 'suggest' a generation to the driver, which is the last generation + 1, before calling into key_rotate(), but this won't work for netdevsim. I could set the generation to !!(ns->psp.spi & PSP_SPI_KEY_PHASE) so that it aliases the device key selection bit, but I think this is basically the same as just setting it to 0. This series makes the generation field dead code in core. The old netdevsim implementation relied on it to do its fake authentication hack, but that is removed with this series. The only real hw implementation we have, mlx5, does not support device key generations. Maybe we need to just remove that until a real driver comes along as a user. >> Assisted-by: Claude:claude-opus-4.6 >> Signed-off-by: Daniel Zahka >> enum skb_drop_reason >> nsim_psp_handle_tx(struct sk_buff *skb, struct netdevsim *ns) >> { >> @@ -155,7 +189,7 @@ nsim_rx_spi_alloc(struct psp_dev *psd, u32 version, >> struct netlink_ext_ack *extack) >> { >> struct netdevsim *ns = psd->drv_priv; >> - int i; >> + unsigned int phase; >> >> if ((ns->psp.spi ^ (ns->psp.spi + 1)) & PSP_SPI_KEY_PHASE) { >> NL_SET_ERR_MSG(extack, "SPI space exhausted"); >> @@ -163,9 +197,11 @@ nsim_rx_spi_alloc(struct psp_dev *psd, u32 version, >> } >> >> assoc->spi = cpu_to_be32(++ns->psp.spi); >> - assoc->key[0] = psd->generation; >> - for (i = 1; i < PSP_MAX_KEY; i++) >> - assoc->key[i] = ns->psp.spi + i; >> + phase = !!(ns->psp.spi & PSP_SPI_KEY_PHASE); >> + >> + /* dev_keys_lock not needed because of psd->lock */ > Can you elaborate a bit? > > Is dev_keys_lock only used to synchronize the writers, then? Which after > device init would only be concurrent invocations of nsim_key_rotate. But > that operation correctly also holds the device lock using > psp_device_get_locked. This is an error in splitting changes in the series on my part. The spinlock is used to synchronize the writer with the reader running the kdf in the napi_poll() path in the later aes-gcm commit. I should have added the spinlock stuff when that reader was introduced. The comment is just pointing out that all of the psp_dev_ops on a psd are serialized with the psd->lock. I'll fix that in the respin.