Goten: GPU-Outsourcing Trusted Execution of Neural Network Training and Prediction
Authors: Lucien K.L. Ng
Sherman S.M. Chow
Anna P.Y. Woo
Donald P. H. Wong
Yongjun Zhao
Venue:  (2020)
Keywords: machine learning
security
privacy
TEE
trusted processors
Intel SGX
GPU
high-performance

Abstract: Before we saw worldwide collaborative efforts in training machine-learning models or widespread deployments of prediction-as-a-service, we need to devise an efﬁcient privacy-preserving mechanism which guarantees the privacy of all stakeholders (data contributors, model owner, and queriers). Slaom (ICLR ’19) preserves privacy only for prediction by leveraging both trusted environment (e.g., Intel SGX) and untrusted GPU. The challenges for enabling private training are explicitly left open – its pre-computation technique does not hide the model weights and fails to support dynamic quantization corresponding to the large changes in weight magnitudes during training. Moreover, it is not a truly outsourcing solution since (ofﬂine) pre-computation for a job takes as much time as computing the job locally by SGX, i.e., it only works before all pre-computations are exhausted.

We propose Goten, a privacy-preserving framework supporting both training and prediction. We tackle all the above challenges by proposing a secure outsourcing protocol which 1) supports dynamic quantization, 2) hides the model weight from GPU, and 3) performs better than a pure-SGX solution even if we perform the precomputation online. Our solution leverages a non-colluding assumption which is often employed by cryptographic solutions aiming for practical efﬁciency (IEEE SP ’13, Usenix Security ’17, PoPETs ’19). We use three servers, which can be reduced to two if the pre-computation is done ofﬂine. Furthermore, we implement our tailor-made memory-aware measures for minimizing the overhead when the SGX memory limit is exceeded (cf., EuroSys ’17, Usenix ATC ’19). Compared to a pure-SGX solution, our experiments show that Goten can speed up linear-layer computations in VGG up to 40×, and overall speed up by 8.64× on VGG11.

Under review as a conference paper at ICLR 2020
GOTEN: GPU-OUTSOURCING TRUSTED EXECUTION OF NEURAL NETWORK TRAINING AND PREDICTION
Anonymous authors Paper under double-blind review
ABSTRACT
Before worldwide collaborative efforts in training machine-learning mod- els or widespread deployments of rediitionnas-a-seeee we need to devise an efficient privacy-pre preeeeviig mechanism which guarantees the privacy of all stake- holders (data contributors, model owner, and queriers). Slalom (ICLR '19) pre- serves privacy only for prediction by leveraging both trusted environment (e.g.. In- tel SGX) and untrusted GPU. The challenges for enabling private training are ex- plicitly left open its pre- crepommputaiion technique does not hide the model weights and fails to support dynamic quantization corresponding to the large changes in weight magnitudes during training. Moreover, not truly outsourcing solu- tion since (offline) pre-computation for job takes much time as computing the job locally by SGX, i.e., it only works before pre-computations are exhausted.
We propose Goten, privacy-preservee prediction. We tackle all the above challenges by proposing a secure outsourcing protocol which 1) supports dynamic quantization, 2) hides the model weight from GPU, and 3) performs better than a pure-SGx solution even if we perform the pre- computation online. Our solution leverages non-colluding assumption which is often employed by cryptographic solutions aiming for practical efficiency (IEEE SP 13, Usenix Security '17, PoPETs '19). We use three servers, which be reduced to two the pre-computation is done offline. Furthermore, we implement our tailor-made memory-aware measures for minimizing the overhead when the SGX memory limit is exceeded (cf., EuroSys '17, Usenix ATC '19). Compared to pure-SGX solution, our experiments show that Goten can speed up linear-laee computations in VGG up to 40x, and overall speed up by 8.64x on VGGI1.
framework supporting both training and
INTRODUCTION
While deep neural networks (DNN) can produce predictive models with unparalleled performance, its training phase requires enormous data input. A single data owner may not possess enough data to train a good DNN. Multiple data owners, say, financial institutions, may want to collaborate in training DNNs. Yet, they often expected to protect the privacy of the data contributors. This dis- courages any collaborative training over global-scale data that is otherwise promising (Cheng et al.) 2019). Moreover, to perform prediction using trained model, queriers need to submit their own private data (e.g., medical history). Meanwhile, the model owners want to protect the confidentiality of the trained model in the prediction phase as well. The exposure of the (parameters of a) model (to queriers or a third-pan
cloud server) may reveal information about its training data (Fredrik- son et al. 2015), deterring the participation of data contributors. Also, the model itself is of high commercial value. These concerns hinder the deployment of prediction as a service.
increasingly popular approach to ensure privacy is using a trusted execution environment (TEE) (Cheng et al.) 2019 Tramer & Boneh 2019) and in particular, trusted processors, e.g., In- tel Software Guard Extension (SGX), When a data provider sends some private data to a server equipped with SGX, it can initialize cated way and subsequently operate on them. Even the untrusted server, who physically owns the enclave, cannot read or tamper the data inside the enclave. This paper investigates the following questions: Can we support DNN training (and prediction) by using SGX and untrusted GPU while still preserving the privacy of all stakeholder? If so, how much speedup do we gain by using GPU?
enclave to receive the data in confidential and authenti-

---

Under review as a conference paper at ICLR 2020
1.1 OUR BASELINE APPROACH: CAFFESCONE
Arnautov et al. 2 propose SCONE, secure container mechanism that allows developers to directly run applications in an SGX enclave with almost zero code c We combine SCONE with Caffe (Tia et al. ) an efficient open-source DNN framework, build our baseline privacy- preserving DNN framework - CaffeSCONE. Beyond demonstrating what one can get by applying a generic solution that uses SGX (SCONE) for training (not supported by Slalom), our CaffeSCONE implementation enables more benchmarking for insight in possible improvements, which are even- uaally achieved by our main result (hence further optimizing it not our goal). For one, we show (in Section (422) that this baseline approach greatly suffers when the enclave's ' memory limit is reached. Specifically, it invokes native paging mechanism to swap data in and out, which further requires en/decryption. Also, we found that using more threads and cores cannot improve performance.
1.2 OUR PROPOSED FRAMEWORK: GOTEN
Secure Outsourcing GPU By using SGX solely, CaffeSCONE is already orders of magni- tude faster than the state-of-the-art cryptographic solutions (SecureML (Mohassel & Zhang 2017).
MiniONN (Liu al. 2017), Gazelle (Juvekar al. 2018), and DINN (Bourse et al. 2018)) while only SecureML supports training). Nevertheless, in general, CPU (with or without SGX) is not optimized for costly operations in DNN such as matrix multiplication. Using specialized hardware such as GPU for such computation is common practice. However, SGX-enclaves cannot directly leverage GPU because its security guarantee is bounded within the CPU and fixed memory. It is unclear how CaffeSCONE (and other works including TensorSCONE, Chiron (Hunt et al. 20188) and MLCapsule (Hanzlik et al. 2018)) can leverage GPU without trusting (or losing privacy).
The SGX+GPU mode of our framework, which we call Goten, enables an even more efficient ap- proach. To the best of our knowledge, no existing work ever explored this possibility on privacy- preserving training. A recent work Slalom (Tramèr & Bonch 2019) also uses GPU but it only offers prediction privacy. We follow the common practice in the cryptographic privacy-preserving training literature (SecureML, its subsequent work (Wagh et al. 2019), and other prior works (Niko- laenko et al. b)) which employ non-colluding servers. Specifically, our framework uses three non-colluding GPU-enabled servers, two of them with a trusted processor. This setup appears to be necessary when the primary goal is to achieve privacy without heavyweight cryptographic tools. In practice, one can employ cloud service providers who are market competitors and value their reputations, or involve a government agency especially in healthcare/finanee settings.
Taking Full Advantage of the Servers We choose to exploit the server-aided setting fully and em- ploy one additional server when compared with SecureML. What this server does is to "bootstrap" the triplets for secret sharing (Beaver 1991) across the two servers, which SecureML assumes such bootstrap has been done in advance in offline phase. Goten thus achieves higher throughput without worrying that the offline preparation will be "exhausted" when the demand reaches its peak, which is also hidden problem not addressed by Slalom. It also means Goten provides "true" outsourcing solution the time needed for securely outsourcing the job to the untrusted GPU is less than that for computing the job locally by the SGX plus any time needed for pre-computation. If desired, one may easily adapt our framework back to the two-server setting. (See Section 2.2
Dynamic Quantization Scheme We quantize the neural network parameters to fixed-point num- ber format for efficient cryptographic operations (cf., static quantization in Slalom). This process needs to be implemented carefully for the following reasons. First, the many matrix multiplications in neural network may scale up the output values quickly, easily exceeding the numeric limit of the data type. Second, there are functions that map values to small interval (e.g., softmax() and sigmoid()) which require high precision. To avoid these potential accuracy problems, we developed a data-rype type conversion scheme, again, for enjoying "the best of both worlds," i.e., the benefit of ac- curate floating-pole maaing operations on trusted processors and efficient fixed-point operations on GPUs. Our experiment (Section 4 confirms that our framework preserves high accuracy.
'TensorSCONE: Kunkel et al. 2019) employed SCONE with TensorFlow (Abadi et al. 2016al (a DNN
framework like Caffe usedy; unfortunately, is not open source.
2

---

Under review as a conference paper at ICLR 2020
Memory-aware Implementation A naive solution of overcoming the memory limit of SGX en- claves to rely on the Linux's 's paging provided by Intel SGX SDK. However, it imposes much per- formance overhead ranging from 10x to 1000 comparing to unprotected programs (Armauoov eet al. 2016) for exiting the enclave mode and switching back after processing the untrusted mem- ory. Hence, in our framework, we take extra measures to reduce the memory footprints by looking into our specific DNN operations and handle any needed memory swapping by the enclave itself.
1.3 TECHNICAL CONTRIBUTIONS
Using both SGX and GPU for srivacy-preeeringg training may sound straightforward. but we stress that we tackled number of issues. To better understand the obstacles, here revisit how Slalom performs crivacy-rreserving prediction and why it fails to support training. The core idea of Slalom can be described in simple terms: first apply static quantization on an input æ to be protected, then outsource the job of computing f(x + r) to GPU by hiding x with a blinding factor r in Eg (where q is large prime). Since it focuses on linear layers, f is linear and hence rr f(x) ( f(r). When SGX gets back f(z + r), it performs "unblinding" using f(r and obtains f far) For such outsourcing to be possible, f(r) should be precomputed. As simple as it may seem, Slalom needs to minimize the following three kinds of overheads - (i) computations over 2, performed by the untrusted GPU for the security of the blinding trick, (ii) the communication between TEE and the untrusted GPU, and (iii) loading the precomputed unblinding factor frr to TEE. Looking ahead, our outsourcing protocol faces even greater challenges regarding (i) and (ii). Slalom addresses (ii) by assumption it was done in an offline stage before the TEE needs to process any query. If we just ask the SGX to compute it, computing (r) is of the same complexity as f(x). Another way is to load them on-spot. It is again subjected to the memory limit and incurs the unwanted communication overhead. More importantly, it is insecure to ask the untrusted environment to compute f(r).
There are five conceptual challenges remain unsolved by Slalom regarding training. 1) Dynamic quantization: Slalom explicitly left it as one of the open challenges. 2) DNN weights are fixed at inference time, but it is not for training. This further complicates the dynamic quantization issue since the weights fluctuate. 3) The pre-computation technique does not apply for training. In more details, the training function is actually parameterized by a publicly- multiples z with W. Moreover, the weight changes after (a batch of) operations are processed which makes fw(r) useless for a changing weight W 4) It is now apparent that Slalom does not protect the model weight W, which should be protected in private training (and "more private" prediction). This also one of the open challenges left explicitly by Slalom. 5) The last one is a challenge unique to solution in addressing the other challenges. In their usage, TEE and GPU are co- located. However, in our settings, we need to propose an outsourcing solution which is efficient enough even are subjected to even higher communication overhead between the servers.
weight W, i.e., fw (x)
Goten is the first framework that preserve the privacy of not only the prediction queries but the training data and model parameters with GPU and trusted environment. Our work achieves the highest efficiency of training and prediction in such privacy setting. This is the also first work which performs extensive experimental investigations of this possibility. Concretely, in our case study on VGG, we can speed up a linear layers up to 40x, and improve the performance of VGG11 by 8. 8.64x.
2 SYSTEM MODEL
There are mutually untrusted data providers who want to jointly train DNN using their disjoint training data, but they are not willing to reveal their private data to others. They have already agreed on specific DNN architecture. The corresponding code for the training algorithm is assumed to be genuine after manual or automated verification (Sinha et al.) 2016). After training, a querier can obtain prediction results from the resulting DNN and the results are only revealed the querier.
2.1 CAFFESCONE
Fig. la shows the system architecture of CaffeSCONE. The server S initializes an enclave E with the specified training and prediction algorithms. The data providers C2 ..... attest E and verify that it is running the intended algorithms. Then they establish secure channel with E to send it
3

