mbox series

[v2,0/4] xen: harden netfront against malicious backends

Message ID 20210824102809.26370-1-jgross@suse.com
Headers show
Series xen: harden netfront against malicious backends | expand

Message

Juergen Gross Aug. 24, 2021, 10:28 a.m. UTC 
Xen backends of para-virtualized devices can live in dom0 kernel, dom0
user land, or in a driver domain. This means that a backend might
reside in a less trusted environment than the Xen core components, so
a backend should not be able to do harm to a Xen guest (it can still
mess up I/O data, but it shouldn't be able to e.g. crash a guest by
other means or cause a privilege escalation in the guest).

Unfortunately netfront in the Linux kernel is fully trusting its
backend. This series is fixing netfront in this regard.

It was discussed to handle this as a security problem, but the topic
was discussed in public before, so it isn't a real secret.

It should be mentioned that a similar series has been posted some years
ago by Marek Marczykowski-Górecki, but this series has not been applied
due to a Xen header not having been available in the Xen git repo at
that time. Additionally my series is fixing some more DoS cases.

Changes in V2:
- put netfront patches into own series
- comments addressed
- new patch 3

Juergen Gross (4):
  xen/netfront: read response from backend only once
  xen/netfront: don't read data from request on the ring page
  xen/netfront: disentangle tx_skb_freelist
  xen/netfront: don't trust the backend response data blindly

 drivers/net/xen-netfront.c | 272 +++++++++++++++++++++++--------------
 1 file changed, 169 insertions(+), 103 deletions(-)

Comments

Jan Beulich Aug. 24, 2021, 3:33 p.m. UTC | #1 
On 24.08.2021 12:28, Juergen Gross wrote:
> It should be mentioned that a similar series has been posted some years
> ago by Marek Marczykowski-Górecki, but this series has not been applied
> due to a Xen header not having been available in the Xen git repo at
> that time. Additionally my series is fixing some more DoS cases.

With this, wouldn't it have made sense to Cc Marek, in case he wants to
check against his own version (which over time may have evolved and
hence not match the earlier submission anymore)?

Jan
patchwork-bot+netdevbpf@kernel.org Aug. 25, 2021, 10 a.m. UTC | #2 
Hello:

This series was applied to netdev/net-next.git (refs/heads/master):

On Tue, 24 Aug 2021 12:28:05 +0200 you wrote:
> Xen backends of para-virtualized devices can live in dom0 kernel, dom0

> user land, or in a driver domain. This means that a backend might

> reside in a less trusted environment than the Xen core components, so

> a backend should not be able to do harm to a Xen guest (it can still

> mess up I/O data, but it shouldn't be able to e.g. crash a guest by

> other means or cause a privilege escalation in the guest).

> 

> [...]


Here is the summary with links:
  - [v2,1/4] xen/netfront: read response from backend only once
    https://git.kernel.org/netdev/net-next/c/8446066bf8c1
  - [v2,2/4] xen/netfront: don't read data from request on the ring page
    https://git.kernel.org/netdev/net-next/c/162081ec33c2
  - [v2,3/4] xen/netfront: disentangle tx_skb_freelist
    https://git.kernel.org/netdev/net-next/c/21631d2d741a
  - [v2,4/4] xen/netfront: don't trust the backend response data blindly
    https://git.kernel.org/netdev/net-next/c/a884daa61a7d

You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html
Marek Marczykowski-Górecki Sept. 10, 2021, 10:19 a.m. UTC | #3 
On Tue, Aug 24, 2021 at 05:33:10PM +0200, Jan Beulich wrote:
> On 24.08.2021 12:28, Juergen Gross wrote:

> > It should be mentioned that a similar series has been posted some years

> > ago by Marek Marczykowski-Górecki, but this series has not been applied

> > due to a Xen header not having been available in the Xen git repo at

> > that time. Additionally my series is fixing some more DoS cases.

> 

> With this, wouldn't it have made sense to Cc Marek, in case he wants to

> check against his own version (which over time may have evolved and

> hence not match the earlier submission anymore)?


I have compared this, and the blkfront series against my patches and
they seem to cover exactly the same set of issues. Besides one comment I
made separately, I think nothing is missing. Thanks!

BTW, shouldn't those those patches land in stable branches too? In some
threat models, I'd qualify them as security fixes.

-- 
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
Juergen Gross Sept. 10, 2021, 11:10 a.m. UTC | #4 
On 10.09.21 12:19, Marek Marczykowski-Górecki wrote:
> On Tue, Aug 24, 2021 at 05:33:10PM +0200, Jan Beulich wrote:

>> On 24.08.2021 12:28, Juergen Gross wrote:

>>> It should be mentioned that a similar series has been posted some years

>>> ago by Marek Marczykowski-Górecki, but this series has not been applied

>>> due to a Xen header not having been available in the Xen git repo at

>>> that time. Additionally my series is fixing some more DoS cases.

>>

>> With this, wouldn't it have made sense to Cc Marek, in case he wants to

>> check against his own version (which over time may have evolved and

>> hence not match the earlier submission anymore)?

> 

> I have compared this, and the blkfront series against my patches and

> they seem to cover exactly the same set of issues. Besides one comment I

> made separately, I think nothing is missing. Thanks!

> 

> BTW, shouldn't those those patches land in stable branches too? In some

> threat models, I'd qualify them as security fixes.


Its on my todo list.

Most stable branches will need backports, so this might require some
more time to get it finished.


Juergen