最新

也就是说，如果我从我的大型语言模型（LLM）的训练数据中省略所有小说和非小说类内容，那么这个LLM解决科学问题的能力是否会比另一个LLM更强？ 换句话说，一个像科学家一样训练的LLM，是否真的是一个更好的“科学”LLM？

我一直在思考，为什么我们没有一个只接受欧盟境内托管网站的 Chrome 分支？如果一个网站托管在欧盟境内，那么它就可以完全受到欧盟的监管。 这将使公民更容易知道他们的数据是安全的（根据欧盟标准），并避免了在其他国家强制执行规则的监管复杂性。 想法？

我编写了一个 Linux 命令行工具，使用 AES-256-GCM 加密和解密文件夹。它还能隐藏文件和文件夹名称，并将映射存储在一个加密文件中。 代码仓库：https://github.com/sahilPadmani/ACE-files-encryption

5月7日，Hyunwoo Kim (V4bel) 披露了 Dirty Frag——两个 Linux 内核漏洞（CVE-2026-43284 和 CVE-2026-43500），这些漏洞允许非特权用户在自 2017 年以来发布的大多数 Linux 发行版上获得确定的 root 权限。微软在第二天确认了主动利用行为。<p>我们在 Firecracker 微型虚拟机上构建 declaw.ai——用于 AI 代理的沙盒基础设施。我们运行着我们不编写且无法预测的不可信代码，因此当 Dirty Frag 出现时，我们的第一个问题是：我们的隔离边界是否牢固？我们在一颗故意<i>未打补丁</i>的内核上进行了测试。它保持了隔离。原因如下。<p>该漏洞利用是一个页面缓存写入原语：它欺骗内核覆盖任何文件（&#x2F;usr&#x2F;bin&#x2F;su, &#x2F;etc&#x2F;passwd）的内存内容，并提供 root 权限。完全确定，没有竞争条件。<p>为什么这对于多租户平台很重要：页面缓存由整个机器共享。容器共享宿主内核，命名空间隔离、seccomp 和已删除的权限都是由该内核强制执行的。内核漏洞利用不需要逃逸容器——它在容器隔离存在的层之下运行。与 Dirty COW (2016) 和 Dirty Pipe (2022) 存在相同的结构性问题。在零日漏洞出现当天，在任何补丁存在之前，每个共享该内核的基于容器的沙盒都会暴露。打补丁是在事后关闭窗口；它无法提前关闭。<p>我们在两种环境中运行了公开的 PoC（ESP 路径，CVE-2026-43284）。<p>测试 1——容器沙盒（Docker，seccomp 开启，非特权 uid=1001，宿主内核 6.8.0）：非特权用户在 2 秒内获得 root 权限。Seccomp 处于活动状态，但没有帮助——所需的系统调用被配置文件允许。拥有 root 权限后，我们读取了 &#x2F;etc&#x2F;shadow、宿主内核启动参数和 Docker overlay2 路径。<p>测试 2——Firecracker 微型虚拟机（未打补丁的客户内核，无 seccomp，以 root 身份启动，具有完全权限——有意比测试 1 更宽松）。该漏洞利用在客户机<i>内部</i>有效，但每次尝试访问宿主机的尝试都失败了：宿主内核不可见，宿主机进程不可见（客户机有自己的 kthreadd&#x2F;kswapd），所有宿主机端口都关闭，只有虚拟块设备，没有宿主机硬件身份。它损坏的页面缓存属于客户机自己的内核，通过 EPT 映射到宿主内存的受限区域。<p>不对称性是关键：微型虚拟机以比容器更高的权限启动，但仍然无法访问宿主机。重要的是软件授予的权限，而不是内核是否被共享。要逃逸 Firecracker，您需要在 VMM（约 5 万行 Rust 代码）或 KVM 中找到一个漏洞；谷歌的 kvmCTF 为客户机到宿主机的逃逸支付 25 万美元，并且只有一次被公开演示。<p>如果您运行多租户的不可信代码，任何隔离提供商的问题是：如果沙盒内的代码获得 root 权限，它是否可以访问宿主机或其他租户？如果答案是“只要我们打了补丁”——这就是差距。<p>PoC：https:&#x2F;&#x2F;github.com&#x2F;V4bel&#x2F;dirtyfrag 完整说明（命令 + 输出）：https:&#x2F;&#x2F;declaw.ai&#x2F;blog&#x2F;dirty-frag-microvm-isolation