netdev - Re: [PATCH 0/2] fix kernel crash with macvtap on top of LRO

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <87r4g0ngs0.fsf@rustcorp.com.au>
Date:	Tue, 18 Jun 2013 14:42:47 +0930
From:	Rusty Russell <rusty@...tcorp.com.au>
To:	Ben Hutchings <bhutchings@...arflare.com>
Cc:	"Michael S. Tsirkin" <mst@...hat.com>,
	David Miller <davem@...emloft.net>, eric.dumazet@...il.com,
	netdev@...r.kernel.org, linux-kernel@...r.kernel.org,
	virtualization@...ts.linux-foundation.org
Subject: Re: [PATCH 0/2] fix kernel crash with macvtap on top of LRO

Ben Hutchings <bhutchings@...arflare.com> writes:
> On Mon, 2013-06-17 at 11:05 +0930, Rusty Russell wrote:
>> I thought LRO was deprecated and GRO was the new hotness, but I haven't
>> been following.  Do we still care about LRO?
>
> The old software LRO implementation, inet_lro, is deprecated in favour
> of GRO and is now only used by one or two drivers.  Hardware/firmware
> implementations of LRO are still in use and not deprecated, but we try
> to disable them on devices for which forwarding is enabled because of
> this information loss.

Right, thanks for the clarification.

Hardware implementations of LRO which can't meet GRO rules are only
semi-useful, and that should be fed back to vendors.  Hard.

> The problem I was talking about is this: you can put macvlan on top of a
> device that has LRO enabled, and then if the macvtap/macvlan device is
> used for forwarding the output packets might not look the same as those
> originally received.  So LRO should be disabled on the underlying device
> whenever forwarding is enabled on the macvtap/macvlan device; however we
> can't necessarily tell when that happens as the forwarding might be done
> inside a VM.  Maybe this is just too obscure a use case to worry much
> about getting it right automatically.

The VM needs to tell us it's OK with such mangling, otherwise we
shouldn't do it (at least by default).  The same way we'd be annoyed if
a card rev started doing LRO without the driver explicitly enabling it.

Cheers,
Rusty.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html