From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f178.google.com (mail-pl1-f178.google.com [209.85.214.178]) (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 0081E284682 for ; Tue, 22 Apr 2025 13:56:31 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.178 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1745330193; cv=none; b=AiRe62rQD/bMnLEdYw6P9oWJhDOfBqB+hYr6xPUvteYZ+DtNhAzofixvJcHLdq5oTfSSxCpdIPzNEGXmzG8d14HOuaPipnawQwJ7g61cDdWJmPhSEVFP8x3U9245He8wvBdTltrW+/+nj8A6+1J2gLO/3DYxT2y2FvYPr51aL68= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1745330193; c=relaxed/simple; bh=5UhTPLXTy54HSw4bbuMVr6NHCHxgfaB24c/UygOGD5o=; h=MIME-Version:References:In-Reply-To:From:Date:Message-ID:Subject: To:Cc:Content-Type; b=jwhSHtDU85GCHR9Hqmd9mrPkkoWCTXqh2CGhglEempSc7iX9MEzQM+buRD/4d/E5txHy2z/I3oUUpuTopDf1WH4mg5T/TzKFsMsdVZaYgLN0YjJ5G8UxDMJ/Yw64oAiCYNJJZkkSgALbcLLDBplGOWgv8kwKYKm8ItlTl+7inFk= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com; spf=pass smtp.mailfrom=google.com; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b=F12AWa1h; arc=none smtp.client-ip=209.85.214.178 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=reject dis=none) header.from=google.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=google.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=google.com header.i=@google.com header.b="F12AWa1h" Received: by mail-pl1-f178.google.com with SMTP id d9443c01a7336-2240aad70f2so180105ad.0 for ; Tue, 22 Apr 2025 06:56:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20230601; t=1745330191; x=1745934991; darn=vger.kernel.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=5UhTPLXTy54HSw4bbuMVr6NHCHxgfaB24c/UygOGD5o=; b=F12AWa1haXcsCudCgDYHjn2nNfZXI3lbEma09OMg5nCnR7GzJuX8RBzTsy+aLZxnlP G3KDr+MgQbOHQschhs2yKHUMROZvYMDuvkA2dOkccaWcJNess9Hp4TfbIqXjoGqli4kI +U9yYc2mKurzkivWGlJqXif6GYJ28rvsIfCD8cvv2EBltZDLmnDViJWWOYnCPSJ5BWuB strzglMGQBpP7YIbUEyB4vnYUBvjCuH11iIdAWWRCHUyZW75wzZPWGy2NSd8M+g+HmdR NoRgXS6T12hgTXSfSz24ARES3ZTJvZXG0GmbkKSy5ko8M/v0HdSGZMmYcx/neG7gmt9c YyDw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1745330191; x=1745934991; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=5UhTPLXTy54HSw4bbuMVr6NHCHxgfaB24c/UygOGD5o=; b=MWXXR5M1CMkhuFRcUPz4qDcVrUHvpN1fe4WdGq7EHrUu2aUzeyu/FdJj1QOALGbuUI WOwbrPV1XRVfYiBCo8qnlBjtBNUjMgkTm7VkhOXcAuAL4lvBFSSJTTt8h8UA5zytCS6Y V+FT35/RflBNVuXkdSetqYVIKhm3X4RdD99Zq0c9FokLjPGoSLvbTIVcGV1ogBA7qGAi u7QC1/lxP0Sol1y9Dxy4vvMSIRnUwBwMEHqqexFuRR1Dg1Hep2+kfiyR6vnq8ELnTHt9 aXObE36RBwsPKQfV8jb4flUtpzxwC4u/NeNcjbBmy8R/pQ3q6DXwtyQv5OtS8G21K+L5 QcDw== X-Forwarded-Encrypted: i=1; AJvYcCVShG+u65kr/IwHBKR0Bgp9xlzmzIk4gHB6BzmCrNww3+mTgEQE4/8NnDCmMtcGa6G2f3bZw5sgCQ==@vger.kernel.org X-Gm-Message-State: AOJu0YzPqAGfI2EutUdMKeV2b/0K5D2jgOLIC0mxk3hBsI9fnU97Vf7C kvpsWz/vRsIgXJCDbHIhoKL2x9V7iZfVMgolDNw3MLmPfbiJZ7BDAUIWp4dpyjN2BnLspr2ZYO3 kbJFKrnB4B5bJCXVE3DBbC0eSPRy5OTTdATwXe8v+fg2vLRo2hD7U X-Gm-Gg: ASbGncvXxHSlWgqEfCsHbaRhYzHAoo5oJ+JrTyOmVkyUJAG71qW8tAy1evm3/FwT3Mr X0DWRr0BpbpXGepFeTxP5waAEGd9BqmjEWJ8eIoG8z9KpaB7cHXea4n80Rl/QNnv1GVK0wcdx2g XCdE/zsdHjmvZ6dDIqPNpzyQA= X-Google-Smtp-Source: AGHT+IH/hAru3MKmJ60Z25FXBslSMx5hLypeOWFuJfnaTmWFJ711/aVQCwonng9BnnPokRail3ZgA21iLnH/6NJDRM0= X-Received: by 2002:a17:902:ce0a:b0:220:ce33:6385 with SMTP id d9443c01a7336-22c54797b1bmr9643675ad.9.1745330190914; Tue, 22 Apr 2025 06:56:30 -0700 (PDT) Precedence: bulk X-Mailing-List: io-uring@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 References: <20250417231540.2780723-1-almasrymina@google.com> <20250417231540.2780723-3-almasrymina@google.com> <484ecaad-56de-4c0d-b7fa-a3337557b0bf@gmail.com> In-Reply-To: <484ecaad-56de-4c0d-b7fa-a3337557b0bf@gmail.com> From: Mina Almasry Date: Tue, 22 Apr 2025 06:56:17 -0700 X-Gm-Features: ATxdqUFU-Nv8GeoWu8ltonWAw6xNaP21dKReuqOOxLDIWBd4SeZRRiQwqzNABOY Message-ID: Subject: Re: [PATCH net-next v9 2/9] net: add get_netmem/put_netmem support To: Pavel Begunkov Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org, linux-doc@vger.kernel.org, io-uring@vger.kernel.org, virtualization@lists.linux.dev, kvm@vger.kernel.org, linux-kselftest@vger.kernel.org, "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Simon Horman , Donald Hunter , Jonathan Corbet , Andrew Lunn , Jeroen de Borst , Harshitha Ramamurthy , Kuniyuki Iwashima , Willem de Bruijn , Jens Axboe , David Ahern , Neal Cardwell , "Michael S. Tsirkin" , Jason Wang , Xuan Zhuo , =?UTF-8?Q?Eugenio_P=C3=A9rez?= , Stefan Hajnoczi , Stefano Garzarella , Shuah Khan , sdf@fomichev.me, dw@davidwei.uk, Jamal Hadi Salim , Victor Nogueira , Pedro Tammela , Samiullah Khawaja Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Apr 22, 2025 at 1:43=E2=80=AFAM Pavel Begunkov wrote: > > On 4/18/25 00:15, Mina Almasry wrote: > > Currently net_iovs support only pp ref counts, and do not support a > > page ref equivalent. > > Makes me wonder why it's needed. In theory, nobody should ever be > taking page references without going through struct ubuf_info > handling first, all in kernel users of these pages should always > be paired with ubuf_info, as it's user memory, it's not stable, > and without ubuf_info the user is allowed to overwrite it. > The concern about the stability of the from-userspace data is already called out in the MSG_ZEROCOPY documentation that we're piggybacking devmem TX onto: https://www.kernel.org/doc/html/v4.15/networking/msg_zerocopy.html Basically the userspace passes the memory to the kernel and waits for a notification for when it's safe to reuse/overwrite the data. I don't know that it's a security concern. Basically if the userspace modifies the data before it gets the notification from the kernel, then it will mess up its own TX. The notification is sent by the kernel to the userspace when the skb is freed I believe, at that point it's safe to reuse the buffer as the kernel no longer needs it for TX. For devmem we do need to pin the binding until all TX users are done with it, so get_netmem will increase the refcount on the binding to keep it alive until the net stack is done with it. > Maybe there are some gray area cases like packet inspection or > tracing? However in this case, after the ubuf_info is dropped, the > user can overwrite the memory with its secrets. Definitely iffy > in security terms. > You can look at all the callers of skb_frag_ref to see all the code paths that grab a page ref on the frag today. There is also an inspection by me in the v5 changelog. --=20 Thanks, Mina