Alex的技术博客

AFPS（Apple File System）是 Apple 平台上使用的默认文件格式。APFS 继承自 HFS+，因此其设计的某些方面有意遵循 HFS+ 以便于历史数据的迁移。 Apple File System 支持对容器、卷和文件使用的数据结构进行加密。当一个卷被加密时，它的文件系统树和该卷中的文件内容都被加密。根据设备的能力，苹果文件系统使用硬件或软件加密： * 硬件加密：用于支持硬件加密的设备的内部存储，包括macOS(带T2安全芯片)和iOS设备。 当使用硬件加密时，只有内核（安全隔区）可以与内部存储交互。 既支持 FDE 单密钥模式，也支持 FBE 多密钥模式。

长期以来 Apple 公司有两条数据安全的技术演进路线，iPhone 和 iPad 等智能终端设备使用称为数据保护（Data Protection）的文件加密方法，基于Intel的Mac设备通过文件保险箱（FileVault）的宗卷加密技术。 MacOS 和 iOS 都是基于 FreeBSD 发展而来，基础架构是一个多用户的操作系统，但 iPhone 等作为个人化（无需支持多用户）的终端设备，存储了通信录、照片等非常敏感的隐私数据，对数据保护的要求更高；其次，App Store 和 iCloud等云服务大量出现，在网络开放环境下既要支持便利的后台服务管理，又要解决数据迁移过程中的数据保护，对

Apple 起家的产品是个人电脑，操作系统是基于 BSD 的定制化Linux，使用的是 MFS 文件系统。 1985年，Apple 发布了 HFS（Hierarchical File System）作为专用的文件系统，后续改进推出了 HFS+（扩展日志式）。HFS 的设计理念源自软盘和磁盘设备时代，为此饱受开发者吐槽，甚至被 Linus 痛斥为有史以来最烂的文件系统，突出的问题有以下几个方面： * 大小写不敏感（最新版本已支持大小写敏感，但默认配置仍未不敏感） * 不支持对数据内容进行 checksum 校验 * timestamp 只支持到秒级 * 不支持并发访问，不支持快照，不

FileVault 的意思是文件保管箱，是 Apple 公司为 Mac 电脑提供的、基于 MacOS 的加密技术方案，其本质归类于 FDE（Full Disk Encryption，全盘加密）。 注意！与之对应的，为 iPhone 提供的、基于 iOS 的 DataProtect （数据保护）加密技术方案，其本质归类于 FBE（File Based Encryption，文件加密）。 一、Legacy FileVault 2003年，Mac OS X Panther (黑豹，10.3) 首次发布了 FileVault，当时的版本只加密了用户的主目录（不包含启动宗卷），方法是采用一个巨大的稀疏

一、背景 研究分组密码工作模式的核心是机密性保护（Confidentiality），历史上曾经将完整性保护（Integrity，例如在某些数据被修改后的情况下密码的误差传播特性）也一并纳入设计目标，但在发现兼顾两个设计目标的难度之后，密码学社区已经普遍将完整性保护作为另一个完全不同的，与加密无关的密码学目标，并开始研究专门的认证加密模式（AE，Authenticated Encryption）。 在密码学中，消息验证码（MAC，Message Authentication Code，也称为标签Tag）是用于验证消息的一小段信息。换句话说，用于确认消息来自指定的发送者（其真实性）并且没有被篡改

LaTex 是一个创建专业文档的工具，在各类科学文献中得到了广泛的使用。它不仅可以创建出有着漂亮排版的文档，还可以让用户非常方便的处理排版中非常复杂的一些问题，例如输入数学公式、创建表格、引用、参考文献，以及全文统一的格式。 LaTeX 是一种排版语言，并非所见即所得，而是基于 What You See Is What You Mean 的理念，用户需要输入特定的代码，保存在后缀为.tex的文件中，通过编译得到所需的pdf文件。 配置方法 Hexo博客中支持复杂数学公式的渲染，MathJax 和 KaTeX 是两个常见的渲染引擎。 MathJax是一个开源JavaScript库。它支持La

AES-XTS 的设计目标是解决磁盘文件的加密存储需求。 ECB 模式存在明文攻击问题，磁盘文件中经常存在内容相同的分组，显然不适用。其他分组密码工作模式也有两个难题无法解决，一是如何存储初始向量IV，二是如何支持随机存取。 CBC、CFB 和 OFB 模式都需要初始向量，因此每个文件都需要额外的空间用于存储 IV，不仅增加磁盘开销，而且破坏了明文和密文在扇区存储上的对应关系，给底层技术实现带来了很大麻烦。 CBC、CFB 和 OFB 模式的分组之间存在依赖关系，不能实现完全的并行计算（CBC、CFB 模式仅支持解密的并行计算，并需要额外读取上一个分组的密文；OFB 模式完全不支持并行计算

原本 HEXO v5.4.2 基于 node v12 版本，但最近个别组件出现安全告警要求强制升级，但新版本的组件依赖 node v14 版本，只好再次升级。 其中一个开发设备是古老的 Mac 一体机，通过 node 官网下载 v18 的 pkg 安装包，运行异常退出，核查原因是操作系统版本是 High Sierra 10.13（最后一个支持32位App的版本，告别了僵尸大战！），被迫升级到 Catalina 10.15，经过好几番折腾，最后完成情况如下： node：最新版本 v20，LTS 版本 v18 npm：9.8.1 Hexo：6.3 Next：8.18.2 package.j

一、概述 cloud-init 最初由 ubuntu 的母公司 Canonical 开发，基本设计思路是： * 当用户首次创建虚拟机时，将前台设置的主机名，密码或者秘钥等存入后台的元数据服务器 - metadata server * 当 cloud-init 随虚拟机启动而运行时，通过 http 协议访问 metadata server * 虚拟机根据预设的元数据信息修改主机配置，从而完成系统的环境初始化 目前大部分公有云（openstack, AWS, Aliyun）都在使用 cloud-init , 已经成为事实的工业标准。 开源代码： https://github.com/cl

一、概述 与 ntp 相比，chrony 是一种相对较新的时间同步工具，具有以下特点： * 采用一种称为”时间滤波”的技术，通过估计时钟漂移率，平滑时钟跳变和抖动，来提高时钟同步的精度和稳定性 * 支持本地时钟缓存，在没有网络连接时依然保持时钟的精度，还支持快速时钟校准和实时时钟补偿等功能 * 系统资源的消耗相对较少，配置相对简单更加易于管理 Chrony 有两个核心组件： * chronyd：守护进程，主要用于调整内核中运行的系统时间和时间服务器同步 * chronyc：客户端，它提供一个用户界面，用于监控性能并进行多样化的配置 二、服务器的配置方法 1. 安装方法 Cen