---

Under review as a conference paper at ICLR 2020
Providers
Server
SGX
TrainingPrrecccte
GPU
GPU3
8
Server
SGX Enclave
Providers
(a) CaffeSCONE
(b) Goten
Figure 1: System Architecture of CaffeSCONE and Goten
their training data. E then trains the DNN with the attested algorithm. Once training is done, C₁ sends queries to E, which then computes the prediction according to the trained model parameters.
2.2 GOTEN
Goten uses GPU to accelerate the computations the fully-connected and convolutional layers. We introduce two additional non-colluding servers. Fig. illustrates the system architecture.
Servers So, S1, and S₂ are equipped with GPU and SGX-enabled processor. So and S₁ initialize Eo and E₁ respectively. All the enclaves attested by the other enclave and data providers, then secure channels are built. Su and S1 take care of DNN computations. S2 provides multiplication triplets for linear computation (independent of the model parameters the training/prediction data).
The training and prediction phases are similar to those in (pure-SGX) CaffeSCONE but with two important differences. To avoid cumbersome data transfer between the servers, data providers only send their data to Es. which is then responsible for forwarding to other enclaves. We also design new outsourcing protocol (from SGX GPU) that significantly changes the way of matrix multipli- cation. We leverage the best of SGX (deriving randomness) and GPU (for batch processing), While we still employ known trick that protects the secret using additive secret sharing, existing designs assume general scenario and do not consider the characteristics of SGX and GPU.
Our goal is to ensure that adversary cannot learn anything other than the DNN specification and the data of compromised parties. In particular, the model parameters remain private. Any attacker that observes the communication between servers cannot compromise privacy. An attacker can compromise any subset of the data providers and at most one of the servers, i.e., two servers cannot collude with each other. We allow the attacker to control all the software (including operating system and hypervisor) of the server, but assume it cannot launch any hardware attack SGX. Denial- of-service or side-channel attacks are also out of the scope. See Appendix for further discussions.
CaffeSCONE further guarantees the correctness of both training and prediction. Goten does not provide it as we present due to page limitation, but we can resort to the trick used by Slalom.
Reducing Non-colluding Servers Our design can be easily modified use merely servers with some preparation. Looking ahead, the duty of S2 is to produce two random matrices and the product = u v, and distribute these matrices to Eg and Ej. These enclaves can instead prepare u, v, and by themselves, S2 is longer needed. Similar tricks also used by SecureML and MiniONN. Since matrix computation enclaves is slower than that GPU, Es and Ej should pre-compute these matrices before the training/prediction process prevent stalling the GPU. Additional storage and preparation are required for removing S2.
Moreover, the third server can also be group of triplet providers which provide triplets in turns. In this case, these providers can amortize the computation requirement so they are not necessarily equipped with expensive GPUs and well-connected with the first two servers.

---

