{"id":"a5c7793e-f961-43f0-99de-89fe80737e45","arxiv_id":"2501.11558","paper_version":1,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":5.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":4,"one_line_summary":"Intel TDX adds at most about 1.5x runtime overhead to federated image classification training, based on single runs across three datasets and two models.","lead":"This paper benchmarks Intel TDX, a new virtual-machine-based trusted execution environment, for federated learning, reporting at most 1.5x wall-clock overhead compared to unprotected training. It also compares this to an earlier SGX-based approach, but the two use different CPU generations, which weakens the comparison.","discovery_kind":"extension","skeptic_critique":{"model":"deepseek-v4-flash","headline":"The at-most-1.5x overhead claim rests on a single rounded run per configuration; the maximum observed 1.47x leaves less than 3% margin, so unrepeated measurements cannot support the asserted bound.","rationale":"I read the paper as an extension of the prior SGX study [17], and the arithmetic in Table II is internally consistent: the top-table baseline and TDX runs appear to use the same TDX-enabled hardware, so the 1.47x maximum is not an artifact of comparing across CPU generations. However, the central claim is an upper bound ('at most 1.5x'), and the evidence for that bound is a single wall-clock observation per cell, reported at minute granularity, with the largest ratio only 2-3% below the bound. Without repeated runs or error bars, the bound is not established as a stable property of the setup. The tuning ambiguity from Section III compounds this: the paper notes that prior work required careful thread-count tuning but does not confirm that the same tuning was applied to both baseline and TDX, so the overhead ratio could be biased. These concerns do not require rejecting the paper; the observed numbers are plausible and valuable as preliminary data, but the headline generalization should remain conditional on repeated, configuration-controlled measurements. The reader's weakest assumption identifies the same underlying issue, so my assessment agrees with the conditional verdict and does not move it.","tokens_in":7668,"tokens_out":7071,"duration_ms":72357,"concrete_test":"Rerun the MobileNetV3-Small/MNIST configuration (the 1.47x case) and the ResNet-18/CIFAR100 configuration at least 5 times each on the same TDX hardware, explicitly applying the [17] thread setting (threads = cores per socket) and recording unrounded wall-clock times. Compute the mean, standard deviation, and 95% bootstrap confidence interval for the ratio TDX+TLS / baseline. If the upper confidence bound or the observed mean exceeds 1.5, the headline 'at most 1.5x' claim is not supported. Also report the thread counts used for baseline and TDX runs to rule out configuration mismatch.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The abstract's central quantitative claim is that VM-based TEEs add at most 1.5x overhead. In Table II this rests on the largest observed ratio, MobileNetV3-Small on MNIST: TDX+TLS = 1:18 vs baseline = 0:53, i.e. 1.47x. Only one wall-clock time per configuration is reported, at minute granularity, with no repeated runs or confidence intervals. The 1.47x point estimate is only about 2-3% below the asserted cap, so ordinary run-to-run variance (e.g., network jitter, data-loading behavior, VM scheduling) could push it above 1.5x on a second run; rounding alone could also hide a true ratio above 1.5. The paper references the thread-tuning recommendation from [17] (threads equal to cores per socket) but does not state whether it was applied to the TDX and baseline runs; if the baseline was run untuned while TDX was tuned, the overhead would appear artificially small. The SGX comparison is confounded by different CPU generations, but that is secondary because the at-most-1.5x claim uses the TDX-hardware baseline. Thus the strongest claim is load-bearing on a single, unrepeated, rounded measurement with a thin margin; as reported, the evidence does not yet substantiate a universal upper bound.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper benchmarks Intel TDX, a VM-based TEE, for confidential federated learning under OpenFL, comparing wall-clock execution times with an earlier SGX/Gramine-based baseline from the same authors' prior work. Three datasets (MNIST, CIFAR10, CIFAR100) and two models (ResNet-18, MobileNetV3-Small) are trained for 100 federated rounds, with incremental protections: baseline, TLS, TDX, and TDX+TLS. The authors report that TDX adds only slight overhead, state in the abstract that VM-based TEEs introduce at most 1.5x overhead, and fit a linear overhead model T = T_baseline + C_TDX*T_baseline + C_TLS*T_baseline to the measured times. They conclude that confidential computing can be deployed in untrusted HPC/cloud environments without significant performance detriment.","tokens_in":7901,"tokens_out":3315,"duration_ms":40516,"significance":"If the central quantitative claim were well supported, the paper would provide useful deployment evidence for VM-based TEEs in federated learning, an area where most prior measurements concern SGX-style application isolation. The study has concrete strengths: it covers three datasets and two model architectures, uses a realistic distributed setting with one aggregator and three collaborators, and reports communication-time statistics in Table III. The linear overhead model is transparent and easy to reuse. However, the headline 'at most 1.5x' claim is currently underwritten by single rounded wall-clock measurements whose largest ratio is only 1.47x, and the fitted overhead coefficients are descriptive rather than predictive. The SGX comparison is also confounded by different CPU generations. These issues bear directly on the paper's main conclusion.","major_comments":[{"comment":"The central claim that VM-based TEEs introduce 'at most 1.5x' overhead is not supported by the evidence as reported. The largest observed ratio in Table II is MobileNetV3-Small on MNIST with TDX+TLS: 1:18 versus 0:53 baseline, which is 1.47x. Each configuration is represented by a single wall-clock time rounded to the minute, with no repeated runs, standard deviations, or confidence intervals, leaving a margin of only about 2-3% below the asserted cap. Rounding alone could hide a true ratio above 1.5x, and run-to-run variance from network jitter, data loading, or VM scheduling could do the same. The abstract should either be qualified to the observed point estimates or the authors should provide repeated measurements with error bars demonstrating that the 1.5x bound holds across runs.","section":"Abstract and Table II"},{"comment":"The overhead coefficients C_TDX and C_TLS are fitted by non-negative linear regression to the same wall-clock data from which the overhead ratios are computed, yet no goodness-of-fit, residual analysis, or out-of-sample validation is provided. The model is therefore descriptive of the six measured configurations, not a predictive performance model. In addition, the model form is inherited from prior work [17] without revalidation for TDX. The manuscript should state this limitation explicitly and should not present the fitted coefficients as evidence that the 1.5x bound generalizes beyond the measured runs.","section":"Section III, overhead model and Fig. 2"},{"comment":"The comparison between TDX and SGX is confounded by hardware differences: the TDX experiments run on dual-socket 5th-generation Intel Xeon Platinum 8592 processors, while the SGX baseline runs on dual-socket 3rd-generation Intel Xeon Platinum 8380 processors. The narrative that SGX 'doubles execution time' while TDX adds only slight overhead conflates TEE technology with CPU generation. The authors should either run both TEE configurations on the same hardware generation or restrict the SGX comparison to qualitative statements and make the hardware confound explicit.","section":"Section III, experimental setup and Table II"},{"comment":"The manuscript states: 'Since our approach is not affected by loss in learning performance, as we perform a standard training routine as in [17], and due to space constraints, we omit plots and discussion about model's accuracies.' This assertion is unsupported because no accuracy numbers are reported anywhere in the paper. While the paper is focused on performance, claiming no learning-performance loss without reporting accuracies is a load-bearing omission, especially because the sentence frames the omission as a consequence of the claim rather than as a measurement. The authors should either report the accuracy results or remove the claim.","section":"Section III, accuracy statement"}],"minor_comments":[{"comment":"The items labeled 'Fig. 1' and 'Fig. 2' are not figures but displayed equations and a coefficient table, respectively; they should be numbered as equations or tables and referenced consistently in the text.","section":"Section III, Figs. 1 and 2"},{"comment":"The template placeholder 'Index Terms—component, formatting, style, styling, insert' has been left in the manuscript and should be replaced with actual index terms.","section":"Header/abstract metadata"},{"comment":"The parenthetical sentence about CIFAR100 and 'colours MNIST' is grammatically garbled and unclear; it should be rewritten, and the claim about MNIST being colored should be checked, as MNIST is grayscale.","section":"Section III, sentence on CIFAR/MNIST statistics"},{"comment":"The sentence 'The author hypothesizes that this can be due to some optimization reasons' uses the singular 'the author' where 'we' or 'the authors' is intended; this should be corrected.","section":"Section III, discussion of MobileNetV3"},{"comment":"The two blocks of Table II (TDX-based rows and SGX-based rows) are not explicitly labeled in the table itself; adding a column or grouping label indicating the hardware/TEE type would improve readability.","section":"Table II presentation"}],"recommendation":"major_revision","confidential_remarks":"The manuscript reads as a workshop-style empirical study, and the central 1.5x overhead claim is not yet robust enough for a journal publication. The main fix is not a change in direction but additional experimental rigor: repeated runs with error bars, a clear statement of hardware constraints, and a descriptively honest framing of the fitted model. If the authors can provide that, the paper would be a useful contribution; as submitted, the evidence is thin relative to the abstract's universal claim."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"Quick take: this is a straightforward extension of the author's earlier SGX benchmark [17] to Intel TDX. The new data are the TDX wall-clock times for two models across three datasets, plus communication-time statistics. That is a legitimate contribution: TDX is new enough that public numbers help people planning confidential FL deployments. The paper does a clean job of describing the setup and reproducing the prior learning scenario, and the communication-time table with means and standard deviations is a nice touch.\n\nThe main claim, that TDX overhead is at most 1.5x, is consistent with the reported table but not actually established. The largest ratio is MobileNetV3-Small on MNIST: 1:18 vs 0:53, which is 1.47x. Those are single wall-clock runs reported at minute granularity, with no repetition or variance. A 2-3% margin is within ordinary run-to-run noise, so the 'at most 1.5x' phrasing is stronger than the evidence supports. The paper should either run repeats and report bounds, or soften the claim to 'around 1.5x or less in these runs.'\n\nOther soft spots: the comparison to SGX runs on different CPU generations (5th Gen vs 3rd Gen Xeon), so the SGX-vs-TDX overhead comparison is not apples-to-apples. The paper also explicitly omits accuracy verification, saying the standard training routine makes it unnecessary. That is a defensible assumption but worth a sentence or two of justification or a quick accuracy table. The fitted linear model is descriptive, not predictive; that is fine as a summary but should not be called a predictive performance model. No code or data are provided, which limits reproducibility.\n\nWho should read this: practitioners choosing between SGX and TDX for federated learning, and people benchmarking TEE overhead in general. It deserves peer review, but only conditionally: the single-run timing issue needs addressing, and the claims should be scaled back to match the evidence. The paper is on the right track and the data are genuinely new; with repeats and clearer limitations it would be a solid engineering data point.\n\nI would send it to review, expecting revision.","headline":"Useful first TDX-for-FL benchmark, but the headline 1.5x cap is built on a single unrepeated measurement per cell.","tokens_in":8464,"tokens_out":3104,"would_cite":false,"duration_ms":32510,"reading_group":"maybe","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"VM-based trusted execution environments like Intel TDX add no more than 1.5x overhead to confidential federated learning.","keywords":["federated learning","confidential computing","trusted execution environment","Intel TDX","Intel SGX","performance analysis","TLS overhead","OpenFL"],"falsifier":"Repeat the MobileNetV3-Small/MNIST 100-round training on the same 5th-generation Xeon hardware with several thread counts and multiple trials, comparing the best-tuned no-TEE baseline against TDX+TLS; the reported 78-minute vs 53-minute result is already 1.47x, so any trial pushing the ratio past 1.5x, or a better-tuned baseline, would refute the headline bound.","tokens_in":7383,"feed_emoji":"🔐","tokens_out":17007,"duration_ms":151515,"temperature":0.7,"pith_summary":"This paper claims that Intel TDX, a VM-based trusted execution environment, runs confidential federated learning with only a small, predictable runtime penalty: at most 1.5x relative to unprotected execution, compared with roughly 2x for an SGX-based pipeline. The evidence is a set of 100-round, one-epoch federated training runs across MNIST, CIFAR10, and CIFAR100 with ResNet-18 and MobileNetV3-Small, each measured under four configurations (baseline, baseline plus TLS, TDX, TDX plus TLS). The author decomposes the cost with an additive model in which TDX and TLS each contribute a fixed multiple of baseline time, with fitted coefficients of 0.126 and 0.245 for TDX on the two models. If the claim holds, confidential computing becomes a practical default for federated learning on public cloud and HPC resources, not a specialized option requiring heavy porting effort.","feed_headline":"Trusted VMs add at most 1.5x to confidential federated learning","feed_subtitle":"SGX roughly doubles runtime; TDX keeps secure federated training near 1.5x, easing cloud/HPC adoption.","key_machinery":"The load-bearing mechanism is an additive runtime model, $T = T_{\\text{baseline}} + O_{\\text{TDX}} + O_{\\text{TLS}}$, in which each security layer contributes an overhead $O = C \\cdot T_{\\text{baseline}}$ proportional to the unprotected baseline. The coefficients are fitted by non-negative linear regression and are the paper's quantitative result: $C_{\\text{TDX}}$ is 0.126 for ResNet-18 and 0.245 for MobileNetV3-Small, while $C_{\\text{TLS}}$ is 0.079 and 0.065 respectively. This identity matters because it separates the cost of computation isolation (TDX) from the cost of secure communication (TLS), so each can be measured, predicted, and budgeted independently. The hardware mechanism underneath is Intel TDX's VM-level isolation, which encrypts memory and CPU state while avoiding per-call enclave switching, and which is compared against an SGX-plus-Gramine baseline supplied by an earlier study.","core_discovery":"The paper's central discovery is that VM-level isolation changes the cost profile of confidential federated learning. On the same 5th-generation Xeon hardware, TDX and TDX plus TLS completed the full training runs in at most 1.47x the unprotected baseline time, whereas the SGX-based pipeline took roughly twice as long. The overhead is additive and model-dependent: $T = T_{\\text{baseline}} + C_{\\text{TDX}}T_{\\text{baseline}} + C_{\\text{TLS}}T_{\\text{baseline}}$ with $C_{\\text{TDX}} = 0.126$ for ResNet-18 and $0.245$ for MobileNetV3-Small, and $C_{\\text{TLS}} \\approx 0.065\\text{--}0.079$. The author attributes the improvement to TDX's VM-based design, which removes the constant enclave-to-unprotected-world switches that SGX requires, at the price of a larger trust boundary that includes the guest OS and VM administrators.","pith_inferences":["Beyond the paper's comparisons, the TDX runs used 5th-generation Xeon Platinum 8592 CPUs while the SGX baseline used 3rd-generation Xeon Platinum 8380 CPUs, so the measured speed advantage probably mixes TEE architecture with hardware-generation gains; the paper does not isolate these factors.","The paper's linear model suggests a cheap extrapolation recipe—measure one secure run and estimate overhead for other models by subtracting the fitted coefficients—but this recipe is not validated across architectures and remains an unproven extension.","Since Table II reports single wall-clock values while Table III shows substantial variance in communication times, the headline 1.5x bound is likely run-dependent; repeated trials on the same hardware would reveal its distribution and true maximum.","A security-aware reading of the performance result: TDX's larger trust boundary means the low overhead is only acceptable when the guest OS and VM administrators are trusted, so the deployment recommendation should be conditioned on the threat model."],"forward_implications":["Secure federated training with TDX and TLS stays within 1.47x of unprotected training on every tested dataset/model pair, so the performance argument against confidential deployment on untrusted cloud or HPC hardware is substantially weakened.","Practitioners can estimate end-to-end runtime from a baseline measurement using the fitted coefficients ($C_{\\text{TDX}} \\approx 0.13\\text{--}0.25$, $C_{\\text{TLS}} \\approx 0.07$), rather than needing to benchmark every security stack from scratch.","Because TDX removes the enclave-world switching and code-porting burden of SGX, VM-based TEEs make confidential FL compatible with standard federated learning implementations and workflows.","The roughly doubled TDX coefficient for MobileNetV3-Small implies that model architecture, especially layer count and depthwise separable convolutions, affects TEE overhead, so architecture-aware budgeting will matter."],"supporting_citations":[{"why":"Supplies the SGX baseline, the experimental protocol, and the additive overhead model that this paper extends to Intel TDX.","marker":"[17]"},{"why":"OpenFL is the federated learning implementation used for all server and client training runs.","marker":"[20]"},{"why":"Gramine is the library OS used to run the SGX baseline, which the TDX results are compared against.","marker":"[18]"},{"why":"TLS is the secure communication protocol whose overhead is measured alongside the TEE overhead.","marker":"[21]"},{"why":"ResNet-18 is one of the two benchmarked neural networks; its fitted TDX overhead coefficient is 0.126.","marker":"[24]"},{"why":"MobileNetV3-Small is the other benchmarked network, with about three times as many layers and a fitted TDX coefficient of 0.245.","marker":"[25]"},{"why":"MNIST supplies one of the three benchmark datasets in the federated training runs.","marker":"[22]"},{"why":"CIFAR10 and CIFAR100 supply the other two benchmark datasets and drive the dataset variation in all configurations.","marker":"[23]"}],"fun_headline_variants":["TDX VMs cap confidential FL overhead at 1.5x","VM-based TEEs: TDX beats SGX on private FL speed","Confidential FL with TDX VMs: only 1.5x slower","SGX doubles runtime; TDX adds just 50% for secure FL"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The central claim assumes the TDX and baseline runs were configured under otherwise identical, representative conditions and that the single wall-clock measurements are stable; the paper does not report repeated runs or tuning checks, so a poorly tuned baseline could make the overhead appear smaller than it is.","fun_headline_variants_meta":{"raw":{"variants":["TDX VMs cap confidential FL overhead at 1.5x","VM-based TEEs: TDX beats SGX on private FL speed","Confidential FL with TDX VMs: only 1.5x slower","SGX doubles runtime; TDX adds just 50% for secure FL"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000311,"raw_usage":{"total_tokens":1801,"prompt_tokens":1005,"completion_tokens":796,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":621,"completion_tokens_details":{"reasoning_tokens":713}},"tokens_in":621,"tokens_out":796,"duration_ms":7750,"temperature":1.0,"reasoning_tokens":713,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-10T18:06:42.501092+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Repeat the MobileNetV3-Small/MNIST 100-round training on the same 5th-generation Xeon hardware with several thread counts and multiple trials, comparing the best-tuned no-TEE baseline against TDX+TLS; the reported 78-minute vs 53-minute result is already 1.47x, so any trial pushing the ratio past 1.5x, or a better-tuned baseline, would refute the headline bound.","supporting_citations":[{"cited_title":"OpenFL: the open federated learning li brary","cited_arxiv_id":null,"evidence_quote":"OpenFL is the federated learning implementation used for all server and client training runs."},{"cited_title":"Cooperation and security isolation of l ibrary OSes for multi-process applications","cited_arxiv_id":null,"evidence_quote":"Gramine is the library OS used to run the SGX baseline, which the TDX results are compared against."},{"cited_title":"The Transport Layer Security (TLS) Protoc ol V ersion 1.3","cited_arxiv_id":null,"evidence_quote":"TLS is the secure communication protocol whose overhead is measured alongside the TEE overhead."},{"cited_title":"& Sun, J","cited_arxiv_id":null,"evidence_quote":"ResNet-18 is one of the two benchmarked neural networks; its fitted TDX overhead coefficient is 0.126."},{"cited_title":"& Haffner, P","cited_arxiv_id":null,"evidence_quote":"MNIST supplies one of the three benchmark datasets in the federated training runs."},{"cited_title":"& Others Learning multiple layers of features from tiny images","cited_arxiv_id":null,"evidence_quote":"CIFAR10 and CIFAR100 supply the other two benchmark datasets and drive the dataset variation in all configurations."}],"review_version":1}