FFMとJVMの実装から学ぶJavaのインテグリティ

Transcript

1. 2025/11/15 数村憲治 © 2025 Fujitsu Limited JJUG CCC Fall 2025 @kkzr FFMとJVMの実装から学ぶ Javaのインテグリティ
2. © 2025 Fujitsu Limited アジェンダ ネイティブコードとのI/F メモリ安全性 Javaのインテグリティ サマリ 2
3. © 2025 Fujitsu Limited 自己紹介 Jakarta EE 仕様策定委員 MicroProfile ステコミ委員 JCP Executive Committee メンバー Eclipse Foundation ボードディレクター OCX、Adoptium Summit、JakartaOneなどで登壇 Adoptium ステコミ委員 3
4. © 2025 Fujitsu Limited アジェンダ ネイティブコードとのI/F メモリ安全性 Javaのインテグリティ サマリ 4
5. © 2025 Fujitsu Limited Write Once Run Anywhere の理念 OS・ハード Java VM アプリケーション pure Java JDKライブラリ (Java) JDKライブラリ (ネイティブ) ネイティブI/F 5
6. © 2025 Fujitsu Limited Write Once Run Anywhere の現実 OS・ハード Java VM アプリケーション Java + JNI JDKライブラリ (Java) JDKライブラリ (ネイティブ) ネイティブライブラリ (PF依存) ネイティブI/F ネイティブI/F 6
7. © 2025 Fujitsu Limited © 2025 Fujitsu Limited ネイティブ I/F の用途 性能向上 JDKが提供していない OS機能の利用 (ネットワーク系等) 特殊なデバイス操作 (認証デバイス等) 現在ではJITの性能が向上し ネイティブを使わない方がよい 現在ではかなり充実している 現在もネイティブは必要だが レアケース ネイティブの必要性は、ほぼない(つい最近まで) 7
8. © 2025 Fujitsu Limited © 2025 Fujitsu Limited ネイティブの新たな要件 AI領域におけるJavaの期待で新たなネイティブ I/F が必要 GPUプログラミング CUDAなどのネイティブライブラリへのアクセス JCudaなどもあるが。。。 BabylonでJavaからのアクセスができるようになるが。。。 8
9. © 2025 Fujitsu Limited JNIの危険性 Cコード public native void foo(); void bar() { foo(); } JNIEXPORT void JNICALL Java_Hello_foo (JNIEnv env*, jobject o) { // なんでもありのコード } Javaコード できることが限られている 危険なことができない ランタイムが安全性を確保 なんでもできる 意図せず危険になる プログラマが安全性を確保 支配 プログラミングは自由主義が優位 JNI 制約の世界 自由の世界 9
10. © 2025 Fujitsu Limited FFMの安全性 JNI JNI FFM アプリケーション Java ランタイム OS・ハード Javaコード Cコード ネイティブ ライブラリ FFM 実装コード ネイティブ ライブラリ FFM API Cコードを排除し、Javaランタイムが安全性を確保 Javaコード 10
11. © 2025 Fujitsu Limited FFM で実現するメモリ安全性 var layout = MemoryLayout.sequenceLayout(3,ValueLayout.JAVA_BYTE); var arena = Arena.global(); var array = arena.allocate(layout); var b2 = array.getAtIndex(ValueLayout.JAVA_BYTE, 2); var b4 = array.getAtIndex(ValueLayout.JAVA_BYTE, 4); IndexOutOfBoundsException 主な手段は､ArenaとMemoryLayout 安全とは､解放チェック､型チェック､境界チェック 境界チェックの例 本セッションでは 境界チェックと MemoryLayoutに フォーカス 11
12. © 2025 Fujitsu Limited MemoryLayoutの例 // 'struct msghdr' defined at "socket.h" MemoryLayout MSGHDR = MemoryLayout.structLayout( ValueLayout.ADDRESS.withName("msg_name"), ValueLayout.JAVA_INT.withName("msg_namelen"), MemoryLayout.paddingLayout(4), ValueLayout.ADDRESS.withName("msg_iov"), ValueLayout.JAVA_INT.withName("msg_iovlen"), MemoryLayout.paddingLayout(4), ValueLayout.ADDRESS.withName("msg_control"), ValueLayout.JAVA_INT.withName("msg_controllen"), ValueLayout.JAVA_INT.withName("msg_flags") ); 手動で正確に作成するのはかなりめんどう 12
13. © 2025 Fujitsu Limited jextract が使える例 #include <netdb.h> struct addrinfo hints; hints.ai_family = AF_UNSPEC; import ccc.*; var layout = addrinfo.layout(); var seg = Arena.global().allocate(layout); addrinfo.ai_family(seg, netdb_h.AF_UNSPEC()); $ jextract --output ccc ¥ --target-package ccc ¥ /usr/include/netdb.h Cコード FFMコード 13
14. © 2025 Fujitsu Limited C言語での配列アクセスの例 struct array { int len; char data[0]; } *a; int len = 5; a = malloc(sizeof(struct array) + len); a->len = len; a->data[2] = 100; 定義範囲を超えたアクセスだが、 プログラマの意図としては正しい・想定アクセス 14
15. © 2025 Fujitsu Limited © 2025 Fujitsu Limited FFMの限界 FFMではC言語でできる危険なメモリアクセスも可能 C言語では、キャスト、配列の範囲外アクセスなどは 精巧に扱えば安全に使える FFMでは、精巧に扱っているかどうか、 文法的・記号的・機械的に判断できない 15
16. © 2025 Fujitsu Limited アジェンダ ネイティブコードとのI/F メモリ安全性 Javaのインテグリティ サマリ 16
17. © 2025 Fujitsu Limited NSAがメモリアクセスガイドラインをリリース https://www.nsa.gov/Press-Room/News-Highlights/Article/Article/3215760/nsa-releases-guidance-on-how-to-protect-against-software-memory-safety-issues/ 17
18. © 2025 Fujitsu Limited メモリ安全な言語を推奨 https://media.defense.gov/2022/Nov/10/2003112742/-1/-1/0/CSI_SOFTWARE_MEMORY_SAFETY.PDF Commonly used languages, such as C and C++, provide a lot of freedom and flexibility in memory management while relying heavily on the programmer (後略) NSA recommends using a memory safe language when possible. Examples of memory safe language include Python®, Java®, C#, Go, Delphi/Object Pascal, Swift®, Ruby , Rust®, and Ada. (中略) (中略) 18
19. © 2025 Fujitsu Limited © 2025 Fujitsu Limited メモリ安全な言語とは メモリ安全な言語が解決すべきメモリ問題 バッファオーバーフロー メモリリーク 領域解放後のメモリアクセス・二重解放 未初期化データのアクセス レースコンディション 19 Javaは実現できている？
20. © 2025 Fujitsu Limited 例：JVMでの配列インデックスチェック arrayOopDesc内に’length’の定義はないが。。。 // The layout of array Oops is: // // markWord // Klass* // ・・・ // length // ・・・ class arrayOopDesc : public oopDesc { ・・・ https://github.com/openjdk/jdk25u/blob/fcece2ecb1700a73ff9778b13d45b217c322c111/src/hotspot/share/oops/arrayOop.hpp 20
21. © 2025 Fujitsu Limited C言語での配列アクセスの例 (再掲) struct array { int len; char data[0]; } *a; int len = 5; a = malloc(sizeof(struct array) + len); a->len = len; a->data[2] = 100; 定義範囲を超えたアクセスだが、 プログラマの意図としては正しい・想定アクセス 21
22. © 2025 Fujitsu Limited © 2025 Fujitsu Limited メモリ安全な言語は安全なのか？ Even with a memory safe language, memory management is not entirely memory safe. Most memory safe languages recognize that software sometimes needs to perform an unsafe memory management function to accomplish certain tasks. メモリ安全な言語を使えばメモリ管理が安全になるとは限らない https://media.defense.gov/2022/Nov/10/2003112742/-1/-1/0/CSI_SOFTWARE_MEMORY_SAFETY.PDF 22 Javaでは、JNI/FFM/sun.misc.Unsafeなどが該当
23. © 2025 Fujitsu Limited アジェンダ ネイティブコードとのI/F メモリ安全性 Javaのインテグリティ サマリ 23
24. © 2025 Fujitsu Limited © 2025 Fujitsu Limited CIA(セキュリティの３要素) 秘匿性 Confidentiality 完全性 Integrity 可用性 Availability 24
25. © 2025 Fujitsu Limited © 2025 Fujitsu Limited プログラムコードでのIntegrity プログラムコード中、常に正しいとされる属性 Invariantが言語・ランタイムで保証されること プログラマーがその正しさをいちいち検証しなくてよい Invariant Integrity Invariant 25
26. © 2025 Fujitsu Limited 例：クラスのInvariant public class Even { private int x = 0; public int value() { return x; } public void increment() { x += 2; } public void decrement() { x -= 2; } } Invariant: ‘x’ の値は常に偶数である カプセル化(encapsulation)により実現 Integrity Invariantではない 26
27. © 2025 Fujitsu Limited © 2025 Fujitsu Limited JavaのIntegrity Invariant 配列の範囲外アクセスがないこと use-after-free がないこと データ(フィールド変数)が初期化されていること 実行時の型安全性 ・・・ 言語仕様として規定されている 27
28. © 2025 Fujitsu Limited Java VM でのチェック カプセル化によるJavaのIntegrity Java VMが カプセル化 の役割 メモリ Java コード Java コード Java コード 28
29. © 2025 Fujitsu Limited カプセル化をバイパスする危険機能 Java VMが カプセル化 の役割 Java VM でのチェック メモリ Java コード Java コード Java コード JNI / FFM / sun.misc.Unsafe 29
30. © 2025 Fujitsu Limited ソフトウェアサプライチェーンセキュリティ コーディング ビルド パッケージ ディプロイ 悪意のあるコード を含むパッケージ が配布される 偽のパッケージをアップ 配布サイトの攻撃 30
31. © 2025 Fujitsu Limited Adoptium / Temurin コーディング ビルド パッケージ ディプロイ 信頼できるJDK OpenJDK ・リプロデューシブルビルド ・SBOM ・電子署名 ・・・・ Temurin プロジェクトは SLSA Level 3 31
32. © 2025 Fujitsu Limited Adoptium Working Group AdoptiumメンバーはTemurinと同等の信頼できるJDKを提供 Temurinの技術はAdoptiumメンバーで開発・共有 32
33. © 2025 Fujitsu Limited 複雑な依存関係・エコシステム Dependency Dependency JDK Trusted Dependency Dependency Java Application Dependency Dependency JNI/FFM OS UnTrusted Danger UnTrusted UnTrusted UnTrusted UnTrusted UnTrusted 33
34. © 2025 Fujitsu Limited OSSは必ずしも信頼できない https://x.com/Cryolite/status/1774300154566455736 https://xkcd.com/2347/ xz-utils 事件 OSSにバックドアが仕込まれる 34
35. © 2025 Fujitsu Limited © 2025 Fujitsu Limited 危険な機能の注意喚起 Some languages require anything memory unsafe to be explicitly annotated as such to make the programmer and any reviewers of the program aware that it is unsafe. https://media.defense.gov/2022/Nov/10/2003112742/-1/-1/0/CSI_SOFTWARE_MEMORY_SAFETY.PDF NSAガイドライン 危険機能を使う場合は使っていることがわかるようにする Java: Integrity by Default 35
36. © 2025 Fujitsu Limited © 2025 Fujitsu Limited JEP draft : Integrity by Default https://openjdk.org/jeps/8305968 デフォルトで危険機能を使えない、 あるいは、使った場合に警告がでる 関連するJEP JEP 261: Module System JEP 260: Encapsulate Most Internal APIs JEP 396: Strongly Encapsulate JDK Internals by Default JEP 403: Strongly Encapsulate JDK Internals JEP 451: Prepare to Disallow the Dynamic Loading of Agents JEP 498: Warn upon Use of Memory-Access Methods in sun.misc.Unsafe JEP 471: Deprecate the Memory-Access Methods in sun.misc.Unsafe for Removal JEP 472: Prepare to Restrict the Use of JNI JEP 500: Prepare to Make Final Mean Final 36
37. © 2025 Fujitsu Limited © 2025 Fujitsu Limited 例：JNI / FFMでの注意喚起 JNI FFM WARNING: A restricted method in java.lang.System has been called WARNING: java.lang.System::loadLibrary has been called by JNI in an unnamed module (file:/tmp/) WARNING: Use --enable-native-access=ALL-UNNAMED to avoid a warning for callers in this module WARNING: Restricted methods will be blocked in a future release unless native access is enabled WARNING: A restricted method in java.lang.foreign.MemorySegment has been called WARNING: java.lang.foreign.MemorySegment::reinterpret has been called by FFM in an unnamed module (file:/tmp/) WARNING: Use --enable-native-access=ALL-UNNAMED to avoid a warning for callers in this module WARNING: Restricted methods will be blocked in a future release unless native access is enabled 37
38. © 2025 Fujitsu Limited Integrity by Def. による最適化の向上 constant folding public class Foo { final int bar; Foo foo = ・・・ if (foo.bar == n) { ・・・ tree shaking public class Foo { private void unused(); 現在はJNI/Unsafe/deep reflectionの可能性により最適化不可 38
39. © 2025 Fujitsu Limited アジェンダ ネイティブコードとのI/F メモリ安全性 Javaのインテグリティ サマリ 39
40. © 2025 Fujitsu Limited サマリ FFMはJNIより安全だが、依然、使い方の注意が必要 依存ライブラリがFFMなど危険機能を使っている場合、 警告を無視せず、受け入れ可否判断が必要 Integrityがプログラム言語に課されつつある Javaでは動作変更ラッシュが続く サマリ 40
41. © 2025 Fujitsu Limited © 2025 Fujitsu Limited Question? 41
42. © 2025 Fujitsu Limited © 2025 Fujitsu Limited Thank You