Under review as a conference paper at ICLR 2020
3 THE DESIGN OF GOTEN
3.1 HIGH-LEVEL. IDEA
Matrix multiplication and convolution occupy 2 90% of computation time (see Appendix A.3).
is well known that GPU can speed up the computation of linear transformation and convolution by orders of magnitude. We thus outsource linear operations to GPU, and prevent leaking information to the hosts of (untrusted) GPU via additive secret sharing. Still, CPU needs to convert data of linear layers into the format used by secret sharing, and then convert the result from GPU back into the normal format for non-linear layers. We call these procedures pre-processing and post-procces post-processing of outsourcing linear operations. If they are not handled properly, the processing time could offset the performance gained from GPU. In the following, we introduce our tricks for reducing the run-time of pre/post-processing and present our modified secret-sharing protocol that improves performance.
Moreover, not only the computation in linear layers but also heads due to paging. We apply memory-aware measures to reduce such overhead. The high-level idea is let the enclave specifies the piece of memory going to use, read and write the memory without triggering Linux's 's inefficient paging. This approach is also vital for the performance.
suffer from over-
3.2 GPU-POWERED OPERATIONS VIA OUR OUTSOURCING PROTOCOL
A trivial approach to protect two operands a and via SGX is to encrypt them to the enclave and ask it to multiply them directly. Yet, it cannot leverage the batch- processing advantage of GPU and is inefficient for large scale computation. We aim to design a protocol that leverages the SGX enclave to secure the unprotected computation environment of GPU, without the enclave performing any expensive decryption beyond the bare minimum, iee., two decryptions (for the two operands).
We start with the "bare minimum" operations which let the two enclaves Eu and E1 know the secrets a and b. The core design principle is to let the enclaves do what they are good for, ie., generating cryptographic randomness and using them one-time-pad some values. With the non-colluding assumption (required by the original protocol (Beaver) 1991)), we choose to fully exploit it and
introduce one additional server to establish the triplets involved in computing u @ v 2. The triplets generation can be performed by "the initiating client" offline in existing protocols (Mohassel
& Zhang 2017. Liu et al. 2017), thus, this server can be removed as discussed in Section 2.2
@ b. @ can be convolution (so a and are tensors) or matrix multiplication (for matrices and b). Another important usage of enclaves is to store the same seed for deriving the random factors across all the servers. This trick forms confidential channel between two servers very efficiently without AES or public-key encryption. For example, Sy sends in the form of Rand(r:)) to Eg and Eg via insecure channels, which can be computed quickly. In other words, all instances of - E, var" in the figure refer to loading the variable(s) var to E; directly without encryption.
Fig. describes our protocol for outsourcing linear operation of
The steps in line 3 of Fig. appear to be working on many more values than the trivial approach of computing @ b. Our experiments in Section 4.2 confirms that the performance gain can be as large as 40x. Below, we discuss the changes we made over the original triplet- based protocol.
Parallelizable Pre-Processing without Communication Our protocol makes further improve- ments/refinements over the existing one (in Appendix(A.4p. Our goal is to compute a&b by operating over (e, f), masked version (a, b). In the original protocol, the shares ((a)o, o, (b)o) and ((a) 1, (b) from the two parties (Sp and S₁ here) must be masked independently by the corresponding one-time pads ((u)o. (o)o) and ((u)1, (v)1). After this step, they must interact to produce e and f.
In our protocol, both enclaves know and b, they can the same seed derive the same time pads u and u (which is in, say, ) and obtain e and ff without any interaction. This saves half of the pre/post-processing and communication cost, and makes e and f no longer dependent on (a); and (b),. All the steps in line 3 of Fig. 2 thus be done in parallel. We then further reduce the run-time time of such pre-pue processing roughly by 3/4 i.e., it is 1/4 of the original. Moreover, Ep and E, no longer need to interact until the last step for result construction, they then work in parallel.
5

---

Under review as a conference paper at ICLR 2020
Secure Outsourcing of Linear Operation @ to GPU
1: S2 12:u Rrnd(ru), u + Rand(ru), = u & v, (2)1 f 2 Rand(r:))
2: S2 + Eo, (2)1
for i = 0, in parallel:
3: E, (a)x - Gen ra), (b), +- Gem,(b, = (r)n f = -b Rand(r=),
(2)0 + Rand(r=),
Rand(rko): Ki Rand(re,) in parallel;
4: E. S. (a) (b)ss e, Ki-i-
5: E. 1. (a): f (b), 0 --0--
6: S. + : = q Ki-1-i
endfor
7: En : c co + (Co + k1 + (2)0 + (z)
E:: a (C1+ Ka-1) + (z)a (2)1
Figure 2: Protocol for Outsourcing Linear Operation
Reducing Run-time of Share Reconstruction Unlike the original standalone protocol where each party only needs to learn share (c), of c but not c @ b itself, it is necessary for enclaves to know e because they need to perform the succeeding non-linear operations of non-linear layers. (In some existing protocols, is actually recovered "implicitly" via cryptographic means, say. within a garbled circuit.) naïve way is to let S: encrypt their respective shares to the other enclave Ei Again, its own share e; into a ciphertext Ci-; for Ei_ via the key Ki-,1- derived from the seed. In total, reduce weeppost-pocessing time by roughly 87.5% and halve the communication cost.
the common seed to form secure channel which lets S; one- mee-tme--pe -add
Performance Gain for Linear Layers Our outsoureing protocol, while optimized, still imposes overhead in pre/post-pres propesssnn and communication between the servers. It is instructive to confirm how much gain. Beyond the obvious reliance the relative performance of the GPU, it turns out to be crucially relying on the shapes of the input and weight (specifically, arithmetic intensity (cud) 2019h. Appendix D gives the theoretical analysis. Fig. 5a shows convolution gains speed-up as expected when paging overhead low.
3.3 DATA TYPES AND DYNAMIC QUANTIZATION
The triplet trick we used operates over fixed-point numbers in Eg, while common neural network framework operates over floating- point numbers ("floats"). Therefore, Goten has accommodate the fixedpooin setting so that it can attain superior performance as if using floats.
The Choice of Zy GPU slow in modular arithmetic, off-the-shield optimized libraries do not support them. To work Z. integers, we thus put them floats Slalom (Trmmrr & Boneh 2019). This leaves us only 53 significant bits plus a sign bit to represent the integers in linear layers (where the rest of (64 53- 1) exponent bits are 0).
To make sure the result of the matrix multiplication or tensor convolution a does not overflow, we need g²k 253 where & the number of columns of matrix a k Cin -w-fuu in convolution.
To avoid overflow in Zap- should be large; but predicting the value of & beforehand is hard. We thus resort to the heuristics of testing different choices of q over common VGG networks. Based experiments, 221 - 9 is the largest value that does not overflow in almost all (i= 100%) cases.
Challenges Quantization To compute x &r w with seating-point multiplication Gt, we need a quantization scheme convert floats to fixed-point numbers and vice versa for linear layers. We first quantize x and w into xQ = (z; (x)) and wQ = Q (w Ow), where 6, and 6n are the corresponding quantization parameters. We then fixed-point multiplication Oz, compute yQ xQ Ez, wQ- and derive the result by y Q 0z, Ow.) Br w.

---

Under review as a conference paper at ICLR 2020
Slalom only supports prediction. Knowing the model, it knows the value distribution of model parameters. It can then derive the distribution of the input, output, and intermediate values. Picking static scaling parameter that minimizes the error in prediction is thus relatively easy. In Slalom, Q(: 0) is always parameterized by 0 = 2 for all data (inputs and weights) and every computation. In short, static quantization may not pose a big problem in a prediction-only framework.
Dynamic Quantization for Training Stalom clearly states that quantization for training is a chal- lenging problem. For training, the range of gradient of the weight may change. hence the output, and the input of the successive layer. Knowing the value distribution prior to training is hard, so we cannot determine what parameters for Q good enough to support training.
Beyond what Slalom did, we need dynamic quantization for training, meaning that it can adapt the change on the distribution of the model parameters, and hence the intermediate value and gradient. The (de- qleantiuazizniinn process has to be efficient since it is part of the GPU APPUppoered scheme. An inefficient scheme would reduce or even offset the performance gain.
of our
Our Choice SWALP (Yang et al. 2019) is training scheme which works in a low-precision setting. The forward and backward computation are performed in low-precision ixed-point, but the weights are stored and updated in floats with high-precision.
Suppose bit the number of bits available for the low-precision computation, and the default value is 8. For both the weight and the input, SWALP first finds out the maximum absolute value, and then calculates its exponent in the format of bits, i.e., compute exp = [(logg max o abs) ( d. Then, it scales up all the values by that exponent so that the new maximum values are roughly aligned to 2bit 2, rounds them up stochastically (Gupta et al. 2015), and clips all the value to [-2bit 2,
- 1], i.e., dataq = Q data, exp) clip data 2 exp+ After the computation, the resulting values are scaled down accordingly, i.e., YQ 2mx,, txxp_ b-b
Based on the existing SWALP experiment, its accuracy drops by less than 1% when compared to training in full-precision for VGG16, and the operands are only of 8 bits. Also, finding the maximum absolute value and scaling up and down the values only requires 3 linear scans. The scaling can be fused with other dynamic because it samples the maximum value of the weight and input every iteration. Section 4.2 shows that with this quantization scheme, Goten can train VGG11 attain high accuracy efficiently.
too. Finally, this scheme matches with our expectation that is
3.4 MEMORY-AWARE MEASURES
When the allocated memory in the enclave exceeds the 128MB limit, it incurs excessive overhead. Our memory-aware mechanism handles most operations in the enclave to mediate this problem.
A naïve solution is Linux's paging, which is provided by Intel SGX SDK. However, native paging is known to be inefficient. As reported in SCONE (Arnautov et al. 2016). memory access can be 10 x000 slower compared plaintext setting. Eleos (Orenbach et al. 2017) explains that triggering SGX native paging would make the CPU core exit the enclave mode, which is time- consuming. The more memory allocated, the more frequent such expensive operations are invoked.
To prevent these expensive operations, our memory-aware measures restrict the memory usage of the computations in SGX to minímize the chance of native paging. When Goten needs to allocate memory more than 128MB, it would directly encrypt the chunk of memory and evict it to the un- trusted zone, which, unlike the native paging, does not leave the enclave mode. When it needs to use memory that is not in the enclave, it loads the chunk of memory into the enclave and decrypts it. Section 4.2 shows that our mechanism speeds up the computation of non-linear layers by 8.72x.
For operations inside the enclave, we aim to minimize the memory access across the border be- tween the trusted/untrusted zone. In particular, we fuse together operations that use the same set of memory, and independently handle batches in non-linear layers prevent excessive use of memory.
Eleos (Orenbach et al. 2017) is also another mechanism for mediating page-fault overhead. allows the program to handle faul-fault without exiting the enclave. COSMIX (Orenbach et al. 2019) further automates the instrument for this haaiingg mechanism. However, its implementation was released less than month, so we have not compared integrated with it.
7

---

Under review as a conference paper at ICLR 2020
4 EMPIRICAL EVALUATION
For Goten, its SGX part is written in C++ and compiled with Intel SGX SDK 2.3.101.50122 and we use Pytorch 1.2 (pyt 2019) on Python 3.6.9 to marshal network communication and operation on GPU, which run with CUDA 9.0. The C++ code is compiled by GCC 7.4. Also, reuse some code of Slalom (Tramèr & Boneh 2019), including their code of crypetographiiciallysssoo random number generation and encryption/deerypioon, and their OS-call-free version of Eigen, linear-algebra library. All the experiments were conducted for at least 5 times, and we report the average of the results. We uploaded our source code https://github.com https//ggghhbboooomoogotttt////e goteneetennttmnttenn
4.1 SETUP
SGX's Simulation Mode and Hardware Mode Only limited models of Intel CPU are powered by SGX, which can run in the regular hardware mode and enjoy the SGX protection. Intel SGX SDK also provides simulation mode for testing purpose. Its code compilation is almost the same as hardware mode except that i) the program is not protected by SGX, which is fine for our pur- pose since the DNN training and prediction algorithms publicty known, and îï) it does not encryption, which does not affect our experimental timing figures because we handle most of our secret values via one-time pads. In particular, a ciphertext produced by one-time pad is long as the plaintext it is encrypting, thus, it does not affect the most important overhead - paging.
In term of performance, the largest difference between these two mode is related paging. When the allocated memory in enclaves exceeds its physical limit, the enclaves in hardware mode may suffer much larger overhead compare to native programs. In simulation mode, the overhead is little. Programs in hardware mode has negligible overhead as long as no paging is triggered. Specifically, according to the experimental results in Privado (Tople et al.) 2018). the neural networks which do not trigger page-fault do not have any performance overhead.
Experiemental Environment for CaffeSCONE and Goten We evaluate the performance of CaffeSCONE on a computer (which supports SGX hardware mode) equipped with Intel i7-7700 Kaby Lake Quad-cores 4.3GHz CPU and 16GB RAM, using Ubuntu 18.04. For reproducibility and for the ease of setting up the experiment, we evaluate the performance Goten on 3 Google Cloud VMs. We specify all VMs to equip CPU with Sky Lake, the latest microarchitecture that can be used for Google Cloud's VM. Unfortunately, all CPUs on Google VMs do not support Intel SGX's hardware mode. Also, all these machines are equipped with 32GB RAM and a Nvidia V V000 GPU.
Calibration on Experiment Results Given the constraint, our experiments on the environment we used for Goten would underestimate the performance of programs running in SGX simulation mode because the CPUs have lower clock rate and older microarchitecture compared to Intel i7-7700.
To make the comparison between these two frameworks fair, we calibrate Goten's CPU runtime to CaffeSCONE's CPU runtime. We measure the runtime of the non-linear layers in the two afore- mentioned environments. We found that the environment we used for Goten would overestimate the runtime on CaffeSCONE's CPU. Hence, we decide to scale down the runtime of most time- consuming non-linear layers in Goten according to the data collected. The scaling factor for ReLU is 0.96, for Batchnorm is 0.56, for Maxpool is 0.85.
Since the runtime in linear layers is related to the transfer between CPU and GPU and over the network, it is hard to calibrate the runtime of CPU solely. Also, our data showed that the pre/post- processing CPU time is similar across hardware mode and simulation mode. So we do not calibrate the runtime of linear layers. The results in Fig. and Tables I and 2 are calibrated by this method.
Choice of Dataset and Architecture: CIFAR-10 and VGG11 Both of Goten and CaffeSCONE are evaluated on CIFAR-10, 10, a common dataset for benchmarking the accuracy. We pick a VGG architecture with 11 layers and batch normalization layers because it is a typical DNN that can attain high accuracy on CIFAR-10 10. Also, it is small enough to fit with (the memory limit of) CaffeSCONE.
4.2 PERFORMANCE ON VGG11
8

---

Under review as a conference paper at ICLR 2020
size
40
Batch size HW Made
2.30
Butch size 125, Sim. Mode
Batch size 512, Sint Mode
0.50
26
Texe
2.75
18
10
5.05
CanteCCONE (Berch Stee
Cotan (tates Size
2.50
100020
6)
Figure 3: Training Throughput of CaffeSCONE
Figure 4: Accuracy Convergence in VGGI1
Table 1: Time Distribution on Linear/Non-linedt Layers
Linear Layers
Non-linear Layers
Total
Time (ms)
Proportion
Time (ms)
Proportion
Time (ms)
CaffeSCONE (BS=128)
9243
57.7%
6774
42.3%
16017
Goten (BS=512)
4306
58.1%
3106
41.9%
7412
Speedup
8.59x
8.72x
8.64x
Throughput of CaffeSCONE First, we show the training throughput of CaffeSCONE in Fig. by which we emphasize that using more cores on CPU cannot improve the performance of such pure-SGX approach. Moreover, we benchmark the throughput with batch sizes of 128 (a common setting in plaintext setting) and 512 (the setting we adopted for Goten). We confirmed that the former one has better performance for VGG11 in CaffeScone, and thus we adopt it in the later experiments. Note that we adopt batch size 512 in Goten because with which Goten has better performance.
Training Throughput of Goten Table illustrates the speedup of Goten compared to CaffeSCONE in the training phase. For the experimental settings, Goten with simulation mode on Google VMs and employed memory-aware measures to reduce the overhead of paging. More- over, rescale the running time non-linear layer, which bases on the running time with the real SGX setting, i.e., the hardware mode on the experimental machine equipped with Intel i7-7700.
According the experimental results on non-linear layers, programs running with the real setting are faster than those on Google VMs. Hence, we believe that linear layers in the real setting are also faster as both kinds of layers have similar operation and (linear) access patterns.
In conclusion, Table I shows that Goten outperforms CaffeSCONE by about 8x on linear layers and non-linear layers VGG11 and by 8.6x on the whole network.
Convergence on Quantized Neural Networks Furthermore, Fig demonstrates how the perfor- mance speedup leads to higher convergence rate. Since the training methods for CaffeSCONE and Goten are different: the former adopts the most common approach, which uses plain single-precision precision floats, whereas the latter one employs the dynamic quantization scheme SWALP (in Section 3.3) natural to wonder whether Goten can attain a higher convergence rate. Our experimenta result confirmative. We record the converge trajectory of both training methods, which was captured in an unprotected setting on GPU, and then rescale the time axis according to the timing from Table The results show that Goten can converge much faster.
To better emphasize our advantage on the convergence rate, Table 2 lists the speedup (at different levels of accuracy). which ranges from 4.93x to 11.78x. shows our quantization scheme does
Table Accuracy vs. Speedup using GPU-powered Scheme
Accuracy
0.90
0.89
0.88
0.87
0.86
0.85
Speedup
4.93
7.28
7.31
7.31
11.78

---

Under review as a conference paper at ICLR 2020
not have a significant impact training, and it attains high accuracy in a shorter time. However, Goten still cannot attain 0.9 accuracy after 200 epochs, while CaffeSCONE can.
4000
20.0
Arithmeee Indenally
Arttimedi: Intersily
3500
(ight)
17,5
16000
Speed (righ)
1400
35
12000
30
2000
10.0
1500
7.5
8000
15
1000
5.0
4000
10
530
2.5
012.4.33 137
122 st an
mi fat
the aot 4j
e12 t2t 201-
let erz mz 4
(a az W2..)
182 022.6433 3,30
e12 to
B 22.28, 18t
a1 286
a12 stz 4)
a12 32..8. $12
82 as
shape
shap
(a) With Low Paging Overhead
(b) SGX Hardware Mode
Figure 5: Speedup vs. Arith. Intensity of GPU-powered Conv. of Shape (B, Couts Cin Iiw)
bieeo-benchmark::: Speedup of Our GPU Outsoureing Protocol our main contribution is the performance speedup linear layers, we further isolate the performance gain of them. Fig. shows the speedup and arithmetic intensity, which is explained Appendix [D] of each convolution layer presented in VGG with CIFAR-10. The shapes correspond to the batch size, the number of input channels, the number output channels, the height and width of input images. The filter size of all layers is 3 3. The results illustrate that Goten most beneficial to neural networks with high- aaritheeeiiiiitenniitt linear layers.
Fig. 5a shows the result in simulation, where paging overhead is negligible as explained. The result confirms with our analysis in Appendix D the higher arithmetic intensity a convolution layer has, the higher gains of performance. Furthermore, to have performance gain in experimental envi- ronment, the arithmetic intensity should be at least 250. Also, we notice that the layer with image size 2 2 actually has huge performance gain while has a relatively low arithmetic intensity. We suspect that it is because Caffe cannot efficiently handle inputs with a small image size in the CPU.
Fig. 5b shows the estimated speedup in hardware mode, where paging overhead is significant. The estimation is derived from the same setting of Table [ The results show much higher speedup when there are small images and many input channels, and the speedup not proportional the ar- chitecture intensity. We suspect that the convolution's implementation of Caffe amplifies the paging overhead in the above situation.
5 CONCLUSIONS
We proposed new secure neural network framework using trusted processors. Our framework not only outperforms cryptographic solutions by orders magnitude, but also resolved the memory limits issues in the existing state-of-thee of-the-art trusted processors approach (Ohrimenko al.) 2016). We made
training, prediction, and model-outsourcing for very deep neural networks more deployable in practice by advancing the frontier of the SGX-based machine-leaming. For the first time, we can run a very deep neural network, with privacy, but without any memory issue.
REFERENCES
Deep Learning Performance Guide :: Deep Learning SDK Documentation. https://does
Ividia. com http://deeeeeaannn/naaaaaaaa dl http://///.l-pppffrorooooeeaee wttp-aaoooooo----eeeeeeeieeeeeee html 2019. [Online; accessed 13-Sept-2019).
PyTorch. htttp:://pyoorch.orr 2019. [Online; accessed 13-Sept-2008).
10

---

Under review as a conference paper at ICLR 2020
Martín Abadi, Paul Barham, Jianmin Chen, Zhifeng Chen, Andy Davis, Jeffrey Dean, Matthieu Devin, Sanjay Ghemawat, Geoffrey Irving, Michael Isard, Manjunath Kudlur, Josh Levenberg, Rajat Monga, Sherry Moore, Derek Gordon Murray, Benoit Steiner, Paul A. Tucker, Vijay Va- sudevan, Pete Warden, Martin Wicke, Yuan Yu, and Xiaoqiang Zheng. Tensorflow: A system for large-scale machine learning. In OSDI, pp. 265-283. 2016a.
Martín Abadi, Andy Chu, lan J. Goodfellow, H. Brendan McMahan, llya Mironov, Kunal Talwar, and Li Zhang. Deep learning with differential privacy. In CCS, pp. 308-318. ACM, 2016b.
Ahmad Abdelfattah, Azzam Haidar, Stanimire Tomov, and Jack J. Dongarra. Performance, design, and autotuning of batched GEMM for GPUs. In ISC, pp. 21-38, 2016.
Sergei Arnautov, Bohdan Trach, Franz Gregor, Thomas Knauth, André Martin, Christian Priebe, Joshua Lind, Divya Muthukumaran, Dan O' O'Keeffe, Mark Stillwell, David Goltzsche, David M. Eyers, Rüdiger Kapitza, Peter Pietzuch, and Christof Fetzer. SCONE: secure linux containers with intel SGX. In OSDI, pp. 689-703, 2016.
Raad Bahmani, Manuel Barbosa, Ferdinand Brasser, Bernardo Portela, Ahmad-Rezz Sadeghi. Guil- laume Scerri, and Bogdan Warinschi. Secure multiparty computation from SGX. In Financial Crypt., pp. 477-497. 2017.
Donald Beaver. Efficient multiparty protocols using circuit randomization. In CRYPTO, pp. 420- 432, 1991.
Raphael Bost, Raluca Ada Popa, Stephen Tu, and Shafi Goldwasser. Machine learning classification encrypted data. In NDSS, 2015.
Florian Bourse, Michele Minelli, Matthias Minihold, and Pascal Paillier. Fast homomorphic evalu- ation of deep discretized neural networks. In CRYPTO, 2018.
Ferdinand Brasser, Urs Müller, Alexandra Dmitrienko, Kari Kostiainen, Srdjan Capkun, and Ahmad-Reet Sadeghi. Software grand exposure: SGX cache attacks are practical. In USENIX Workshop on Offensive Technologies, 2017.
Stefan Brenner, Colin Wulf, David Goltzsche, Nico Weichbrodt, Matthias Lorenz, Christof Fetzer, Peter R. Pietzuch, and Rüdiger Kapitza. SecureKeeper: Confidential zookeeper using Intel SGX. In Middleware, pp. 14, 2016.
Paul Bunn and Rafail Ostrovsky. Secure two-party k-means clustering. In CCS, pp.
Somnath Chakrabarti.
SGX memory oversubscription, 2017. httpp:/caslab... cat.slabb.all...... cal cal. yaal. pdf]
edd//wowo
Raymond Cheng, Fan Zhang, Jernej Kos, Warren He, Nicholas Hynes, Noah M. Johnson, Ari Juels, Andrew Miller, and Dawn Song. Ekiden: A platform for confidentiality- prreettttpppeeriinggg trustworthy, and performant smart contracts. In IEEE EuroS&P, pp. 185-200, 2019.
Sherman S. M. Chow, Jie-Han Lee, and Lakshminarayanan Subramanian. Two-party computation model for srivacy-preservingg queries over distributed databases. NDSS. ISOC, 2009.
Victor Costan and Srinivas Devadas. Intel SGX explained. Cryptology ePrint 2016/086, 2016.
Daniel Demmler, Thomas Schneider, and Michael Zohner. ABY framework for efficient mixed- protocol secure two-party computation. In NDSS. ISOC, 2015.
Cynthia Dwork. Differential privacy. In ICALP, pp. 1-12. Springer, 2006.
Cynthia Dwork, Krishnaram Kenthapadi, Frank McSherry, Ilya Mironov, and Moni Naor. Our data, ourselves: Privacy via distributed noise generation. In EUROCRYPT, pp. 486-503, Springer, 2006a.
Cynthia Dwork, Frank McSherry, Kobbi Nissim, and Adam D. Smith. Calibrating noise to sensitiv- ity in private data analysis. In TCC, pp. 265-284. Springer, 2006b.
11

---

Under review as a conference paper at ICLR 2020
C. Feng. SGX protected memory limit in SGX, 2017. en Be--u/fooe
https://soffwwre.
60322
Matt Fredrikson, Somesh Jha, and Thomas Ristenpart. Model inversion attacks that exploit confi- dence information and basic countermeasures. In CCS, pp. 1322-1333. ACM, 2015.
Ran Gilad-Bachrach, Nathan Dowlin, Kim Laine, Kristin E. Lauter, Michael Nachrig, and John Wernsing. CryptoNets: Applying neural networks to encrypted data with high throughput and accuracy. In ICML, pp. 201-210, 2016.
Ian Goodfellow, Yoshua Bengio, and Aaron C. Courville. Deep Learning. Adaptive computation and machine learning. MIT Press, 2016. ISBN 178-0-262-03561-2
Suyog Gupta, Ankur Agrawal, Kailash Gopalakrishnan, and Pritish Narayanan. Deep learning with limited numerical precision. In ICML, pp. 1737-1746, 2015. 2015.
Lucjan Hanzlik, Yang Zhang, Kathrin Grosse, Ahmed Salem, Max Augustin, Michael Backes, and Mario Fritz. MLCapsule: Guarded offline deployment of machine learning as service. CoRR abs/1 fbss/108.00m 808900090, 2018.
Danny Harnik and Eliad Tsfadia. Impressions of Intel SGX performance, 2017. https://ling medi um com 2 2iaueRi9uuRi2
Susan Hohenberger and Anna Lysyanskaya. How to securely outsource cryptographic computations. In TCC, pp. 264-282. Springer. 2005.
Tyler Hunt, Congzheng Song, Reza Shokri, Vitaly Shmatikov, and Emmett Witchel. Chiron: Privacy Privacy-preeerving machine learning service. CoRR abs/ 10ss/8803.5 2018.
Intel. Intel Software Guard Extensions (Intel SGX), 2017. ltttps://ootwareee intrerrr.intt.... com/ en ua--us/a ussgg
Geetha Jagannathan and Rebecca N. Wright. Privacy-preserving distributed k-means clustering over arbitrarily partitioned data. In SIGKDD, pp. 593-599, 2005.
Yangqing Jia. Learning Semantic Image Representations at a Large Scale. PhD thesis, University of California, Berkeley, USA, 2014.
Yangqing Jia, Evan Shelhamer, Jeff Donahue, Sergey Karayev, Jonathan Long, Ross B. Girshick, Sergio Guadarrama, and Trevor Darrell. Caffe: Convolutional architecture for fast feature em- bedding. In ACM International Conference on Multimedia, MM, 2014.
Chiraag Juvekar, Vinod Vaikuntanathan, and Anantha Chandrakasan. GAZELLE: A low latency framework for secure neural network inference. In USENIX Security, pp. 1651-1669, 2018.
Alex Krizhevsky, Ilya Sutskever, and Geoffrey Hinton. Imagenet classification with deep convo- lutional neural networks. Commun. ACM, 60(6):84-90, 2017.
Roland Kunkel, Do Le Quoc, Franz Gregor, Sergei Arnautov, Pramod Bhatotia, and Christof Fetzer. Tensorscone: A secure tensorflow framework using intel SGX. CoRR abs/1902.04413, 2019.
Jian Liu, Mika Juuti, Yao Lu, and N. Asokan. Oblivious neural network predictions via MiniONN transformations. In CCS, pp. 619-631. ACM, 2017.
Chi-Keung Luk, Robert Cohn, Robert Muth, Harish Patil, Artur Klauser, Geoff Lowney, Steven Wallace, Vijay Janapa Reddi, and Kim Hazelwood. Pin: building eustomized program analysis tools with dynamic instrumentation. In PLDI, pp. 190-200. ACM, 2005.
Payman Mohassel and Yupeng Zhang. SecureMI.: A system for scalable learning. IEEE S&P, pp. 19-38. IEEE, 2017.
machine
Valeria Nikolaenko, Stratis loannidis, Udi Weinsberg, Mare Joye, Nina Taft, and Dan Boneh. Privacy-preserving matrix factorization. In CCS, pp. 801-812, ACM, 2013a.
12

---

Under review as a conference paper at ICLR 2020
Valeria Nikolaenko, Udi Weinsberg, Stratis Ioannidis, Mare Joye, Dan Boneh, and Nina Taft. Privacy-preserve ridge regression on hundreds of millions of records. In IEEE S&P, pp. 334- 348. IEEE, 2013b.
Olga Ohrimenko, Felix Schuster, Cédric Fournet, Aastha Mehta, Sebastian Nowozin, Kapil Vaswani, and Manuel Costa. Oblivious multi-party machine learning on trusted processors. In USENIX Security, pp. 619-636. Usenix, 2016.
Meni Orenbach, Pavel Lifshits, Marina Minkin, and Mark Silberstein. Eleos: ExitLess OS services for SGX enclaves. In EuroSys, pp. 238 288-553.42 ACM, 2017.
Meni Orenbach, Yan Michalevsky, Christof Fetzer, and Mark Silberstein. Cosmix: compiler- based system for secure memory instrumentation and execution in enclaves. In USENIX ATC, pp- 570, 2019.
Le Trieu Phong, Yoshinori Aono, Takuya Hayashi, Lihua Wang, and Shiho Moriai. Privacy- preserving deep learning via additively homomorphic encryption. IEEE Trans. Information Foren- sícs and Security, (K5):1333-1344 2018.
Fahad Shaon, Murat Kantarcioglu, Zhiqiang Lin, and Latifur Khan. SGX-BigMarix: A practical encrypted data analytic framework with trusted processors. In CCS. pp. 1211-1228. ACM, 2017.
Reza Shokri and Vitaly Shmatikov. ACM, 2015.
deep learning. CCS, pp. 1310-1321.
Karen Simonyan and Andrew Zisserman. Very deep convolutional networks for large-scale image recognition. In ICLR, 2015.
Rohit Sinha, Manuel Costa, Akash Lal, Nuno P. Lopes, Sriram K. Rajamani, Sanjit A. Seshia, and Kapil Vaswani. A design and verification methodology for secure isolated regions. In PLDI, pp. 665-681. ACM, 2016.
Aleksandra B. Slavkovic, Yuval Nardi, and Matthew M. Tibbits. Secure logistic regression of hori- zontally and vertically partitioned distributed databases. In ICDM, pp. 723-728, 2007.
Raymond K. H. Tai, Jack P. K. Ma, Yongjun Zhao, and Sherman S. M. Chow. Privacy-preserving decision trees evaluation via linear functions. In ESORICS, pp. 492-512, 2017.
Qiang Tang and Husen Wang. Privacy- hybrid recommender system. In AsiaCCS-SCC, pp. 09-6599666 66, 2017.
Shruti Tople, Karan Grover, Shweta Shinde, Ranjita Bhagwan, and Ramachandran Ramjee. Privado: Practical and secure DNN inference. CoRR abs/1810.000 810.00602, 2018.
Florian Tramèr and Dan Boneh. Slalom: Fast, verifiable and private execution of neural networks in trusted hardware. In ICLR, 2019.
Florian Tramèr, Fan Zhang, Ari Juels, Michael K Reiter, and Thomas Ristenpart. Stealing machine learning models via prediction APIs. USENIX Security, pp. 601-618, 2016.
Jaideep Vaidya, Hwanjo Yu, and Xiaoqian Jiang. Privacy-preserving SVM classification. Knowl, Inf. Syst. 14(2):161-178. 2008
Stavros Volos, Kapil Vaswani, and Rodrigo Bruno. Graviton: Trusted execution environments on GPUs. In OSDI, pp. 681-696, 2018.
Sameer Wagh, Divya Gupta, and Nishanth Chandran. SecureNN: 3-party secure computation for neural network training. PoPETs, 2019(3):26-49, 2019.
Boyang Wang, Ming Li, Sherman S. M. Chow, and Hui Li. A tale of two clouds: Computing on data encrypted under multiple keys. In IEEE CNS, pp. 337-345. IEEE, 2014.
Nico Weichbrodt, Pierre-Louis Aublin, and Rüdiger Kapitza. sgx-perf: A performance analysis tool for Intel SGX enclaves. In Middleware, 2018.
13

---

Under review as a conference paper at ICLR 2020
David J. Wu, Tony Feng, Michael Nachrig, and Kristin E. Lauter. Privately evaluating decision trees and random forests. PoPETs, 3016(4):335-355) 2016.
Guandao Yang, Tianyi Zhang, Polina Kirichenko, Junwen Bai, Andrew Gordon Wilson, and Christo- pher De Sa. SWALP: Stochastic weight averaging in low-precision training. arXiv:1904.1 11943, 2019.
Hwanjo Yu, Jaideep Vaidya, and Xiaoqian Jiang. Privacy-presenve SVM classification verti- cally partitioned data. In PAKDD, pp. 647-656, 2006.
Yongjun Zhao and Sherman S. M. Chow. Privacy preserving collaborative filtering from asymmetric randomized encoding. In Financial Crypt., pp. 459 459444457774 47799477,4400 2015.
A PRELIMINARIES
A.1 NEURAL NETWORKS
A neural network gains its predictive power by imitating biological neural networks (Goodfellow al. 2016). A (feedforward) neural network can be represented by a sequence of transformations.
This paper focuses on supervised learning - every training data is a data point x associated with label y, and the neural networks try to learn the relationship between and y. Prediction in supervised learning outputs label of query x.
We refer the computation for prediction by forward-propagation. For training, gradient descend is usually employed, where the computation for updating the parameters is called backward- propagation.
A.1.1 COMMON LAYERS IN NEURAL NETWORKS
Roughly, transformations in a neural network can be divided into two categories: linear transforma- tion and non-lineat transformation? ?
For the linear transformation, we have two kinds of layers.
i) Fully-comnected layer (a.k.a dense layer) - It just multiplies a weighting matrix to the input (for training or prediction).
ii) Convolutional layer It is similar to the convolution operation except it rotates the kernels by 180 degrees. The data structure of inputs, outputs, and kernels are tensors, which are usually 3-dimensional or 4-dimensional.
For non-linear transformation, we have
i) Activation layer, which applies a non-linear function on each element to mimic the impulse acti- vation of biological cells.
ii) Pooling layer, which aggregates values in group after applying function like max() mean() function.
úi) Output layer, which outputs the results in the prediction phase. In the training phase, it computes a loss value measuring the error between the ground truth and the neural network's 's prediction.
A.1.2 COMPUTATIONAL ASPECTS
The linear transformation is the most computationally intensive part JJa 2014) when we compute in plaintext. The same applies to the SGX setting. Looking ahead, we will leverage GPU accelerate the computation of linear layers. Looking ahead, we further outsource the linear transformation to multiple servers by additive secret sharing (Section A.4) to improve efficiency.
In SGX-enclave, the non-linear transformation can be processed in plaintext efficiently. These non- linear transformations are basically aggregating the output from its previous layer and/or applying element-wise operations. A simple but efficient way to handle them is to load the entries from
Some weird layers may appear in some architecture but can he easily implemented using the principle introduced.
14

