Abstract: A secure inference over Deep Neural Networks (DNNs) using secure two-party computation to perform privacy-preserving machine learning. The secure inference uses a particular type of comparison that can be used as a building block for various layers in the DNN including, for example, ReLU activations and divisions. The comparison securely computes a Boolean share of a bit representing whether input value x is less than input value y, where x is held by a user of the DNN, and where y is held by a provider of the DNN. Each party computing system parses their input into leaf strings of multiple bits. This is much more efficient than if the leaf strings were individual bits. Accordingly, the secure inference described herein is more readily adapted for using in complex DNNs.

Abstract: A framework for reliably communicating port information in a system of devices is provided. In one embodiment, each device in the system of devices can create a first record that includes port information pertaining to a plurality of ports of the device, where the plurality of ports are usable for communicatively coupling the device to other devices in the system of devices. The device can further receive, from the other devices in the system of devices, one or more second records including port information pertaining to the ports of the other devices, and can store the first record and the one or more second records in a data store maintained locally on the device. The device can then forward copies of the first record and the one or more second records out of each of the plurality of ports, thereby causing the copies of the first record and the one or more second records to be communicated to the other devices in the system of devices.

Abstract: A framework for reliably communicating port information in a system of devices is provided. In one embodiment, each device in the system of devices can create a first record that includes port information pertaining to a plurality of ports of the device, where the plurality of ports are usable for communicatively coupling the device to other devices in the system of devices. The device can further receive, from the other devices in the system of devices, one or more second records including port information pertaining to the ports of the other devices, and can store the first record and the one or more second records in a data store maintained locally on the device. The device can then forward copies of the first record and the one or more second records out of each of the plurality of ports, thereby causing the copies of the first record and the one or more second records to be communicated to the other devices in the system of devices.

Abstract: In embodiments according to the present invention an encryption switch is used to authorize access to LUNs from client VMs present in the cloud provider network. The encryption switch includes responder side software for an authentication protocol and an agent in the client VM includes the requestor side of the authentication protocol. The certificate of the client is securely provided to the encryption switch, which associates the client VM with the LUN. The client private key is securely provided to the client VM, which retains it only non-persistently. The client VM requests LUN access and performs an authentication handshake with the encryption switch. If successful the client VM than has access to the LUN. As the original certificate is linked to the client, if the client is itself a VM, should the client be moved to a different host, the certificate moves with it and LUN accessibility is maintained.

Abstract: An encryption switch which is used in a cloud environment to secure data on the LUNs used by the clients. A client provides a certificate to the cloud service. The encryption switch develops a cloud crypto domain (CCD) as a secure area, with the data at rest on the LUNs encrypted. The encryption switch develops a master key for client use in the CCD, which is provided to the client encrypted by the client's public key. Data encryption keys (DEKs) are created for each LUN and provided to the client. The DEKs are stored in a key vault by the client for use if needed. The cloud service provisions a client VM to be used with the encrypted LUN and develops a nexus between the LUN and the client VM for the encryption switch to use in data operations. The client communicates through the client VM to access the LUN.

Abstract: An encryption switch which is used in a cloud environment to secure data on the LUNs used by the clients. A client provides a certificate to the cloud service. The encryption switch develops a cloud crypto domain (CCD) as a secure area, with the data at rest on the LUNs encrypted. The encryption switch develops a master key for client use in the CCD, which is provided to the client encrypted by the client's public key. Data encryption keys (DEKs) are created for each LUN and provided to the client. The DEKs are stored in a key vault by the client for use if needed. The cloud service provisions a client VM to be used with the encrypted LUN and develops a nexus between the LUN and the client VM for the encryption switch to use in data operations. The client communicates through the client VM to access the LUN.

Abstract: In embodiments according to the present invention an encryption switch is used to authorize access to LUNs from client VMs present in the cloud provider network. The encryption switch includes responder side software for an authentication protocol and an agent in the client VM includes the requestor side of the authentication protocol. The certificate of the client is securely provided to the encryption switch, which associates the client VM with the LUN. The client private key is securely provided to the client VM, which retains it only non-persistently. The client VM requests LUN access and performs an authentication handshake with the encryption switch. If successful the client VM than has access to the LUN. As the original certificate is linked to the client, if the client is itself a VM, should the client be moved to a different host, the certificate moves with it and LUN accessibility is maintained.

Abstract: A fabric driver on a host system connected to a fabric may include an API for an administration application to query and obtain a list of devices connected to a fabric host adapter port(s). The fabric driver may execute this query and obtain the list of devices by querying a fabric name server. One or more direct attach devices may also be discovered. For direct attach devices, like private loop topologies, operating system device nodes may be created during driver attach. However, for fabric topologies the fabric driver provides a list of devices visible through the fabric host adapter port by querying the fabric name server and supplies this list to the administration application in response to the administration application's request. A user may then select devices from this list to be onlined. A dynamic persistent repository may be maintained of devices onlined using this on-demand node creation process.

Abstract: An application may query a fabric driver to obtain a list of devices visible through a fabric host adapter port(s). The fabric driver may obtain the list of devices by querying a fabric name server. For direct attach devices, device nodes may be created during driver attach. However, for fabric topologies the fabric driver is queried on-demand to provide a list of devices visible through the fabric host adapter port(s). A user (e.g. through an application) may then select devices from this list to be onlined. An indication of the fabric devices that are online for the host system are stored in a persistent repository. Following a reboot of the host system, the persistent repository may be read to determine which fabric devices were online prior to the reboot. The fabric devices that were online prior to the reboot to be may again be brought online for the host system.

Abstract: An application may query a fabric driver to obtain a list of devices visible through a fabric host adapter port(s). The fabric driver may obtain the list of devices by querying a fabric name server. For direct attach devices, device nodes may be created during driver attach. However, for fabric topologies the fabric driver is queried on-demand to provide a list of devices visible through the fabric host adapter port(s). A user (e.g. through an application) may then select devices from this list to be onlined. An indication of the fabric devices that are online for the host system are stored in a persistent repository. Following a reboot of the host system, the persistent repository may be read to determine which fabric devices were online prior to the reboot. The fabric devices that were online prior to the reboot to be may again be brought online for the host system.

Abstract: A fabric driver on a host system connected to a fabric may include an API for an administration application to query and obtain a list of devices connected to a fabric host adapter port(s). The fabric driver may execute this query and obtain the list of devices by querying a fabric name server. One or more direct attach devices may also be discovered. For direct attach devices, like private loop topologies, operating system device nodes may be created during driver attach. However, for fabric topologies the fabric driver provides a list of devices visible through the fabric host adapter port by querying the fabric name server and supplies this list to the administration application in response to the administration application's request. A user may then select devices from this list to be onlined. A dynamic persistent repository may be maintained of devices onlined using this on-demand node creation process.