[科技知识] macOS Sonoma 14.4 更新引发 Java 程序崩溃，这对用户使用有何影响？

天天财汇购物网址万年历小说 | 三峰软件小游戏视频

TxT小说阅读器
↓小说语音阅读,小说下载↓

一键清除系统垃圾
↓轻轻一点,清除系统垃圾↓

图片批量下载器
↓批量下载图片,美女图库↓

图片自动播放器
↓图片自动播放,产品展示↓

首页淘股吧股票涨跌实时统计涨停板选股股票入门股票书籍股票问答分时图选股跌停板选股 K线图选股成交量选股 [平安银行]

股市论谈均线选股趋势线选股筹码理论波浪理论缠论 MACD指标 KDJ指标 BOLL指标 RSI指标炒股基础知识炒股故事

商业财经科技知识汽车百科工程技术自然科学家居生活设计艺术财经视频游戏--

天天财汇 -> 科技知识 -> macOS Sonoma 14.4 更新引发 Java 程序崩溃，这对用户使用有何影响？ -> 正文阅读

[科技知识]macOS Sonoma 14.4 更新引发 Java 程序崩溃，这对用户使用有何影响？

[收藏本文] 【下载本文】

IT之家 3 月 17 日消息，甲骨文公司称，最新发布的 macOS Sonoma 14.4 版本存在漏洞，会导致运行 Java 程序的进程意外终止。…

快去请圆胖肿佛祖！

很多人没搞懂到底是什么东西被破坏了导致JVM崩溃。
Apple Silicon上macOS的内核强制执行W^X政策（Write XOR Excutable)，也就是一页内存要么是可写入的，要么是可执行的，通常这种内存是用来实现JIT的。
执行W^X政策的原因是，同时可写入和可执行很容易产生远程代码执行（RCE）的漏洞。
在Apple Silicon的macOS上要执行JIT代码，必须按照如下规则调用API
调用mmap(addr, len, PORT_WRITE|PORT_READ, MAP_ANON|MAP_PRIVAYE|MAP_JIT, -1, 0)创建匿名内存页，注意MAP_JIT是苹果的非POSIX标准扩展，不带这个就无法使页变为可执行调用pthread_jit_write_protect_np(false)，使当前线程的页表中MAP_JIT的页变为可写入状态写入机器指令到目标内存页中调用pthread_jit_write_protect_np(true), 使当前线程的页表中目标内存页可执行调用sys_icache_invalidate(addr, len)清除L1 icache, 因为ARM处理器上L1 icache和dcache不是缓存一致的现在目标内存页的代码可以执行了
在苹果的设计里， 2-4的持续时间应当是尽可能短的，因此还设计了如下api

typedef int (*pthread_jit_write_callback_t)(void *);
int pthread_jit_write_with_callback_np(pthread_jit_write_callback_t callback, void *ctx);

也就是将写入jit指令代码的逻辑放入callback中，由这个api翻转页表的状态。在启用了安全强化运行时之后(Hardened Runtime)，只能通过该api翻转页表状态，而且还必须声明允许的callback指针。

PTHREAD_JIT_WRITE_ALLOW_CALLBACKS_NP(jit_writing_callback)