---

Under review as a conference paper at ICLR 2020
the previous layer to the enclave cache memory one-by-one in deterministic order and output the results once got enough inputs. In this way, the data remains confidential and the memory access pattern is hidden.
In contrast, without SGX, (cryptographic) solutions either use garbled circuits, resulting in high computation and communication overhead (SecureML (Mohassel & Zhang 2017), MiniONN (Liu ett a 2017). and Gazelle (Juvekar et al. 2018)) restricted choice of the activation layer and pooling layer (CryptoNet (Gilad-Bachrace works (DiNN (Bourse et al. (2018). As a result, these solutions are not compatible with many well- developed neural network architectures such as AlexNet (Krizhevsky et al. 2017). VGG16/19 (Si- monyan & Zisserman 2015), etc.
al.) 2 or dramatic reduction of the size of neural net-
A.1.3 VERY DEEP CONVOLUTIONAL NETWORK (VGG)
This is family of very deep neural networks with 9 19 layers with parameters (Simonyan & Zisserman 2013) and has extraordinary performances on object classification. They have convo- lution layers with similar setting, e.g., all of the convolution has filters of 3 x 3 and followed by ReLU and some of them further followed by 2 x 2 max-pooling layers. They are commonly used neural networks and hence it worth to study how improve the performance of neural networks in privacy-preservie setting.
A.2 INTEL SGX
SGX is the latest Intel worddware-asisteee remote secure computing design. Since its seventh gener- ation (Intel 2017). Intel introduced a set instructions and hardware design with which an enclave can be allocated in the trusted hardware, protecting the privacy and integrity of the data to be pro- cessed within it.
A.2.1 SECURITY ENCLAVES AND MEMORY LIMIT
In SGX, enclaves are used as secure containers. When the secure software requests a secure con- tainer, an enclave will be loaded with the code and the data specified by the secure software. The enclave will isolate itself from the rest of the computer. Then the data owner can verify the integrity of the enclave by undergoing a standard remote attestation of SGX. Inside an enclave, all the data will be stored in the main memory in an encrypted and authenticated form when the CPU core is not processing them. When some specific data is going to be processed, it will be loaded into memory caches dedicated to a CPU core with SGX protection enabled and then be decrypted.
Although Intel claims that the current SGX supports up to 128MB of memory, at most 90MB usable according to [Shaon et al. (2017).
A.2.2 GENERIC APPLICATION
The trusted hardware is directly applicable secure computation. Imagine that a data provider holding some sensitive data wants to perform some secure computation on a remote server. The data provider does not trust the server owner and thus he wants that only the server owner can know the pre-defined output. The trusted processor is an efficient solution satisfying these requirements: data can be processed in plaintext inside the trusted processor but remains unknown and tamper-proof, even to the server owner. Of course, the data owner needs to trust both the software provider and the hardware manufacturer.
A.3 GRAPHICS PROCESSING UNIT
A GPU consists of thousands of cores that can perform similar instructions in parallel. If an algo- rithm is parallelizable, GPU increase its computation performance by orders of magnitude.
The most computationally intensive part of neural networks can be transformed into matrix computa- tion, which is well-suited for GPU. Jia (2014) showed that fully-connected layers and convolutional layers occupy over 95% computational time. Abbeefattta et al. (2016) concluded that GPU can speed-up matrix multiplication by > 10x compared multi-core CPU.
15

---

Under review as a conference paper at ICLR 2020
A.4 TWO-PARTY COMPUTATION VIA SECRET SHARING
For two servers Po and P1 holding private input a, b E Zg respectively, where q is a prime, they can let third server learn e + b E Zy without revealing a, b as follows. Po chooses a uniformly random a' Zg.. then sends (a)1
a' to Pt. and keeps (a)o = a - a'. Pi does similar job: samples and sends (b), = b' to Po. and keeps (b)o-
D' No one revealed a or in this process. Then, Po computes (c)o = (a)o + (b)o and Pi computes (c) (a); + (b)1- i. At this point, Po and P1 both hold (additive) secret shares of c = a + Any third party with both shares {ch} can learn (c)o + (c)1.
Beaver 1991) generalized the above method to let Po and P1 compute secret shares of c = a as follows. Suppose Po and P1 have already pre-computed additive secret shares of u, and where u- t = 2. Namely, P, has (u)s. (e)s. and (z); P. masks (a),, (b); via (e), = (a), - (u), and (f); (b), (e);- They then exchange (e); and (f); reconstruct e and f. which is masking a and respectively. Finally, with e and f. they compute (c), = -i(e- f) f (a), e- (b),+ (2); locally,
where (c)o- + (c) ab. This technique can be further generalized to matrix addition//muliplication by replacing En with zg or z Indeed, this technique can applied to any linear operation,
including convolution.
Using this protocol as-is requires two rounds of communication (for recovering (e, ()) and pre- computation (of shares of (u, v, 2)). Looking ahead, we will illustrate how to reduce the communi- cation cost and the pre-computttion and hence improve the throughput.
In the rest of the paper, we use Rand(r=) denote function that takes a random seed ra and outputs random element x' E Zg. Then the (additive) secret share of x held by P; can be written as (x)) Tz, = i x + (-1)² Rand(r..).
B RELATED WORK
B.1 CRYPTOGRAPHIC SOLUTIONS
Gilad-Bachrach et al. (0016) proposed CryptoNet. It exploits non-linear functions supported by leveled homomorphic encryption (LHE) and parallel computation to improve the efficiency of neural network evaluation. However, it only supports limited activation function (x² sigmoid(=:) and pooling function (average pooling). The experiment results of CryptoNet showed that it is roughly 1000 slower than running similar neural network in plaintext.
Subsequent works (Mohassel & Zhang, 2017 Liu et al. 2017; Juvekar et al. 2018) improve or extend CryptoNet in various dimensions. SecureMI. (Mohassel & Zhang, (017) uses two non- colluding servers to support both training and prediction for neural networks, but it is slower than CryptoNet for prediction. MiniONN (Liu al., (017)) achieves higher prediction accuracy than SecureML for the same network structure. It is also 5x faster than SecureML for small neural networks via the single instruction multiple data (SIMD) batching technique on LHE.
To the best of our knowledge, Gazelle (Juvekar et al. 2018) is the state-of oftte--f-thh-att the- cryptographic ap- proach in terms of latency. It performs much better than CryptoNet/MmmiONN by delicately choosing the HE scheme with optimized parameters to fit the hardware architecture. Gazelle has much lower latency than MiniONN//ecureMLL. as its plaintext space is at most 20 bits. However, it still unclear whether Gazelle harms the accuracy, which is not stated in their paper (Juvekar et al. 2018
DiNN (Bourse et al. 2018) follows an approach similar to CryptoNet's. does not require user interaction during the evaluation. To the best of authors' knowledge, it is the state-of-the-art pure- ba-based approach. Yet, as stressed in the DiNN paper (Bourse et al., 2018), they aim to show that pure-HE HE approach is possible and can outperform CryptoNet, at the cost of lower accuracy.
In general, all frameworks mentioned above use expensive cryptographic primitives, such as LHE, garbled circuits, and oblivious transfer, during (training and) prediction, resulting in huge data and computation overheads. Also, using these primitives usually requires multiple rounds of communi- cation between different parties.
As final remark, there are cryptographic solutions that protect the privacy of (mostly the prediction phase of) other machine learning algorithms. A non-exhaustive list includes decision trees random
16

---

Under review as a conference paper at ICLR 2020
forests TTi al. 2017: Wu et al.) 2016 Bost al. 2015), logistic regression (Slavkovic et al.
2007 Bost et al, 2015). support vector machine Vaidya et al. 2008 Yu et al. 2006), collaborative
filtering (Tang & Wang 2017: Zhao & Chow 2015), and k- k-means clustering Bunn & Ostrovsky,
2007
Jagannathan & Wright 2005). They are conceivably less powerful than a deep neural network.
B.2 TRUSTED EXECUTION ENVIRONMENT
Memory Limit Ohrimenko et al. 2 proposed data-oblivious machine learning algorithms using SGX for training and prediction. Their work also defends against some potential side-channel attacks using oblivious operations. However, their algorithms cannot handle any layer of size that exceeds the amount of usable memory (90MB) in an enclave.
The memory limit has been huge drawback of SGX. Different efforts have been devoted to re- solving this issue. [Shaon al. (2017) proposed SGX- MGXX-iiMaatri. It supports operations on matrices which size exceed 90MB, but still have very high overhead comparing to optimized libraries for un- protected matrices. Linux's 's SGX supports memory oversubscription for enclaves, but introduces overhead for the incurred paging, which is reported widely (Weichbrodt et al. 2018 Chakrabarti] et al. (0166). Intel official forum even
2017 Harnik Tsfadia 2017 Brenner et al. reported examples of 10x to x overheads (Feng) 2017). Moreover, based on our experiments, Linux's ' paging introduces up to 24x runtime on matrix multiplications.
Orenbach et al. (2017) proposed Eleos, memory handling mechanism reduce performance over- head due to SGX's 's memory page fault. Its main idea to prevent exiting enclaves when page fault happens because it is expensive instruction. The experimental results showed that it can reduce the paging overhead by 5x. And its successive work CoSMiX (Orenbach et al.] 2019) shows that the paging overhead can be further reduced to 1.3 2.4x. We assume Goten and CaffeSCONE employ this memory handling mechanism to handle paging, and we simulate the performance that does not affected by paging by using simulation mode form Intel SGX SDK.
TEE-based Approaches and TEE+GPU- Approaches A few proposals rely on TEE (Hunt et al. 2018 Tople et al. 2018) or TEE and GPU (Volos et al. 2018 Tramer & Boneh 2019).
Chiron (Hunt et al. 2018) assumes the data provider shards training data into n pieces for n enclaves, such that each shard fits in enclave memory. The authors left the policy for managing insufficient enclave memory as future work. Most importantly, Chiron requires new SGX features that are not available yet. Volos et al. (2018) proposed Graviton, architecture for supporting TEE GPU with the help of SGX, which supports neural network computation in particular, with ncar-native performance compared untrusted GPU. However, they assume that attacker cannot physically steal information from the GPU cores, which is questionable because GPU cores, unlike SGX, are not designed for trusted operation and their security is not well examined.
Bahmani et al. (011)) proposed an SGX-based framework for general-purpose secure multi-party computation. On one hand, work can be viewed realizing specific functionality under their framework at conceptual level. On the other hand, the general-purpose treatment does not take into account the characteristics of neural network computations. More importantly, we pro- vided important technical contribution and we use untrusted GPU to further accelerate computations. Kunkel et al. (2019) proposed TensorSCONE to port another popular DNN framework TensorFlow to SCONE. Our baseline approach is similar to this framework, but we provide our implementation to public for benchmarking.
Privado Topple et al. 2018) allows a model owner to outsource privacy-preserving DNN inference to an SGX-enabled cloud server. It guarantees that even a powerful cloud who sees the SGX enclave memory access pattern does not learn model parameters the user query. Compare with our solu- tion, Privado does not handle training phase, nor does it leverage untrusted hardware like GPU for acceleration.
Tramer & Boneh (209)) recently proposed Slalom for verifiable and private inference using a trusted enclave which also outsources some computation GPU. Their approach heavily relies the assumption that the server knows the model's parameters. is thus not applicable to privacy- preserving training.
17

