Orien Daily
- 📸 @wlFMIkYlwu43514
配信環境って自分はてっきり回線的な、通信速度的なもんと思ってましたが、まさか板から机作ってたとか...あらためて加藤小夏さんの偉大さに、あたしゃガツンと衝撃を喰らいましたよ。
っておもわずつぶやいたのであった。 #加藤小夏
原文 #加藤小夏 - 「～を余儀なくされる」：被迫无奈的学术表达
读论文的时候经常会碰到这个表达，比如「転換を余儀なくされた」，乍一看以为是什么高级被动形式，其实它的逻辑跟我们日常说的「不得不」完全不同。关键在于：余儀なくされる的主语是承受方，而不是施加方。你可以说「政策の転換を余儀なくされた」，但不能说「政府が転換を余儀なくした」——后者的意思是政府主动「让对方别无选择」，语感完全反了。这个区别在口语里不明显，写在论文里就是硬伤。
再往深一层想，这个句型其实暗含一种「本来不想这样，但客观条件不允许其他选择」的无奈感。和「～ざるを得ない」相比，「余儀なくされる」更有书面语的厚度，而且不需要接动词的否定形式，直接接名词就行：変更を、撤退を、見直しを。学术写作里用起来很干净。
那么问题来了——「余儀なく」的「余儀」原来是什么意思？ - 当算法变成后门：JWT 的 Algorithm Confusion 攻击
你登录了一个网站，服务器发给你一个 JWT，里面用 RS256（非对称签名）保护你的身份。看起来很安全——私钥在服务器手里，攻击者没法伪造签名。但问题是，很多 JWT 库在验证时做了一个"贴心"的设计：它们从 token 的 header 里读取alg字段，然后以此决定验证方式。攻击者只需要把 header 里的alg从RS256改成HS256，再用自己的公钥作为 HMAC 密钥对 payload 签名，服务器就会用公钥做 HMAC 验证——而公钥是公开的。一瞬间，非对称签名的安全假设被绕过了，攻击者可以用任意 payload 伪造合法 token。2015 年这个漏洞同时出现在至少五个主流 JWT 库里，包括 node-jws、ruby-jwt 和 python-jose。根本原因不是密码学出了问题，而是实现把"算法选择权"交给了不受信任的输入。修复方式很直接：验证时硬编码期望的算法，拒绝从 token header 动态读取。换句话说，。这个教训不仅适用于 JWT——任何安全协议里，如果验证逻辑依赖攻击者可控的元数据，类似的混淆攻击就必然存在。 - Linux 内核的
container_of宏：从指针倒推回结构体
读 Linux 内核源码的时候，你会在每一个角落碰到一个宏——container_of。它做的事情乍看像黑魔法：给你一个成员变量的指针，你就能拿回整个结构体的指针。听起来像是 C 语言在偷偷搞反射？
其实原理特别朴素。C 结构体在内存里是连续布局的，每个成员的偏移量在编译期就确定了。所以如果你知道某个成员的地址，再减去它相对于结构体起始位置的偏移，就回到了结构体的头部。container_of就是把这个减法封装成了一句宏。内核里到处是链表嵌入在各自的结构体中——list_head自己不承载数据，它被嵌进task_struct、inode、sk_buff等各种结构体里。遍历链表时你拿到的全是list_head *，要从它找回外层的task_struct，只能靠container_of。
这个设计反过来想更有意思：不是"结构体包含链表节点"，而是"链表节点嵌入结构体"。链表的实现完全不知道外面挂的是什么，它只管自己那几个next和prev指针。泛型不是靠模板、不是靠虚函数，而是靠把数据结构的所有权翻转过来实现的。这种内嵌式链表在内核里无处不在，从进程调度到内存管理到文件系统，全靠这一套。
宏的定义本身也有值得看的细节。第一步算偏移用的是((size_t)&((type *)0)->member)——把零地址强转成结构体指针再取成员地址，得到的值恰好就是偏移量，因为这个"结构体"从地址零开始。offsetofoffsetofoffsetof。
下次读内核代码看到container_of(ptr, struct task_struct, run_list)这种写法，就知道那不过是一次指针减法，背后藏着的是内核对数据结构关系的根本态度：谁包含谁，决定了代码怎么组织。 - 📸 @yukirir815 ×4
夜遅くに全肯定BOT達のためにいろいろと頑張ってくれていて感謝🙏✨
トラブルだったのに配信続けてくれて感謝！
近況報告や誕生日会のお話聞けて良かった！今日も推しはかわいいね〜
アーカイブあまり残らなそうなのでまだの人はお早めに😌 #加藤小夏
原文 #加藤小夏
