1. 如何保證 java 應用安全標准答案來了
如何保證 Java 應用安全？
在 Java 程序內存中保護密碼安全，可以通過引入機密計算技術來實現。龍蜥社區雲原生機密計算 SIG 推出了 Java 機密計算實現技術——Teaclave Java TEE SDK。該技術具有顯著優點，已經經過企業級內部場景驗證並在 Apache 社區開源。它在軟體工程頂級會議 ICSE 2023 上發表的論文獲得了 ACM SIGSOFT 傑出論文獎，是自 2020 年以來，龍蜥社區雲原生機密計算 SIG、上海交通大學、大連理工大學首次獲此榮譽。
保護 Java 程序內存中密碼的安全，關鍵在於如何在運行時環境中安全使用敏感數據。密碼一旦解密後，即以明文形式存在於 Java 堆上，可能導致被攻擊或主動泄漏。為了解決這一問題，Teaclave Java TEE SDK 通過將密碼從內存中銷毀，大大減少了敏感信息暴露的時間窗口。此外，通過將密碼保存為 char 數組或 byte 數組，避免了反射調用，使得銷毀過程更加便利。使用 byte 數組保存密碼，更是增加了信息的隱蔽性，使其難以被解讀。
然而，當前在網路上找到的解決方法，如縮短明文密碼在內存中的存放時間，僅縮短了敏感信息暴露的時間窗口，並未真正保護明文密碼。這些方法對密碼的銷毀時間判斷彈性較大，開發人員未必能准確判斷何時是最佳時機。更典型的案例，如著名的 log4j 漏洞問題，攻擊者能夠利用漏洞將惡意類文件上傳至伺服器，並通過 Java 動態類載入機制運行，竊取 Java 堆中的私鑰，進而獲得伺服器與客戶端之間通信內容的完全訪問許可權。
為了解決 Java 程序安全性問題，機密計算技術成為了一個標准答案。它通過提供硬體級的系統隔離，保障數據安全和程序運行安全。機密計算將執行環境分為富執行環境（REE）和可信執行環境（TEE），認為 REE 和 TEE 應該相互隔離，TEE 需要通過硬體加密來保證外界無法知曉其中的內容。這一機制在 1999 年即已提出，並在隨後的 20 多年中得到了發展。
其中，SGX、TrustZone 等提供了通用型機密計算的硬體基礎，Intel、微軟等開源的驅動和 SDK 則為通用型機密計算提供了軟體基礎。然而，直接在 TEE 中運行 Java 程序並不友好，因為 TEE 只能執行 native 程序。為解決這一問題，Occlum 作為介於 TEE 底層 SDK 與 JVM 之間的一層 LibOS，支持 JVM 在 TEE 中的運行。然而，Occlum 方案存在安全性和性能下降的問題，TCB（可信計算基）過大，導致安全性不佳；性能下降，TEE 硬體與 REE 相比存在性能退化。
針對上述問題，Teaclave Java TEE SDK 提出了一種在 TEE 中僅放入可信代碼的解決方案。通過將可信代碼從 Java 代碼直接編譯為 native code 放入 TEE 運行，Teaclave Java 採用模塊分隔、機密計算服務化、簡潔的機密計算服務生命周期管理 API、Java 靜態編譯等關鍵技術特性，將應用代碼分為 Host、Enclave 和 Common 三個模塊。Host 中為普通安全非敏感程序，Enclave 中為安全敏感程序，Common 中則是兩者的公共代碼。通過將可信代碼放入 TEE 運行，實現了 Java 應用的機密計算，降低了安全性和性能的下降問題。Teaclave Java 提供了一站式快速實現 Java 機密計算應用的開發和構建能力，簡化了 Java 機密計算的開發門檻。
在實際應用中，Teaclave Java 通過將應用的普通代碼放在 REE 中執行，安全敏感的解密和私鑰放在 TEE 中，實現了對敏感數據和運算過程的保護。在機密計算框架的對比中，Teaclave Java 的 TCB（可信計算基）大小僅為 Occlum 的大約 1/20 到 1/10，具有更高的安全性。運行時性能方面，Teaclave Java 的 native image 會直接以 native 代碼形式運行，啟動速度非常快，適用於小型應用。對於長時間執行的應用，性能優勢會逐漸減小。此外，Teaclave Java 的運行時內存使用量更少，為應用提供了更高效、安全的運行環境。
綜上所述，Teaclave Java TEE SDK 是解決 Java 應用安全問題的有效方案，它通過硬體寬容性、安全沙箱隔離、高效的運行時性能和簡潔的開發流程，為 Java 應用提供了全面的安全保障。未來，隨著 GraalVM 的 Java 靜態編譯技術被貢獻給 OpenJDK，Teaclave Java 方案將獲得 JDK 的原生支持，進一步提升其性能和易用性。同時，Teaclave Java 項目的源代碼已被貢獻至 Apache 社區，加入機密計算框架 Teaclave 項目，正在開源孵化中。
2. 為什麼ACM初賽用java、c\c++等都可以，到了決賽只能用C/C++
你問的這個問題吧，真的沒有一個標准答案，有許多考量吧。
1. 規則制定：
無可厚非，賽制也可以增加java來作為一種語言，所以只要組織這個活動的委員會投票增加的話也就是了。只不過可能某些原因沒有增加。
Final一般要求更加嚴格，所以修改規定什麼的也就更加難。在該比賽發起時java並不如現在使用廣泛，後來隨著其流行性以及其他語言的情況，考慮在區域賽中增加了支持這些語言已經照顧了很多programmer。這首先區域賽可以稍微靈活點，自主性大點，就比如體育比賽中得到世錦賽名額什麼的和後面最終比賽的規則什麼的會有些不一樣。要新增加java等需要得到委員會的投票認可，但因為公平性、評判性等因素難以得到贊成票，可以看下面的考慮。
2. 公平性與評判方便：
為什麼問公平性呢，這是因為不同語言的運行環境、編譯原理等什麼的都不一樣。無法給出一個完整的時間換算公式。比如區域賽中的c給1s而java給5s，可是不同的演算法c和java的運算效率的倍數是會動態變化的，所以這樣對c及java語言的某一方可能會不公平。
類庫不一樣，比如有的演算法一種語言有庫直接可以調用，另外一種卻要去實現，這樣也會造成不公平。記得08年杭州賽區當時有道題就java有演算法直接可以調，然後評委臨時規定用java的不可以直接調這個函數。
上面兩點也無形中表明如果多種語言的話評判也會很難。
如果你說不支持其他語言不公平的話，要知道到這個級別的，一般c語言是都應該會的。而且它的運行效率高，以及用的比較早，所以就繼續嘍。
以上只是我個人的分析，你覺得不合理的話請指出，應該也許還會有其他因素影響。你自己也可以去想。或者你可以問中國為什麼不改革腐敗呢，可是這些也不是我們所能決定的。