---

Under review as a conference paper at ICLR 2020
B.3 DIFFERENTIAL PRIVACY
Another line of research focuses achieving differential privacy (Dwork) 2006 Dwork et al., b)) Abbai et al. (2016b) propose a differentially private stochastic gradient descent algo- rithm for deep learning. Shokri Shmatikov (2015) propose collaborative learning, in which data owners jointly train a deep neural network by exchanging differentially private gradients through a parameter server instead of directly sharing local training data. Although [Shokri & Shmatikov (215)) makes it hard to tell whether a specific record exists in the victim's 's private training set, it does not prevent an adversary from learning macro-feature of the training set. [hhong al. (2018) showed that the parameter server in Shokri & Shmatikov (2015) can extract information about the training set, and proposed to use additive HE to eliminate the leakage during training.
C SECURITY ANALYSIS
C.I PROTECTION SCOPE
From the perspective of the querier, no one else can learn the prediction query and the corresponding result. For the model, the most valuable information includes the parameter of the neural network (e.g., weights and bias of convolutional filters and fully-connected layer), the accuracy according to the training dataset, and the intermediate results. These explicit parameters of the model would not be known by any data artt-drrvider and server (with protection against side-channel attacks described shortly afterwards).
We aim for practical framework instead of a perfectly leakage-free solution. Following the litera- ture (Juvekar al. 2018 Mohassel & Zhang 2017 Liu et al. 2017 Gilad-Bachrach al. 2016). we do not protect the hyper-paramette parameters such as the learning rate, the number of layers, the size of each layer eíc. These could be inferred by the querier by timing the interaction with the server or by the server from the memory access pattern. One may hide these by adding dummy storage and computation, which is ought to be inefficient.
Side-channed leakage is also out of our protection scope. Specifically, the access pattern in cache- line may reveal information about the data (Ohrimenko et al. 2016). our case, max- pooolppooing layers and the argmax function in the output layer would be exploitable for their branching depending the intermediate results. Yet, the existing defence (Ohrimenko et al. 2016) can be easily employed by changing the assembly code of max() in the enclave, and the computation overhead is less than 2% (Ohrimenko et al. 2016).
Model extraction attacks (Tamer et al. 2016 Fredrikson al., 2015) be launched in blackbox environment, namely, the attacker knows nothing about the model parameters and its architecture but can query the model, whereby he/she duplicates the functionality of the model. We can easily employ two effective mitigations. First, the training data providers can limit the query rate or set up query quota by consensus. Second, we only return the labels of evaluation results, instead of the confidence values (the values of the output vector) since it is the main attribute being abused by the attackers (Tramer et al. 2016).
C.2 REALIZING THE NON-COLLUDIN ASSUMPTION
To perform training, companies may join forces and have the motivation to dedicate better network line between them. A similar argument also applies the setting in which one of the parties is gen- erally trusted would not collude with others, say, the government. To provide machine learning as service the application context of electronic healthcare (e.g., precision medicine). the Department of Health and Human Services (or alike) can take the effort.
Technically, to ensure at least one server remains secure, we resort to the standard practice from the security community on how to fortify selected machine. We got many possible ways, including but not limited to, i) using different hardware and software configuration from the other server (so a vulnerability in one platform will not lead an easy compromise of both machines), ii) placing it within the network-leve security parameter behind the DMZ, and iii) limited access to the machine instead of public-facing Even when machine is compromised by insider, further enforce
18

