Re: [PATCH v2 net-next] hv_netvsc: Copy packets sent by Hyper-V out of the receive buffer

2021-02-03 Thread Andrea Parri
On Tue, Feb 02, 2021 at 11:45:49AM -0800, Jakub Kicinski wrote:
> On Tue, 2 Feb 2021 09:18:43 +0100 Andrea Parri wrote:
> > Hi net maintainers,
> > 
> > 
> > On Sat, Jan 30, 2021 at 12:50:06AM +, 
> > patchwork-bot+netdev...@kernel.org wrote:
> > > Hello:
> > > 
> > > This patch was applied to netdev/net-next.git (refs/heads/master):
> > > 
> > > On Tue, 26 Jan 2021 17:29:07 +0100 you wrote:  
> > > > Pointers to receive-buffer packets sent by Hyper-V are used within the
> > > > guest VM.  Hyper-V can send packets with erroneous values or modify
> > > > packet fields after they are processed by the guest.  To defend against
> > > > these scenarios, copy (sections of) the incoming packet after validating
> > > > their length and offset fields in netvsc_filter_receive().  In this way,
> > > > the packet can no longer be modified by the host.
> > > > 
> > > > [...]  
> > > 
> > > Here is the summary with links:
> > >   - [v2,net-next] hv_netvsc: Copy packets sent by Hyper-V out of the 
> > > receive buffer
> > > https://git.kernel.org/netdev/net-next/c/0ba35fe91ce3  
> > 
> > I'd have some fixes on top of this and I'm wondering about the process: 
> > would
> > you consider fixes/patches on top of this commit now? 
> 
> Fixes for bugs present in Linus's tree?
> 
> You need to target the net tree, and give us instructions on how to
> resolve the conflict which will arise from merging net into net-next.
> 
> > would you rather prefer me to squash these fixes into a v3? other?
> 
> Networking trees are immutable, and v2 was already applied. We could
> do a revert, apply fix, apply v3, but we prefer to just handle the 
> merge conflict.

Thanks for the clarification, Jakub.

And sorry for the confusion; let me just send out the 'fixes'/patches (I
have one targeting the net tree and two targeting the net-next tree, with
no conflict between them), so that they can be reviewed and we can agree
/discuss any further steps.

Thanks,
  Andrea


Re: [PATCH v2 net-next] hv_netvsc: Copy packets sent by Hyper-V out of the receive buffer

2021-02-02 Thread Jakub Kicinski
On Tue, 2 Feb 2021 09:18:43 +0100 Andrea Parri wrote:
> Hi net maintainers,
> 
> 
> On Sat, Jan 30, 2021 at 12:50:06AM +, patchwork-bot+netdev...@kernel.org 
> wrote:
> > Hello:
> > 
> > This patch was applied to netdev/net-next.git (refs/heads/master):
> > 
> > On Tue, 26 Jan 2021 17:29:07 +0100 you wrote:  
> > > Pointers to receive-buffer packets sent by Hyper-V are used within the
> > > guest VM.  Hyper-V can send packets with erroneous values or modify
> > > packet fields after they are processed by the guest.  To defend against
> > > these scenarios, copy (sections of) the incoming packet after validating
> > > their length and offset fields in netvsc_filter_receive().  In this way,
> > > the packet can no longer be modified by the host.
> > > 
> > > [...]  
> > 
> > Here is the summary with links:
> >   - [v2,net-next] hv_netvsc: Copy packets sent by Hyper-V out of the 
> > receive buffer
> > https://git.kernel.org/netdev/net-next/c/0ba35fe91ce3  
> 
> I'd have some fixes on top of this and I'm wondering about the process: would
> you consider fixes/patches on top of this commit now? 

Fixes for bugs present in Linus's tree?

You need to target the net tree, and give us instructions on how to
resolve the conflict which will arise from merging net into net-next.

> would you rather prefer me to squash these fixes into a v3? other?

Networking trees are immutable, and v2 was already applied. We could
do a revert, apply fix, apply v3, but we prefer to just handle the 
merge conflict.


