From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-yw1-f182.google.com (mail-yw1-f182.google.com [209.85.128.182]) (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 1837E298991 for ; Mon, 11 May 2026 19:49:03 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.128.182 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778528946; cv=none; b=d8N3weK2oe3h598zOFbOI5kWCldhNKUu22kfwzYKxBlMHPILvhONXJiUsHa8wp5zTcqn/bD6vx3onunf8TvMXPivmAgRinie+z6Yy7nH4IRG5kn0BDq8r30JUgA0JIOV74URIohBRZzSft5Vaw1Y4pqRGap9fifQqI1MqugFvNE= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1778528946; c=relaxed/simple; bh=QHHzaIEonCbI1C5dXpKIlAYjdgalgcGFxXhTpOB8rKw=; h=Date:From:To:Cc:Message-ID:In-Reply-To:References:Subject: Mime-Version:Content-Type; b=hnmQnTlkH1zd5uG5jmAw+8Ga5qsxOQasBGAye42Z3Qs40uuYLqvUHsCPE6bbEH7UY9ryxP7lTQAl/gXT9UA1zXPYNcwOT9bE07CWLheZugJgQqyUC+b6Yw3QFCnIILecx3EBvBgu6lhs3hua4PUttZ63J9S4r+HxtNKJN73Q2lM= 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=LKLAs8SQ; arc=none smtp.client-ip=209.85.128.182 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="LKLAs8SQ" Received: by mail-yw1-f182.google.com with SMTP id 00721157ae682-7b37d84a6b3so46413867b3.2 for ; Mon, 11 May 2026 12:49:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20251104; t=1778528943; x=1779133743; 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=eUstqJlu3gWnJgtR+FhxyIiNP8zbdgleP0vcu3c2vng=; b=LKLAs8SQKiyUR4XUJjyiu7d6Wvjfle+/Ownp/MVmYtT3Kvd7uNAjz0/CkKUSOPSRsl uvqEK/HUs5SY8nJGHpaIBX6sZnnFrIzAErmmJqpJRvRmne6fyE95MCKDDadyn5DFbZMj Zw/vgnXld4zH+tv/F0z/Vmm7oZlIZze0IJ1qpybZfdYb6DPJEewHd90Q+NGeIBIPUotm NPJJgF3q3ybjm6d4EsqcUdHHr+gJ3yhARM3R6B40FmS+3DGy9NRB6V5g02wcgKULp8rl OlNbhV10n2QkOj1N9kqYhvZzQQfjZzNikW3vkoZhItUI1ALMp7VRx2tpX2YGi7MrMO/v TIOg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1778528943; x=1779133743; 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=eUstqJlu3gWnJgtR+FhxyIiNP8zbdgleP0vcu3c2vng=; b=epv4SMnL5RqLE6Wx0yiiGGb5TSNAGTAK5LE/UAp/3tb3dm/JlXuzQDM/PZx3rmFZO7 D425KB6OgVsYjOFF58cjf4DS6SldbyxBU6XGCRMHUKCpo9+7Cfta/1XvfImMOP76/h2W 1y8fMDDFijNaxjzk5OQl2P/1dRVwBM3CCnG4j/jV9U9ei9GBb4A40lJMOXmWCV3rA1QB 5RSTLwuXgsOQfZEIeyWjUMO02pKBi9/1vDKOjHndzEONcn/8grnA5khhhLCbOCg84upw iJ1CvSw0AvsIMFSIfsbPROTe+BVgDQkV5t0MYCU5ddBBkqS46zey25jeuUyibqI4tEOt 2Sww== X-Forwarded-Encrypted: i=1; AFNElJ/F/8RvQ0Z+nuAC2kjJTvaGJURc5tjvZoknKmljiKLPkpPul8M6GqzHrIU+giUzGte3EWYQLzZpLKcsNkE=@vger.kernel.org X-Gm-Message-State: AOJu0YyZyWUTcL44F6/MMCVK9YGz3QhEsdJK3N2UTTfbDlqr89sUA8vE tI+k71i52G3cw2hbUkXJnS7ouTvKrP6RNNuy+bgiOlaQmhYf43vhGTIY X-Gm-Gg: Acq92OHOgi8FbZyZhXDHvmR1HklRY6balRU06rM5DbXoC0WbXFTHNsqbUmJ0tIpZ2Er UD8oHphgi6om+4JbOjgEeoZRHOHKXoSM8ndvQ100UBoyu0wSsXBp9ElcOVE/H0JCXSnbhf/GDxK sCssvh1e4SauPPB9SI8Pz5e4zEcyNsKkgO5v3o8kiTTFNAgSJi8QKrb8C57vXoXxUvWPqLcuNow EJXM0M1Ogk1e6ykUS4G5v7WEUbWv7MP19bCk6kSNURWodTlSzCnTeiPXSEFocLIxZytp/c5wR9r 4c7o0JfFysEQLF2QutLL92mVwgdV3wAjCNva+YmuHjFOOdqMRIn6/Nz7BoSynLrsZvh6Brt4Yii iiH27o5yvdOGacWksTz5FoWt5qNxlYaN5fJP1rpVC2M49zFwcJf6IjQtII5dc+s3mQrU28mnSw9 whxKiE8/IDPOkzJpRaU+Tbny1Dj9zNj42YiuqoetzxcNXbE2wlvvoMSsqwO6/90376tntqA8PDS xka X-Received: by 2002:a05:690c:298:b0:7c4:86d:5e4b with SMTP id 00721157ae682-7c4086d6187mr37021717b3.41.1778528942944; Mon, 11 May 2026 12:49:02 -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-7bed8946d5dsm73201827b3.14.2026.05.11.12.49.01 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 11 May 2026 12:49:01 -0700 (PDT) Date: Mon, 11 May 2026 15:49:00 -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-4-4b50ed09b794@gmail.com> References: <20260508-nsim-psp-crypto-v1-0-4b50ed09b794@gmail.com> <20260508-nsim-psp-crypto-v1-4-4b50ed09b794@gmail.com> Subject: Re: [PATCH net-next 4/6] netdevsim: psp: implement kdf from psp spec 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: > 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. > 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. > + nsim_psp_derive_key(ns->psp.dev_keys[phase], assoc->spi, version, > + assoc->key); > > return 0; > } > @@ -186,8 +222,15 @@ static int nsim_assoc_add(struct psp_dev *psd, struct psp_assoc *pas, > static int nsim_key_rotate(struct psp_dev *psd, struct netlink_ext_ack *extack) > { > struct netdevsim *ns = psd->drv_priv; > + unsigned int next_phase; > > + psd->generation = 0; > ns->psp.spi = (ns->psp.spi & PSP_SPI_KEY_PHASE) ^ PSP_SPI_KEY_PHASE; > + next_phase = !!(ns->psp.spi & PSP_SPI_KEY_PHASE); > + > + spin_lock_bh(&ns->psp.dev_keys_lock); > + get_random_bytes(ns->psp.dev_keys[next_phase], NSIM_PSP_DEV_KEY_SIZE); > + spin_unlock_bh(&ns->psp.dev_keys_lock); > > return 0; > } > @@ -295,6 +338,10 @@ int nsim_psp_init(struct netdevsim *ns) > struct dentry *ddir = ns->nsim_dev_port->ddir; > struct psp_dev *psd; > > + spin_lock_init(&ns->psp.dev_keys_lock); > + get_random_bytes(ns->psp.dev_keys[0], NSIM_PSP_DEV_KEY_SIZE); > + get_random_bytes(ns->psp.dev_keys[1], NSIM_PSP_DEV_KEY_SIZE); > + > psd = psp_dev_create(ns->netdev, &nsim_psp_ops, &nsim_psp_caps, ns); > if (IS_ERR(psd)) > return PTR_ERR(psd); > > -- > 2.52.0 >