---

Under review as a conference paper at ICLR 2020
access control, which at least holds the entity with special access- srress-permissoons accountable when the access-rights are abused, assuming the security of the audit log the access control system.
C.3 OPERATIONS INSIDE ENCLAVES
With the use of SGX, the security guarantee is casy to see. In our construction, the data provided by data providers are either stored in the enclave sealed server storage. When data is stored inside the enclave, by the security guarantee of SGX, no other party is able to gain any information. When data is stored outside the enclave, seal the data by authenticated eneryption (AES- GCM) (Costan & Devadas 2016), which protects the confidentiality and integrity of a sealed block. We also authenticate the meta-data, in particular, the identity and the number of executions of the block, which disallows arbitrary manipulation of the input data by mix-and-match
Apart from storage, we also perform execution over the data. In our framework, all executions are data-independent - the executions of neural networks have no branching dependent on the data or models parameters. We analysis our implementation to be data-oblivious using PinTool (Luk al. 2005), tool for analysis execution trace, to make sure the trace is the same given model parameter, training data, and prediction queries. The execution view observed by other parties can thus be simulated by without the actual data.
Data-oblivious Operations The host an enclave can observe the memory access pattern, even in L2 cache level (Brasser et al. (017). Hence, need to ensure algorithms running in enclaves are data-oblivious, meaning that the trace executed cpu instruction should be the same even given different input data.
Functions involves branching, e.g. max, min, may arouse concern on data-oblivious because some optimization of compilers may skip the write instruction if the computed value is equal the original value. For example, the write in y = max(y, 0) may be skipped if is indeed large than 0.
Fortunately, can always use vectorization techniques to avoid such situations. With vectorization techniques, e.g., SSE and AVX, the vectorized read and write instructions will not be skipped since they are atomic and hence branch depending the data value. Even better, such vectorization techniques are usually automatically employed by common compilers, egg. GCC, with proper flags, e.g., -ma rmaaachhaattii ive. All we need to do manually inspecting compiled assemble code using trace analysis tools, e.g. PinTool (Luk et al. 2005). for automatic verification.
C.4 OUTSOURCING TO GPUS
The only cryptographic primitive we used in the outsourcing protocol is additive secret sharing,
which is commonly used in the non-colluding server setting (Wang al. 2014 Mohassel Zhang 2017) for privacy-preservnng machine learning. It is also not uncommon in the bigger context of secure multi- multi-party computation (Hohenberger & Lysyanskaya 2005 Chow et al.) 2009 Demmler et al., 2015). Its confidentiality holds in the strong information whwematttttootttttteeeee sense against any adversary without enough shares. This fits with the non-colluding server setting well.
Here, we prove that our modified triplet multiplication is secure, namely, none of the server So, S1, and S2 can gain any information of the contents of a, b, or a & e (the servers can learn their dimensions). Due to the non-colluding assumption, we only need to prove that the knowledge of each individual server can be reduced to their counterpart the original protocol.
For S2, it knows and which are random tensors/matrices and contain no information about a, b, or c. Also, z = u @ derived from u and v contains no extra information.
Speaking high-level, the extra knowledge of So and S₁ leaks meaningful information because it is all one-time padding.
Comparing the original protocol described in Section A.4 with protocol described in Fig, in our protocol, Sy has extra knowledge (2)1, C1 + K1-00- and Ku-1- Now, we apply the game- hopping technique to prove that scheme is reducible to the original protocol. Firstly, since So does not know (z)n in our protocol, we can replace (z); by (2)0- Then, since Sp also does not K1-50 also be replaced by random matrix/tensor. Likewise, K is just another
K K1 C
19