Re: [PATCH v2 net-next] hv_netvsc: Copy packets sent by Hyper-V out of the receive buffer

2021-02-02 Thread Andrea Parri
Hi net maintainers,


On Sat, Jan 30, 2021 at 12:50:06AM +, patchwork-bot+netdev...@kernel.org 
wrote:
> Hello:
> 
> This patch was applied to netdev/net-next.git (refs/heads/master):
> 
> On Tue, 26 Jan 2021 17:29:07 +0100 you wrote:
> > Pointers to receive-buffer packets sent by Hyper-V are used within the
> > guest VM.  Hyper-V can send packets with erroneous values or modify
> > packet fields after they are processed by the guest.  To defend against
> > these scenarios, copy (sections of) the incoming packet after validating
> > their length and offset fields in netvsc_filter_receive().  In this way,
> > the packet can no longer be modified by the host.
> > 
> > [...]
> 
> Here is the summary with links:
>   - [v2,net-next] hv_netvsc: Copy packets sent by Hyper-V out of the receive 
> buffer
> https://git.kernel.org/netdev/net-next/c/0ba35fe91ce3

I'd have some fixes on top of this and I'm wondering about the process: would
you consider fixes/patches on top of this commit now? would you rather prefer
me to squash these fixes into a v3? other?

Thanks,
  Andrea


Re: [PATCH v2 net-next] hv_netvsc: Copy packets sent by Hyper-V out of the receive buffer

2021-01-30 Thread patchwork-bot+netdevbpf
Hello:

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

On Tue, 26 Jan 2021 17:29:07 +0100 you wrote:
> Pointers to receive-buffer packets sent by Hyper-V are used within the
> guest VM.  Hyper-V can send packets with erroneous values or modify
> packet fields after they are processed by the guest.  To defend against
> these scenarios, copy (sections of) the incoming packet after validating
> their length and offset fields in netvsc_filter_receive().  In this way,
> the packet can no longer be modified by the host.
> 
> [...]

Here is the summary with links:
  - [v2,net-next] hv_netvsc: Copy packets sent by Hyper-V out of the receive 
buffer
https://git.kernel.org/netdev/net-next/c/0ba35fe91ce3

You are awesome, thank you!
--
Deet-doot-dot, I am a bot.
https://korg.docs.kernel.org/patchwork/pwbot.html




[PATCH v2 net-next] hv_netvsc: Copy packets sent by Hyper-V out of the receive buffer

2021-01-26 Thread Andrea Parri (Microsoft)
Pointers to receive-buffer packets sent by Hyper-V are used within the
guest VM.  Hyper-V can send packets with erroneous values or modify
packet fields after they are processed by the guest.  To defend against
these scenarios, copy (sections of) the incoming packet after validating
their length and offset fields in netvsc_filter_receive().  In this way,
the packet can no longer be modified by the host.

Reported-by: Juan Vazquez 
Signed-off-by: Andrea Parri (Microsoft) 
Cc: "David S. Miller" 
Cc: Jakub Kicinski 
Cc: net...@vger.kernel.org
---
Changes since v1 [1]:
  - copy certain PPIs into the RSC pkt

[1] https://lkml.kernel.org/r/20210126113847.1676-1-parri.and...@gmail.com

 drivers/net/hyperv/hyperv_net.h   | 93 +++--
 drivers/net/hyperv/netvsc.c   | 20 +++
 drivers/net/hyperv/netvsc_drv.c   | 24 
 drivers/net/hyperv/rndis_filter.c | 99 +--
 4 files changed, 150 insertions(+), 86 deletions(-)

diff --git a/drivers/net/hyperv/hyperv_net.h b/drivers/net/hyperv/hyperv_net.h
index 2a87cfa27ac02..e1a497d3c9ba4 100644
--- a/drivers/net/hyperv/hyperv_net.h
+++ b/drivers/net/hyperv/hyperv_net.h
@@ -105,9 +105,43 @@ struct ndis_recv_scale_param { /* 
NDIS_RECEIVE_SCALE_PARAMETERS */
u32 processor_masks_entry_size;
 };
 
