From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mail-pl1-f180.google.com (mail-pl1-f180.google.com [209.85.214.180]) (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 1393E13D52B for ; Thu, 9 Jan 2025 07:41:56 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=209.85.214.180 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736408519; cv=none; b=UjERxYCb1AaIJ4Ph36B5g8gOJwCgCRrCJ3A0j4yHkuzqZbDIinLlMPs7nBstob6+o/bkxRRSQS6jv9ZRrB2GTqvsmUQm4s4XLMaCF1EuAPzaVFIkEYZPOEqxF1Y3bkXtAJw57aRhLW0mBi1lO3nN1oUalAzE7ZPhYcuLUfZ8Ebk= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1736408519; c=relaxed/simple; bh=Pl+1xEqrW1IF0EiFRc252FTvX3vzsbZHF/HiOa6V3hI=; h=Message-ID:Date:MIME-Version:Subject:To:Cc:References:From: In-Reply-To:Content-Type; b=VSipfA62oSvB5UanapJtTFAedqP7rtP2l2Wle5ocB4b97acJLQfXFgdenwNT2ESvnLcV/+dvUfQsnKFqdLhKQWVmZYlfmRcb5XInlaiCylxe0loIVUbfpVZXmJWX1WfsyWNuE9/JZ2PGHwC1fLpNF7l8D9zfETRq+0wV9perbpc= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=daynix.com; spf=pass smtp.mailfrom=daynix.com; dkim=pass (2048-bit key) header.d=daynix-com.20230601.gappssmtp.com header.i=@daynix-com.20230601.gappssmtp.com header.b=yI5QcCUO; arc=none smtp.client-ip=209.85.214.180 Authentication-Results: smtp.subspace.kernel.org; dmarc=none (p=none dis=none) header.from=daynix.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=daynix.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=daynix-com.20230601.gappssmtp.com header.i=@daynix-com.20230601.gappssmtp.com header.b="yI5QcCUO" Received: by mail-pl1-f180.google.com with SMTP id d9443c01a7336-2167141dfa1so10393195ad.1 for ; Wed, 08 Jan 2025 23:41:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=daynix-com.20230601.gappssmtp.com; s=20230601; t=1736408516; x=1737013316; 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=zujq2FV01D6C2KPe0/EF8xmEzpLBI/t0RD3pI7VCDdo=; b=yI5QcCUOTfFkCRIKaIrEraVpL5GKdr70Cbw2jy9TqWfvH1hbeqhewj9IZbX+3l5SUf KX0TXLjr6qMoQkinOHj9WqGYDJrszYPCBzrhYESbrvuq3t6Kl9E4KY0hqz9/edqLPpD+ IM1ItO6u96gnCEr+FOh4jbMp2XBjwZiza2auO91abI+WEuniKN6SN6mj28oX/kN3ogNs O1/1NKGsMMmVR2K30TpKU/y+FG8GGJj02QmHFDGUcuBzrWp1C7gu84fZCSIQHxuxilUD 0H3NeKDMwS7SJUJL48M8qUBjdHG/PDRdgydug4BAtwNo60jMOPxm1/4QQ9COGTPuL2IF SgwA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1736408516; x=1737013316; h=content-transfer-encoding:in-reply-to:from:content-language :references:cc:to:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=zujq2FV01D6C2KPe0/EF8xmEzpLBI/t0RD3pI7VCDdo=; b=Xu2DAVpTFTx1q5Ko2tIcMucgNjcVyQOeAE0KVDQvhjdi6ctpgxwq7SWEEOVMZnih79 41DnSXbwDsN7fypL2raYRB2wAL01CAtr7dafFxX7E1x1uQMt8tUUUUXRwR9+8afyt3Dc XMbG7P6YOkD7xKF+Ou185RFhQ1uDgy8YsKjyJNZ6RP+PpOHjLFc/izaNmwXJWUYOB8O+ C5HKTU9Cp3E2lLV0j8PGG9T1qyW7nv2P8nxcIFOEfqKlf5xY9mm+ce3NMdXI5/PlRDoV ZGsJxoEqvokpN/obI1FMr7K2SwkAjXuQJ0R5Q15vIWjyiTQpFTZtkDZwuFdFKURR8uCF KBWQ== X-Forwarded-Encrypted: i=1; AJvYcCVd2/MBvpJBDw/+2D5pi9lToluXMbfyooFVraZT9xAlwKg+iQugCqCzIIc0tnMifvSv9IHA/ug=@vger.kernel.org X-Gm-Message-State: AOJu0Yy1SlvmeJb+KgfC5ZWpI3TNqJn2fUzl9VpwJXp+FrBBJ3Q6sRoJ ihzDQJ+N87UqE7iJYwcYOfR6zOwJyP/JlS42nhv6d6W/y0pN1/GfWlx+q0PD/G0= X-Gm-Gg: ASbGncuJ5Crs8q6kTd+ChcAhTidgJFNDzMKQZxzRLAvsHeGTG7s/hB8xkEiWl0VmApS iEK90TuMIlessyE/VRZoNUitLXJCRgY7+NzmRUynoWfzxn+ZqZo+tn82Y7glJ+zU1k0GtsRCRLv wf8Rg4RruhERTDNYO+hSkjPtcBynJvGXe/WQ1Yh+wtMUiKbnakpRVSfGyMl0QKwJtPQUkghhUH7 9o4bU5YKeT4DQRtXZUF01PE5r139XuVd4YW7jpfL2muHmY7WuwKg8FSd6PpgJqTYj4= X-Google-Smtp-Source: AGHT+IHoQ1/i8R8+7m2WyjiW1QZh9ruYZdAVL4zxUuyhPIV5VRkeFn1oW3Ykol5jTRSqrVxVwBQ5DQ== X-Received: by 2002:a17:902:eccf:b0:215:a808:61cf with SMTP id d9443c01a7336-21a8d6ca6bbmr42525445ad.25.1736408516440; Wed, 08 Jan 2025 23:41:56 -0800 (PST) Received: from [157.82.203.37] ([157.82.203.37]) by smtp.gmail.com with ESMTPSA id d9443c01a7336-219dc9d44a0sm338516125ad.165.2025.01.08.23.41.51 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 08 Jan 2025 23:41:56 -0800 (PST) Message-ID: <571a2d61-5fbe-4e49-b4d1-6bf0c7604a57@daynix.com> Date: Thu, 9 Jan 2025 16:41:50 +0900 Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH v2 2/3] tun: Pad virtio header with zero To: "Michael S. Tsirkin" Cc: Jonathan Corbet , Willem de Bruijn , Jason Wang , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Xuan Zhuo , Shuah Khan , linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, netdev@vger.kernel.org, kvm@vger.kernel.org, virtualization@lists.linux-foundation.org, linux-kselftest@vger.kernel.org, Yuri Benditovich , Andrew Melnychenko , Stephen Hemminger , gur.stavi@huawei.com, devel@daynix.com References: <20250109-tun-v2-0-388d7d5a287a@daynix.com> <20250109-tun-v2-2-388d7d5a287a@daynix.com> <20250109023056-mutt-send-email-mst@kernel.org> Content-Language: en-US From: Akihiko Odaki In-Reply-To: <20250109023056-mutt-send-email-mst@kernel.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit On 2025/01/09 16:31, Michael S. Tsirkin wrote: > On Thu, Jan 09, 2025 at 03:58:44PM +0900, Akihiko Odaki wrote: >> tun used to simply advance iov_iter when it needs to pad virtio header, >> which leaves the garbage in the buffer as is. This is especially >> problematic when tun starts to allow enabling the hash reporting >> feature; even if the feature is enabled, the packet may lack a hash >> value and may contain a hole in the virtio header because the packet >> arrived before the feature gets enabled or does not contain the >> header fields to be hashed. If the hole is not filled with zero, it is >> impossible to tell if the packet lacks a hash value. >> >> In theory, a user of tun can fill the buffer with zero before calling >> read() to avoid such a problem, but leaving the garbage in the buffer is >> awkward anyway so fill the buffer in tun. >> >> Signed-off-by: Akihiko Odaki > > But if the user did it, you have just overwritten his value, > did you not? Yes. but that means the user expects some part of buffer is not filled after read() or recvmsg(). I'm a bit worried that not filling the buffer may break assumptions others (especially the filesystem and socket infrastructures in the kernel) may have. If we are really confident that it will not cause problems, this behavior can be opt-in based on a flag or we can just write some documentation warning userspace programmers to initialize the buffer. > >> --- >> drivers/net/tun_vnet.c | 3 ++- >> 1 file changed, 2 insertions(+), 1 deletion(-) >> >> diff --git a/drivers/net/tun_vnet.c b/drivers/net/tun_vnet.c >> index fe842df9e9ef..ffb2186facd3 100644 >> --- a/drivers/net/tun_vnet.c >> +++ b/drivers/net/tun_vnet.c >> @@ -138,7 +138,8 @@ int tun_vnet_hdr_put(int sz, struct iov_iter *iter, >> if (copy_to_iter(hdr, sizeof(*hdr), iter) != sizeof(*hdr)) >> return -EFAULT; >> >> - iov_iter_advance(iter, sz - sizeof(*hdr)); >> + if (iov_iter_zero(sz - sizeof(*hdr), iter) != sz - sizeof(*hdr)) >> + return -EFAULT; >> >> return 0; >> } >> >> -- >> 2.47.1 >