| Message ID | 20250109-tun-v2-2-388d7d5a287a@daynix.com (mailing list archive) |
|---|---|
| State | Changes Requested |
| Delegated to: | Netdev Maintainers |
| Headers | show |
| Series | tun: Unify vnet implementation and fill full vnet header | expand |
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 <akihiko.odaki@daynix.com> But if the user did it, you have just overwritten his value, did you not? > --- > 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
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 <akihiko.odaki@daynix.com> > > 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 >
On Thu, Jan 09, 2025 at 02:31:37AM -0500, 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 <akihiko.odaki@daynix.com> > > But if the user did it, you have just overwritten his value, > did you not? To clearify, I mean if user pre-filled buffer with 1, you have now regressed it. Patch 3 fixes it back, but - not pretty. > > --- > > 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
On Thu, Jan 09, 2025 at 04:41:50PM +0900, Akihiko Odaki wrote: > 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 <akihiko.odaki@daynix.com> > > > > 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. It's been like this for years, I'd say we wait until we know there's a problem? > > > > > --- > > > 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 > >
On 2025/01/09 16:43, Michael S. Tsirkin wrote: > On Thu, Jan 09, 2025 at 04:41:50PM +0900, Akihiko Odaki wrote: >> 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 <akihiko.odaki@daynix.com> >>> >>> 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. > > It's been like this for years, I'd say we wait until we know there's a problem? Perhaps we can just leave it as is. Let me ask filesystem and networking people: Is it OK to leave some part of buffer uninitialized with read_iter() or recvmsg()? > >>> >>>> --- >>>> 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 >>> >
On Thu 09-01-25 18:36:52, Akihiko Odaki wrote: > On 2025/01/09 16:43, Michael S. Tsirkin wrote: > > On Thu, Jan 09, 2025 at 04:41:50PM +0900, Akihiko Odaki wrote: > > > 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 <akihiko.odaki@daynix.com> > > > > > > > > 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. > > > > It's been like this for years, I'd say we wait until we know there's a problem? > > Perhaps we can just leave it as is. Let me ask filesystem and networking > people: > > Is it OK to leave some part of buffer uninitialized with read_iter() or > recvmsg()? I think that leaving part of the IO buffer within returned IO length uninitialized is a very bad practice and I'm not aware of any place in filesystem area that would do that. It makes life unnecessarily harder for userspace and also it is invitation for subtle information leaks (depending on who allocates the buffer and who then gets to read the results). So I think the patch makes sense. Honza
Akihiko Odaki wrote: > 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. Zero is a valid hash value, so cannot be used as an indication that hashing is inactive. > >> 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 <akihiko.odaki@daynix.com> > > > > 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 this is user memory that is ignored by the kernel, just reflected back, then there is no need in general to zero it. There are many such instances, also in msg_control. If not zeroing leads to ambiguity with the new feature, that would be a reason to add it -- it is always safe to do so. > 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.
On Thu, Jan 9, 2025 at 2:59 PM Akihiko Odaki <akihiko.odaki@daynix.com> 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. I'm not sure I will get here, could we do this in the series of hash reporting? > > 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 <akihiko.odaki@daynix.com> > --- > 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; There're various callers of iov_iter_advance(), do we need to fix them all? Thanks > } > > -- > 2.47.1 >
On 2025/01/09 21:46, Willem de Bruijn wrote: > Akihiko Odaki wrote: >> 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. > > Zero is a valid hash value, so cannot be used as an indication that > hashing is inactive. Zeroing will initialize the hash_report field to VIRTIO_NET_HASH_REPORT_NONE, which tells it does not have 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 <akihiko.odaki@daynix.com> >>> >>> 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 this is user memory that is ignored by the kernel, just reflected > back, then there is no need in general to zero it. There are many such > instances, also in msg_control. More specifically, is there any instance of recvmsg() implementation which returns N and does not fill the complete N bytes of msg_iter? > > If not zeroing leads to ambiguity with the new feature, that would be > a reason to add it -- it is always safe to do so. > >> 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.
On Fri, Jan 10, 2025 at 01:38:06PM +0900, Akihiko Odaki wrote: > On 2025/01/09 21:46, Willem de Bruijn wrote: > > Akihiko Odaki wrote: > > > 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. > > > > Zero is a valid hash value, so cannot be used as an indication that > > hashing is inactive. > > Zeroing will initialize the hash_report field to > VIRTIO_NET_HASH_REPORT_NONE, which tells it does not have 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 <akihiko.odaki@daynix.com> > > > > > > > > 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 this is user memory that is ignored by the kernel, just reflected > > back, then there is no need in general to zero it. There are many such > > instances, also in msg_control. > > More specifically, is there any instance of recvmsg() implementation which > returns N and does not fill the complete N bytes of msg_iter? The one in tun. It was a silly idea but it has been here for years now. > > > > If not zeroing leads to ambiguity with the new feature, that would be > > a reason to add it -- it is always safe to do so. > > > 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.
On 2025/01/10 12:27, Jason Wang wrote: > On Thu, Jan 9, 2025 at 2:59 PM Akihiko Odaki <akihiko.odaki@daynix.com> 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. > > I'm not sure I will get here, could we do this in the series of hash reporting? I'll create another series dedicated for this and num_buffers change as suggested by Willem. > >> >> 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 <akihiko.odaki@daynix.com> >> --- >> 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; > > There're various callers of iov_iter_advance(), do we need to fix them all? No. For example, there are iov_iter_advance() calls for SOCK_ZEROCOPY in tun_get_user() and tap_get_user(). They are fine as they are not writing buffers after skipping. The problem is that read_iter() and recvmsg() says it wrote N bytes but it leaves some of this N bytes uninialized. Such an implementation may be created even without iov_iter_advance() (for example just returning a too big number), and it is equally problematic with the current tun_get_user()/tap_get_user(). Regards, Akihiko Odaki > > Thanks > >> } > >> >> -- >> 2.47.1 >> >
On 2025/01/10 17:33, Michael S. Tsirkin wrote: > On Fri, Jan 10, 2025 at 01:38:06PM +0900, Akihiko Odaki wrote: >> On 2025/01/09 21:46, Willem de Bruijn wrote: >>> Akihiko Odaki wrote: >>>> 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. >>> >>> Zero is a valid hash value, so cannot be used as an indication that >>> hashing is inactive. >> >> Zeroing will initialize the hash_report field to >> VIRTIO_NET_HASH_REPORT_NONE, which tells it does not have 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 <akihiko.odaki@daynix.com> >>>>> >>>>> 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 this is user memory that is ignored by the kernel, just reflected >>> back, then there is no need in general to zero it. There are many such >>> instances, also in msg_control. >> >> More specifically, is there any instance of recvmsg() implementation which >> returns N and does not fill the complete N bytes of msg_iter? > > The one in tun. It was a silly idea but it has been here for years now. Except tun. If there is such an example of recvmsg() implementation and it is not accidental and people have agreed to keep it functioning, we can confidently say this construct is safe without fearing pushback from people maintaining filesystem/networking infrastructure. Ultimately I want those people decide if this can be supported for the future or not. > > >>> >>> If not zeroing leads to ambiguity with the new feature, that would be >>> a reason to add it -- it is always safe to do so. >>>> 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. >
Akihiko Odaki wrote: > On 2025/01/10 17:33, Michael S. Tsirkin wrote: > > On Fri, Jan 10, 2025 at 01:38:06PM +0900, Akihiko Odaki wrote: > >> On 2025/01/09 21:46, Willem de Bruijn wrote: > >>> Akihiko Odaki wrote: > >>>> 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. > >>> > >>> Zero is a valid hash value, so cannot be used as an indication that > >>> hashing is inactive. > >> > >> Zeroing will initialize the hash_report field to > >> VIRTIO_NET_HASH_REPORT_NONE, which tells it does not have 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 <akihiko.odaki@daynix.com> > >>>>> > >>>>> 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 this is user memory that is ignored by the kernel, just reflected > >>> back, then there is no need in general to zero it. There are many such > >>> instances, also in msg_control. > >> > >> More specifically, is there any instance of recvmsg() implementation which > >> returns N and does not fill the complete N bytes of msg_iter? > > > > The one in tun. It was a silly idea but it has been here for years now. > > Except tun. If there is such an example of recvmsg() implementation and > it is not accidental and people have agreed to keep it functioning, we > can confidently say this construct is safe without fearing pushback from > people maintaining filesystem/networking infrastructure. Ultimately I > want those people decide if this can be supported for the future or not. It seems preferable to write a value. Userspace should have not assumption that whatever it writes there will be reflected unmodified. That said, that is the tiny risk of changing this in established code. If it worked without issue so far, without hashing, then probably the change should only go to net-next. As said, there are examples in msg_control. I don't immediately have an example where this is the case in msg_data today. A search for iov_iter_advance might show something.
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; }
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 <akihiko.odaki@daynix.com> --- drivers/net/tun_vnet.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)