---

Under review as a conference paper at ICLR 2020
nn Sequential (
nn. Conv2d (3, 64, 3, padding=1).
mn. BatchNorm2d (64), mn. relu ()
mn. MaxPool2d (2. 2),
an. C64v 128. 3, padding=1),
mn. BatchNorm2d(128)) nn..ell
in. MaxPool2d 2).
mn Conv2d(128, 256. 3. padding=1),
un BatchNorm22 (256), nn. mn.relu
Conv2d(256, 256. 3, padding=1), in BatchNorm2d nn reluel
MaxPool2d 2).
in Co5v2d(256, 512, 3, padding=1),
ButchNorm2d (512), relu ()
in Conv2d(512, 512. 3. padding=1), mn (stchNorm2dd512). relu in MaxPool2d 2),
mn C5nv 512, 3, padding=1).
BatchNorm22d5113) relu ()
in Conv2d(512, 512, 3, padding=1), mn BatchNorm2d(512), reluelu nn MaxPool2d 2),
Linear (512, 512),
nn. Batchhorm11d511
nn relu ()
Linear (512, 512),
nn BatchNormld(511) nn nn relu
nn. minear (512, 10)
Figure The Architecture of VGG11
random matrix/tensor so can be replaced trivially. Now, So has the view of S. in the original protocol plus two random matrices/tensors.
Likewise, S1 has extra knowledge co + Ku-1 and K1-0- Applying the same principles for analyzing Sg, it can be reduced to S in the original protocol.
D ANALYSIS FOR PERFORMANCE GAIN FOR LINEAR LAYERS
We first analyze the case of fully-connected layers. Assume Zmi is the input, Z is the weight, and y Z is the output, We found that should maximize min(m, k,,,.,,n,...... n). Since
m, the batch size, is usually small compared to and n, it is better to be large.
We should minimize the run-time ratio of GPU-powered matrix multiplication scheme to the vanilla CPU scheme. The forward computation in fully-connected layer is x ( w = y- The run-time of our GPU-powered scheme fpre-proc - (m k-n) (fpost-proc tcomm) (m-r) (m-n))+tgpee f (m-k --)..
The backward computation computes da dy & and du dy" ær where dr, dw, and dy are the gradient of x, w, and respectively. and they are of the same size as their counterparts. Similar the analysis above, the total run-time of both forward and backward computations is tgpu-scheme = (2 Epre-proc + Épost-proc + toomm) (m k lo n + m n2) + 3 tgpu-op (m k n), fpp
while the run-time of the vanilla CPU scheme tepu scheme fextra 2 free proe + ppost-proe + feumm-
(m k nn). We denote
Finally, the run-time ratio of these schemes
Lgpu-scheme
textra
1 - m
1
/gpu-op
+ 71
fepu-scheme
tepu-op
tepa-op
20

---

Under review as a conference paper at ICLR 2020
The last term matches with the intuition that GPU governs the performance gain. The pre/post- processing and communication time also play an important role if 1/m + 1/n + 1/k is large. Note that the inverse of 1/m + 1/n + 1/K is also known as the arithmetic intensity (ud 2019).
The analysis on convolution layers follows the same principle but is more involved. If we assume the image size of input and output are the same, can have similar result as fully-connected layers by replacing m, k, and n to Cou fn Sw Cin Sw Sh. and In. Iw respectively.
21