-/* Fwd declaration */
-struct ndis_tcp_ip_checksum_info;
-struct ndis_pkt_8021q_info;
+struct ndis_tcp_ip_checksum_info {
+   union {
+   struct {
+   u32 is_ipv4:1;
+   u32 is_ipv6:1;
+   u32 tcp_checksum:1;
+   u32 udp_checksum:1;
+   u32 ip_header_checksum:1;
+   u32 reserved:11;
+   u32 tcp_header_offset:10;
+   } transmit;
+   struct {
+   u32 tcp_checksum_failed:1;
+   u32 udp_checksum_failed:1;
+   u32 ip_checksum_failed:1;
+   u32 tcp_checksum_succeeded:1;
+   u32 udp_checksum_succeeded:1;
+   u32 ip_checksum_succeeded:1;
+   u32 loopback:1;
+   u32 tcp_checksum_value_invalid:1;
+   u32 ip_checksum_value_invalid:1;
+   } receive;
+   u32  value;
+   };
+};
+
+struct ndis_pkt_8021q_info {
+   union {
+   struct {
+   u32 pri:3; /* User Priority */
+   u32 cfi:1; /* Canonical Format ID */
+   u32 vlanid:12; /* VLAN ID */
+   u32 reserved:16;
+   };
+   u32 value;
+   };
+};
 
 /*
  * Represent netvsc packet which contains 1 RNDIS and 1 ethernet frame
@@ -194,7 +228,8 @@ int netvsc_send(struct net_device *net,
struct sk_buff *skb,
bool xdp_tx);
 void netvsc_linkstatus_callback(struct net_device *net,
-   struct rndis_message *resp);
+   struct rndis_message *resp,
+   void *data);
 int netvsc_recv_callback(struct net_device *net,
 struct netvsc_device *nvdev,
 struct netvsc_channel *nvchan);
@@ -884,9 +919,10 @@ struct multi_recv_comp {
 #define NVSP_RSC_MAX 562 /* Max #RSC frags in a vmbus xfer page pkt */
 
 struct nvsc_rsc {
-   const struct ndis_pkt_8021q_info *vlan;
-   const struct ndis_tcp_ip_checksum_info *csum_info;
-   const u32 *hash_info;
+   struct ndis_pkt_8021q_info vlan;
+   struct ndis_tcp_ip_checksum_info csum_info;
+   u32 hash_info;
+   u8 ppi_flags; /* valid/present bits for the above PPIs */
u8 is_last; /* last RNDIS msg in a vmtransfer_page */
u32 cnt; /* #fragments in an RSC packet */
u32 pktlen; /* Full packet length */
@@ -894,6 +930,10 @@ struct nvsc_rsc {
u32 len[NVSP_RSC_MAX];
 };
 
+#define NVSC_RSC_VLAN  BIT(0)  /* valid/present bit for 'vlan' */
+#define NVSC_RSC_CSUM_INFO BIT(1)  /* valid/present bit for 'csum_info' */
+#define NVSC_RSC_HASH_INFO BIT(2)  /* valid/present bit for 'hash_info' */
+
 struct netvsc_stats {
u64 packets;
u64 bytes;
@@ -1002,6 +1042,7 @@ struct net_device_context {
 struct netvsc_channel {
struct vmbus_channel *channel;
struct netvsc_device *net_device;
+   void *recv_buf; /* buffer to copy packets out from the receive buffer */
const struct vmpacket_descriptor *desc;
struct napi_struct napi;
struct multi_send_data msd;
@@ -1234,18 +1275,6 @@ struct rndis_pktinfo_id {
u16 pkt_id;
 };
 
-struct ndis_pkt_8021q_info {
-   union {
-   struct {
-   u32 pri:3; /* User Priority */
-   u32 cfi:1; /* Canonical Format ID */
-   u32 vlanid:12; /* VLAN ID */
-   u32