macOS Sonoma 14.4的变化是，当调用pthread_jit_write_protect_np(false）之后，如果当前线程产生SIGBUS/SIGSEGV, 信号处理函数不会运行，整个进程会被SIGKILL杀掉。
那么，正确情况下JVM的判空优化会产生如上场景吗，不会的。理论上要进行判空优化的Java代码已经被JIT了，处于pthread_jit_write_protect_np(true)的状态下才能执行JIT代码的，这时候发生页故障会正确的产生SIGBUS/SIGSEGV, 被信号处理函数处理。
为什么在pthread_jit_write_protect_np(false）的线程产生页故障应当直接杀掉呢，因为信号处理函数可能会在任何线程执行，而那个线程的JIT页可能是可写的，也可能是可执行的，信号处理函数并没有办法判断那个线程的状态。此外，作为一种安全机制，在写入机器码时发生页故障本身就证明JIT机制出现了问题，没有严格的遵守pthread_jit_write_protect_np调用后仅进行写入操作的逻辑，这种情况下恢复执行存在安全风险。
本质上，这个并非是苹果破坏了SIGBUS/SIGSEGV的Unix语义，而是Hotsopt在该写入JIT机器码的时候却产生了页故障，而这种情况被苹果认为是不安全的。
实际上，Hotspot完全选择了相反的语义，即大部分时候处于可写入的状态，直到必须时再进入执行状态。
我们目前采用的 WX 内存保护方法是默认启用“写入”并根据需要启用“执行”。
我认为我们还应该尝试翻转这一点，并尝试默认使用“执行”运行，并根据需要打开“写入”。
这将为我们提供更好的覆盖范围并刷新更多代码路径，从而对我们的“打鼹鼠”方法更有信心。
很显然，这种做法完全没有起到防止恶意代码执行的目的。
不过这并没有解释为什么非JIT代码产生了页故障，以及为什么过去信号处理函数能从这种页故障恢复。
强化对页表的安全管理并非是苹果的一家之言，在iOS上页表必须强制签名且只有浏览器进程可以进行JIT，微软Xbox和OpenHarmonyOS也对可执行页强制签名，微软甚至禁用了使用Chromium内核的Edge浏览器的JIT功能，OpenHarmonyOS也只允许浏览器进程可以进行JIT。
像HotSopt这样代码逻辑混乱的代码本来就不应该被允许。
当然，本回答不代表认可Apple在正式版上线未经测试的代码的操作，以及破坏第三方配件兼容性的行为。

看到这个新闻，又看了看我刚升级14.4的MacOS版本号，心想这也升级了好几天了，怎么开发Java没遇见这个新闻里说的Bug呢。
于是去看了看Oracle的官方博客怎么说的Java users on macOS 14 running on Apple silicon systems should consider delaying the macOS 14.4 update (oracle.com)

并没有说Intel芯片的苹果设备会受影响
哦，原来是俺太穷，还没更新到Apple Silicon的设备（狗头）
不过现在正在用Apple Silicon做开发的，又恰好喜欢像我一样很喜欢尝鲜最新软件版本的Java程序员们，应该确实有点烦燥了。
Oracle的官方博客明确说明影响范围是Apple Silicon的设备，但是IT之家的新闻好像在有意弱化这个重点，我最开始没有留意，以为IT之家压根没提这个点，后面发现在正文里还是提了一句，说明影响的范围只是Apple Silicon。
不知道是无心之失，还是有意把标题改一个“貌似看起来影响更大”的大新闻。
我不大喜欢处处封闭且从不在意MacOS升级系统向后兼容性的苹果。但是国内媒体转载新闻都转载得不精准，又比苹果的敬业态度强到哪里去呢，嗨~
如果苹果有点良心，个人希望是苹果来做hotfix吧，这个问题反正不管谁来修复，最终总会解决的。
但如果最后是Java8~Java22全产品线hotfix适配ARM版Sonoma 14.4+，那苹果的生态统治力就又一次刷新我的概念了。

有人指出苹果的行为没有违反语义，我没有完整阅读过这个 spec，稍微引用下，若是引用错了还望指出：
https://pubs.opengroup.org/onlinepubs/9699919799/functions/V2_chap02.html#tag_15_08_03_03
Memory Protection
When an object is mapped, various application accesses to the mapped region may result in signals. In this context, SIGBUS is used to indicate an error using the mapped object, and SIGSEGV is used to indicate a protection violation or misuse of an address:
- A mapping may be restricted to disallow some types of access.
- Write attempts to memory that was mapped without write access, or any access to memory mapped PROT_NONE, shall result in a SIGSEGV signal.
- References to unmapped addresses shall result in a SIGSEGV signal.
- Reference to whole pages within the mapping, but beyond the current length of the object, shall result in a SIGBUS signal.
- The size of the object is unaffected by access beyond the end of the object (even if a SIGBUS is not generated).
---- The Open Group Base Specifications Issue 7, 2018 Edition
根据上文引用的句子「mapped without write access」「References to unmapped addresses」，你说破大天它也得是 SIGSEGV。
谣言满天飞。苹果的新版本在一个和 JIT 相关的边缘情况下，对非法内存访问发了 SIGKILL 信号，按 POSIX 规范应该是 SIGBUS/SIGSEGV。
许多程序，都要利用这个信号做兜底处理，甚至是实现主要功能，这也是这个信号存在的意义。Java 的话，JIT 利用这个信号对判空做了优化，所以在这个情况下就遇到了问题，会导致 JVM 直接闪退，没有任何有效的 workaround。
这倒不是什么漏洞，这个问题主要是 Apple 破坏了 API 的兼容性（信号也是 API 的一部分，这是这个信号的正常用法，这是 POSIX 里明确规定的），但是却没有提前在测试预览中包含，大大地坑了下 Java。
至于很多人复现不出来，或者别的语言 runtime 没出事，主要是因为这个变更仅涉及 JIT 下的一个边缘情况，Java 也只会在触发 JIT 优化的特定情况下踩坑。

崩溃原因是jvm为了提升性能没做空指针判断，而是访问到空指针时通过拦截sigsegv信号再抛java异常。
mac觉得在访问受保护内存时发能拦截的信号很容易给扫内存的恶意代码可乘之机，然后把发的信号改成了sigkill。从安全角度mac这点做的我觉得没问题。
但没有广泛验证就直接推正式版就是苹果的问题了

MACOS这质量还嘲笑WINDOWS？？ ^_^

有一说一，这玩儿要是按着安全设计原则来讲，锅在java那边。
但微软更新补丁导致打印机共享失效，hp官方得解决方案都是卸载微软补丁。
mac这么搞，大家买mac还图啥。。。

我现在就是m1芯片+最新系统，用Intellij IDEA时候会无故闪退，巨烦。

Java 乱用危险 API 去做事，遭报应了。
恶意写入被保护的内存被操作系统拒绝。
现在操作系统直接噶了你。
我升级到 macOS 14.4 没有遇到 JVM 被强制嘎掉的问题。
关闭 SIP（系统完整性保护）JVM 并没有被强制终止。
暂时不知道 Apple 到底为什么调整的这些相关内容。

可惜乔帮主已经不在了。
不然得来一篇《关于Flash的思考》的姊妹篇：《关于Java的思考》。

怪不得最近clion总是莫名其妙闪退？