Reviews:
[{"review_id": "rkgoPyQVFr", "reviewer": "AnonReviewer1", "summary": "", "questions": "", "limitations": "", "rating": 1, "confidence": null, "soundness": null, "presentation": null, "contribution": null, "strengths": "", "weaknesses": "", "quality": null, "clarity": null, "significance": null, "originality": null, "strengths_and_weaknesses": "", "was_revised": false, "final_justification": "", "rebuttal": "", "claims_and_evidence": "", "methods_and_evaluation_criteria": "", "theoretical_claims": "", "experimental_designs_or_analyses": "", "relation_to_broader_scientific_literature": "", "essential_references_not_discussed": "", "other_strengths_and_weaknesses": "", "other_comments_or_suggestions": "", "questions_for_authors": "", "summary_of_paper": "", "summary_of_recommendation": "", "technical_quality": "", "clarity_of_presentation": "", "potential_impact": "", "robotics_focus": "", "quality_of_limitations": "", "questions_for_rebuttal": "", "reasons_to_accept": "", "reasons_to_reject": "", "questions_to_authors": "", "main_review": "", "summary_of_the_paper": "", "summary_of_the_review": "", "strength_and_weaknesses": "", "limitations_and_societal_impact": "", "review_text": "\nSummary\n========\nThis paper proposes a framework for privacy-preserving training of neural networks, by leveraging trusted execution environments and untrusted GPU accelerators.\nThe system builds heavily on the prior Slalom system, and uses standard MPC techniques (three non-colluding servers, multiplication triplets) to extend Slalom's inference-only protocol to privacy-preserving training.\nThis is a valuable and hard to reach goal. Unfortunately, the paper's evaluation fails to deliver on its strong promises, by ignoring the high network communication between the non-colluding servers.\nSpecifically, all experiments were conducted with three servers co-located in a public cloud's LAN. In this setting, it is hard to argue that non-collusion is a valid security assumption as the cloud provider controls all servers (alternatively, if the cloud provider is trusted, then there is no need for any trusted execution or cryptography). If the same experiments were conducted on a WAN, the communication costs would alleviate any savings in computation time.\n\nFor these reasons, I lean strongly towards rejection of this paper. \n\nDetailed comments\n=================\nExtending the ideas in Slalom to support privacy-preserving training is a good research question, and Tramer and Boneh had discussed some of the challenges and limitations towards this in their original paper.\nGetting rid of the pre-processing stage for blinding factors by leveraging non-colluding servers is a well-known trick from the MPC literature, but it does not seem easily applicable here. \nThe problem is that the servers need to communicate an amount of data proportional to the size of each internal layer of the network, for each forward and backward pass. If the servers communicate over a standard WAN, the communication time will be much too high to be competitive with the CaffeScone baseline.\nIn a LAN, as in this paper's experiments, the network latency is low enough for the network costs to be dominated by computation. But this begs the question of whether servers running in a same LAN (e.g., hosted by a single cloud provider) can really be considered non-colluding. In the considered setup, the cloud provider (Google in this case), could just observe the communication between all servers, thereby breaking privacy.\n\nAnother security issue with proposed scheme is the lack of computation integrity. This corresponds to the so-called \"honest-but-curious\" threat model which often appears in the MPC literature, and this should be acknowledged and motivated.\n\nOn the experimental side, the considered baseline, CaffeScone, seems pretty weak. In particular, any optimizations that the authors implement for Goten (e.g., better paging) should also be added to their baseline for a fair comparison.\nThe numbers in Figure 3 show that the baseline could be optimized a lot further.  A gap between hardware/simulation modes of ~6x seems indicative of sub-optimal paging. Even the single-core, simulation mode throughput numbers seem low for CIFAR10.\n\nThe experimental setup is quite confusing. Running the baseline and Goten in different environments (e.g., different CPUs) and then re-normalizing throughputs is somewhat convoluted and prone to mistakes. Why not run all experiments on the same setup?\nSimilarly, converting between results in SGX's hardware and simulation modes is also not very indicative. The authors note (p. 8) that in SGX's simulation mode \"code compilation is almost the same as hardware mode except that the program is not protected by SGX, which is fine for our purpose since the DNN training and prediction algorithms are publicly known\". This is fundamentally incorrect!\nSGX's simulation mode provides absolutely no security guarantees. It simply compiles the code using the SGX libraries and ensures that the enclaved code performs no untrusted operations, but it does not provide any hardware protections whatsoever. In particular, code running in simulation mode will not be affected by the overhead of SGX's paging, as the memory is never encrypted.\nAs a result, performance results in simulation mode are usually not indicative of performance in hardware mode. Trying to convert runtimes from simulation mode to hardware mode by comparing times of specific layers is also prone to many approximation errors. \n\nFinally, I had some trouble understanding the way in which Goten quantization works. Section 3.3. mentions that values are treated as floats, but then mentions the use of 53 bits of precision. Did you mean double-precision floats here? But then, aren't modern GPU optimized mainly for single-precision float operations? Section 3.3. also says that the quantization ensures that there are nearly no overflows. What happens when an overflow occurs? I guess that because of the randomized blinding, a single overflow would result in a completely random output. How do you deal with this during training?\n\nMinor\n=====\n- Typo in abstract: Slaom -> Slalom\n- I don't understand the purpose of footnote 3 in Appendix B.2. First, the bibliographic entry for (Volos et al. 2018) explicitly says that the paper was published in OSDI 2018, a top-tier peer-reviewed conference. Regardless, claiming a date for a first unpublished draft of your paper is a little unusual and somewhat meaningless. I'm sure Volos et al. had a draft of their paper ready in late 2017 or even earlier if they submitted to OSDI in XXX 2018. If you want to timestamp your paper, post in to arXiv or elsewhere online.", "extra_scores": {"experience_assessment": "I have published one or two papers in this area.", "review_assessment:_checking_correctness_of_derivations_and_theory": "N/A", "review_assessment:_checking_correctness_of_experiments": "I carefully checked the experiments.", "review_assessment:_thoroughness_in_paper_reading": "I read the paper thoroughly."}, "extra_text": {}}, {"review_id": "HkguQA3BYB", "reviewer": "AnonReviewer3", "summary": "", "questions": "", "limitations": "", "rating": 6, "confidence": null, "soundness": null, "presentation": null, "contribution": null, "strengths": "", "weaknesses": "", "quality": null, "clarity": null, "significance": null, "originality": null, "strengths_and_weaknesses": "", "was_revised": false, "final_justification": "", "rebuttal": "", "claims_and_evidence": "", "methods_and_evaluation_criteria": "", "theoretical_claims": "", "experimental_designs_or_analyses": "", "relation_to_broader_scientific_literature": "", "essential_references_not_discussed": "", "other_strengths_and_weaknesses": "", "other_comments_or_suggestions": "", "questions_for_authors": "", "summary_of_paper": "", "summary_of_recommendation": "", "technical_quality": "", "clarity_of_presentation": "", "potential_impact": "", "robotics_focus": "", "quality_of_limitations": "", "questions_for_rebuttal": "", "reasons_to_accept": "", "reasons_to_reject": "", "questions_to_authors": "", "main_review": "", "summary_of_the_paper": "", "summary_of_the_review": "", "strength_and_weaknesses": "", "limitations_and_societal_impact": "", "review_text": "The paper builds a privacy-preserving training framework within a Trusted Execution Environment (TEE) such as Intel SGX. The work is heavily inspired from Slalom, which does privacy-preserving inference in TEEs. The main drawbacks of Slalom when extending to training are (1) weight quantization needs to be dynamics as they change during training, and (2) pre-processing step of Slalom to compare u = f(r) isn't effective as the weights change, and running this within TEE is no better than running the full DNN within TEE. In addition, Goten also makes the weights private as opposed to Slalom. Overall, this is a very important contribution towards privacy preserving training and the paper takes a strong practical and implementation-focused approach by considering issues arising due to memory limitations in TEE and the performance implications of default Linux paging.\n\nThe paper comes up with a novel outsourcing protocol with two non-colluding servers for offloading linear operations in a fully privacy-preserving way and does detailed analysis of the performance implications. Similar to a lot of other methods for training with quantization, the weights are stored and updated in floats while the computation is performed using quantized values. The experimental results suggest a strong improvement over the CaffeSCONE baseline. One drawback with experiments is the lack of comparison with Slalom for inference if Goten is assumed to be a framework for both training and prediction in a privacy-preserving way.\n\nAnother downside of the paper is that a few sections could be improved with their explanation, and there is quite a bit of redundancy in going over the downsides of Slalom and why it can't be used for secure training. For instance,\n- Section 1.1: \"Our results (referring to Section 4.2) show that CaffeSCONE’s performance greatly suffer from the enclave’s memory limit as it needs an inefficient mechanism to handle excessive use of memory not affordable by the enclave\". Here, it's not clear which mechanism is inefficient. Are we talking about mechanisms in CaffeSCONE for reducing memory usage while training and if so, are they somehow inefficient? Or does it mean to imply that we can't train a DNN fully within an enclave due to memory limits?\n-  Last paragraph of section 2.2 is unclear. \"CaffeSCONE guarantees the correctness of both training and prediction. Goten does not provide it as we present it due to page limitation, but we can resort to the trick used by Slalom\". What does the last sentence mean? Does Goten guarantee correctness during training and prediction or not? And what trick from Slalom are we referring to? The blinding trick used for privacy or the Freivalds' algorithm used for correctness?\n\nOverall a strong contribution with supporting experimental results, but the certain parts need further explanation or rewriting for higher rating.\n\nPros:\n- An important contribution in the direction of fully private DNN training and inference within a TEE. Draws inspirations from Slalom and mainly addresses the challenges left to extend the approach to training.\n- Motivation and reasons for why Slalom can't be used for training is very well laid out.\n- In addition to input and output activations, Goten also preserves the privacy of the weights.\n- Good baseline for comparison using CaffeSCONE.\n- Implementation factors considered and analyzed such as tricks as using SGX-aware paging instead of naive Linux paging.\n- Strong experiments and benchmarks\n\nCons:\n- Some sections are not explained well and unclear as mentioned earlier.\n- How does the inference performance of Goten compare to Slalom given the same privacy and correctness guarantees? This isn't clear from the experiments section.\n\nMinor comments:\n- \"Slalom\" is mis-spelt in line 4 of the abstract.\n- There appear to be typos and grammatical errors at many places in the paper. Further proof-reading might be helpful.", "extra_scores": {"experience_assessment": "I do not know much about this area.", "review_assessment:_checking_correctness_of_derivations_and_theory": "I assessed the sensibility of the derivations and theory.", "review_assessment:_checking_correctness_of_experiments": "I assessed the sensibility of the experiments.", "review_assessment:_thoroughness_in_paper_reading": "I read the paper at least twice and used my best judgement in assessing the paper."}, "extra_text": {}}, {"review_id": "BkehxucWcH", "reviewer": "AnonReviewer2", "summary": "", "questions": "", "limitations": "", "rating": 1, "confidence": null, "soundness": null, "presentation": null, "contribution": null, "strengths": "", "weaknesses": "", "quality": null, "clarity": null, "significance": null, "originality": null, "strengths_and_weaknesses": "", "was_revised": false, "final_justification": "", "rebuttal": "", "claims_and_evidence": "", "methods_and_evaluation_criteria": "", "theoretical_claims": "", "experimental_designs_or_analyses": "", "relation_to_broader_scientific_literature": "", "essential_references_not_discussed": "", "other_strengths_and_weaknesses": "", "other_comments_or_suggestions": "", "questions_for_authors": "", "summary_of_paper": "", "summary_of_recommendation": "", "technical_quality": "", "clarity_of_presentation": "", "potential_impact": "", "robotics_focus": "", "quality_of_limitations": "", "questions_for_rebuttal": "", "reasons_to_accept": "", "reasons_to_reject": "", "questions_to_authors": "", "main_review": "", "summary_of_the_paper": "", "summary_of_the_review": "", "strength_and_weaknesses": "", "limitations_and_societal_impact": "", "review_text": "The paper proposes a method for privacy-preserving training and evaluation of DNNs. The method is based on a combination of hardware support from a trusted execution enclave (Intel SGX) and an algorithm for offloading intensive computation to unsecure GPU devices and communicating with the trusted environment without losing security guarantees during communication.  Compared to related work on a similar system (Slalom), the proposed system enables secure training in addition to inference.  The approach is based on the use of additive secret sharing to relegate chunks of computation to independent GPU servers.\n\nThe evaluation presents experiments that report timings of the proposed system against a baseline. Throughput (images/second) improvements of 8-9x are reported, but the contrast point is unclear (it appears to be CaffeSCONE, but there are several unclear points, summarized below). In addition, a set of results reporting a speed up ratio against attained accuracy of a trained VGG11 network, and a set of results reporting speed up against arithmetic intensity of the workload are given.\n\nI lean towards rejection of this draft, as it has several weaknesses:\n- The connection between the evaluation (which mostly focuses on the speed benefits) and the claimed contributions is tenuous at best. This issue is further compounded by clarity issues in the experiments and their description\n- The empirical results are unclear due to differences between simulation of SGX capability vs hardware support of SGX capability. It is not clear what part of the results is influenced significantly by this disparity, and more importantly whether all the comparisons are done in an equal footing (for example the reported results comparing CaffeSCONE with Goten are performed in two different regimes). As a byproduct, there is a confusing \"scaling factor\" described by the authors that is applied to the timings.\n- A brief mention is made of the fact that the proposed system does not in fact provide correctness guarantees (unlike CaffeSCONE), but this is dismissed by reference to utilizing the same trick used by Slalom.  However, this trick is not described or motivated.\n- The writing in the current draft is of relatively low quality, significantly impacting the readability of the paper and making it hard to understand the contributions and whether they are backed by the presented results.\n", "extra_scores": {"experience_assessment": "I do not know much about this area.", "review_assessment:_thoroughness_in_paper_reading": "I read the paper at least twice and used my best judgement in assessing the paper.", "review_assessment:_checking_correctness_of_experiments": "I assessed the sensibility of the experiments.", "review_assessment:_checking_correctness_of_derivations_and_theory": "I assessed the sensibility of the derivations and theory."}, "extra_text": {}}]

Author rebuttal:

Meta-review: This paper proposes a framework for privacy-preserving training of neural networks within a Trusted Execution Environment (TEE) such as Intel SGX. The reviewers found that this is a valuable research directions, but found that there were significant flaws in the experimental setup that need to be addressed. In particular, the paper does not run all the experiments in the same setup, which leads to the use of scaling factor in some cases. The reviewers found that this made it difficult to make sense of the results. The writing of this paper should be streamlined, along with the experiments before resubmission.
Decision: Reject