| Message ID | 20200625153723.8428-1-lkmlabelt@gmail.com |
|---|---|
| Headers | show |
| Series | Drivers: hv: vmbus: vmbus_requestor data structure | expand |
> Andres Beltran (3): > Drivers: hv: vmbus: Add vmbus_requestor data structure for VMBus > hardening > scsi: storvsc: Use vmbus_requestor to generate transaction ids for > VMBus hardening > hv_netvsc: Use vmbus_requestor to generate transaction ids for VMBus > hardening For the series, Tested-by: Andrea Parri <parri.andrea@gmail.com> Thanks, Andrea
On Thu, Jun 25, 2020 at 11:37:20AM -0400, Andres Beltran wrote: > From: Andres Beltran (Microsoft) <lkmlabelt@gmail.com> > > Currently, VMbus drivers use pointers into guest memory as request IDs > for interactions with Hyper-V. To be more robust in the face of errors > or malicious behavior from a compromised Hyper-V, avoid exposing > guest memory addresses to Hyper-V. Also avoid Hyper-V giving back a > bad request ID that is then treated as the address of a guest data > structure with no validation. Instead, encapsulate these memory > addresses and provide small integers as request IDs. > > The first patch creates the definitions for the data structure, provides > helper methods to generate new IDs and retrieve data, and > allocates/frees the memory needed for vmbus_requestor. > > The second and third patches make use of vmbus_requestor to send request > IDs to Hyper-V in storvsc and netvsc respectively. > Per my understanding, this new data structure is per-channel, so it won't introduce contention on the lock in multi-queue scenario. Have you done any testing to confirm there is no severe performance regression? Wei. > Thanks. > Andres Beltran > > Cc: linux-scsi@vger.kernel.org > Cc: netdev@vger.kernel.org > Cc: "James E.J. Bottomley" <jejb@linux.ibm.com> > Cc: "Martin K. Petersen" <martin.petersen@oracle.com> > Cc: "David S. Miller" <davem@davemloft.net> > Cc: Jakub Kicinski <kuba@kernel.org> > > Andres Beltran (3): > Drivers: hv: vmbus: Add vmbus_requestor data structure for VMBus > hardening > scsi: storvsc: Use vmbus_requestor to generate transaction ids for > VMBus hardening > hv_netvsc: Use vmbus_requestor to generate transaction ids for VMBus > hardening > > drivers/hv/channel.c | 150 ++++++++++++++++++++++++++++++ > drivers/net/hyperv/hyperv_net.h | 10 ++ > drivers/net/hyperv/netvsc.c | 56 +++++++++-- > drivers/net/hyperv/rndis_filter.c | 1 + > drivers/scsi/storvsc_drv.c | 62 ++++++++++-- > include/linux/hyperv.h | 22 +++++ > 6 files changed, 283 insertions(+), 18 deletions(-) > > -- > 2.25.1 >
On Fri, Jun 26, 2020 at 01:42:27PM +0000, Wei Liu wrote: > On Thu, Jun 25, 2020 at 11:37:20AM -0400, Andres Beltran wrote: > > From: Andres Beltran (Microsoft) <lkmlabelt@gmail.com> > > > > Currently, VMbus drivers use pointers into guest memory as request IDs > > for interactions with Hyper-V. To be more robust in the face of errors > > or malicious behavior from a compromised Hyper-V, avoid exposing > > guest memory addresses to Hyper-V. Also avoid Hyper-V giving back a > > bad request ID that is then treated as the address of a guest data > > structure with no validation. Instead, encapsulate these memory > > addresses and provide small integers as request IDs. > > > > The first patch creates the definitions for the data structure, provides > > helper methods to generate new IDs and retrieve data, and > > allocates/frees the memory needed for vmbus_requestor. > > > > The second and third patches make use of vmbus_requestor to send request > > IDs to Hyper-V in storvsc and netvsc respectively. > > > > Per my understanding, this new data structure is per-channel, so it > won't introduce contention on the lock in multi-queue scenario. Have you > done any testing to confirm there is no severe performance regression? I did run some performance tests using our dev pipeline (storage and network workloads). I did not find regressions w.r.t. baseline. Andrea
On Fri, Jun 26, 2020 at 04:48:17PM +0200, Andrea Parri wrote: > On Fri, Jun 26, 2020 at 01:42:27PM +0000, Wei Liu wrote: > > On Thu, Jun 25, 2020 at 11:37:20AM -0400, Andres Beltran wrote: > > > From: Andres Beltran (Microsoft) <lkmlabelt@gmail.com> > > > > > > Currently, VMbus drivers use pointers into guest memory as request IDs > > > for interactions with Hyper-V. To be more robust in the face of errors > > > or malicious behavior from a compromised Hyper-V, avoid exposing > > > guest memory addresses to Hyper-V. Also avoid Hyper-V giving back a > > > bad request ID that is then treated as the address of a guest data > > > structure with no validation. Instead, encapsulate these memory > > > addresses and provide small integers as request IDs. > > > > > > The first patch creates the definitions for the data structure, provides > > > helper methods to generate new IDs and retrieve data, and > > > allocates/frees the memory needed for vmbus_requestor. > > > > > > The second and third patches make use of vmbus_requestor to send request > > > IDs to Hyper-V in storvsc and netvsc respectively. > > > > > > > Per my understanding, this new data structure is per-channel, so it > > won't introduce contention on the lock in multi-queue scenario. Have you > > done any testing to confirm there is no severe performance regression? > > I did run some performance tests using our dev pipeline (storage and > network workloads). I did not find regressions w.r.t. baseline. Thanks, that's good to hear. Wei. > > Andrea
From: Andres Beltran (Microsoft) <lkmlabelt@gmail.com> Currently, VMbus drivers use pointers into guest memory as request IDs for interactions with Hyper-V. To be more robust in the face of errors or malicious behavior from a compromised Hyper-V, avoid exposing guest memory addresses to Hyper-V. Also avoid Hyper-V giving back a bad request ID that is then treated as the address of a guest data structure with no validation. Instead, encapsulate these memory addresses and provide small integers as request IDs. The first patch creates the definitions for the data structure, provides helper methods to generate new IDs and retrieve data, and allocates/frees the memory needed for vmbus_requestor. The second and third patches make use of vmbus_requestor to send request IDs to Hyper-V in storvsc and netvsc respectively. Thanks. Andres Beltran Cc: linux-scsi@vger.kernel.org Cc: netdev@vger.kernel.org Cc: "James E.J. Bottomley" <jejb@linux.ibm.com> Cc: "Martin K. Petersen" <martin.petersen@oracle.com> Cc: "David S. Miller" <davem@davemloft.net> Cc: Jakub Kicinski <kuba@kernel.org> Andres Beltran (3): Drivers: hv: vmbus: Add vmbus_requestor data structure for VMBus hardening scsi: storvsc: Use vmbus_requestor to generate transaction ids for VMBus hardening hv_netvsc: Use vmbus_requestor to generate transaction ids for VMBus hardening drivers/hv/channel.c | 150 ++++++++++++++++++++++++++++++ drivers/net/hyperv/hyperv_net.h | 10 ++ drivers/net/hyperv/netvsc.c | 56 +++++++++-- drivers/net/hyperv/rndis_filter.c | 1 + drivers/scsi/storvsc_drv.c | 62 ++++++++++-- include/linux/hyperv.h | 22 +++++ 6 files changed, 283 insertions(+), 18 deletions(-)