📸 @oshito_2023 #YEJI ×3
\ ✨ 応援広告紹介✨/
韓国・バス停広告にて、
YEJI の応援広告が掲載されています✨
主催：@ITZY_yeji_JP 様
掲載期間：2026年5/15〜6/14
掲示場所：강동보건소건너 25-284
韓国を訪れるMIDZYの皆さんはぜひチェックしてみてください📸💛
\ ✨ 配套广告介绍✨/
在韩国的一个公交车站广告中，
YEJI 的支持广告已发布✨
赞助者：@ITZY__yeji_JP
发布时间：2026年5月15日至6月14日
发帖地点: 강동보건소건너 25-284
所有来韩国的MIDZY请查看📸💛 #ITZY #YEJI #ITZY #있지 #예지 #ITZY_YEJI #응원광고 #センイル広告 #韓国広告 #KPOP応援広告
原文 #黄礼志
\ ✨ 応援広告紹介✨/
韓国・バス停広告にて、
YEJI の応援広告が掲載されています✨
主催：@ITZY_yeji_JP 様
掲載期間：2026年5/15〜6/14
掲示場所：강동보건소건너 25-284
韓国を訪れるMIDZYの皆さんはぜひチェックしてみてください📸💛
\ ✨ 配套广告介绍✨/
在韩国的一个公交车站广告中，
YEJI 的支持广告已发布✨
赞助者：@ITZY__yeji_JP
发布时间：2026年5月15日至6月14日
发帖地点: 강동보건소건너 25-284
所有来韩国的MIDZY请查看📸💛 #ITZY #YEJI #ITZY #있지 #예지 #ITZY_YEJI #응원광고 #センイル広告 #韓国広告 #KPOP応援広告
原文 #黄礼志
#News
🌃 Orien Daily 晚刊【5.21】
1️⃣ OpenAI模型推翻离散几何核心猜想 — AI数学突破
2️⃣ 恶意VSCode扩展入侵3800仓库 — 供应链安全问题
3️⃣ N tokens/s到底有多快？ — LLM推理速度体感
4️⃣ SpaceX首次公开财务数据 — 为6月上市铺路
5️⃣ Google I/O 2026发布100项更新 — Gemini Omni亮相
6️⃣ OlmoEarth v1.1地球观测模型 — AllenAI开源新模型
7️⃣ AI爬虫正让Wiki运维变难 — 社区基础设施承压
8️⃣ 血管炎药タブネオス致20人死亡 — 厂家发布蓝信警示
频道：@OrienDaily
🌃 Orien Daily 晚刊【5.21】
1️⃣ OpenAI模型推翻离散几何核心猜想 — AI数学突破
2️⃣ 恶意VSCode扩展入侵3800仓库 — 供应链安全问题
3️⃣ N tokens/s到底有多快？ — LLM推理速度体感
4️⃣ SpaceX首次公开财务数据 — 为6月上市铺路
5️⃣ Google I/O 2026发布100项更新 — Gemini Omni亮相
6️⃣ OlmoEarth v1.1地球观测模型 — AllenAI开源新模型
7️⃣ AI爬虫正让Wiki运维变难 — 社区基础设施承压
8️⃣ 血管炎药タブネオス致20人死亡 — 厂家发布蓝信警示
频道：@OrienDaily
#News
🌅 Orien Daily 朝刊【5.22】
1️⃣ Flipper One开发求助 — 社区求援
2️⃣ Antigravity暗藏陷阱 — 钓鱼手法
3️⃣ Anthropic秀编程未来 — AI编程走向
4️⃣ Waymo暂停高速运营 — 施工区问题
5️⃣ 索尼发True RGB TV — 5.28公布
6️⃣ AT&T起诉加州 — 欲关旧电话网
7️⃣ 是枝裕和谈AI — 想象力不可替
8️⃣ AI爬虫困Wiki — 抓取致运维难
@OrienDaily
🌅 Orien Daily 朝刊【5.22】
1️⃣ Flipper One开发求助 — 社区求援
2️⃣ Antigravity暗藏陷阱 — 钓鱼手法
3️⃣ Anthropic秀编程未来 — AI编程走向
4️⃣ Waymo暂停高速运营 — 施工区问题
5️⃣ 索尼发True RGB TV — 5.28公布
6️⃣ AT&T起诉加州 — 欲关旧电话网
7️⃣ 是枝裕和谈AI — 想象力不可替
8️⃣ AI爬虫困Wiki — 抓取致运维难
@OrienDaily
This media is not supported in your browser
VIEW IN TELEGRAM
📸 @YejiBrasil
[🎥] YEJI chegando para a pré-gravação do Music Bank
@ITZYofficial
[🎥] YEJI 抵达音乐银行预录制
@ITZY官方 #예지 #있지 #YEJI #ITZY
原文 #黄礼志
[🎥] YEJI chegando para a pré-gravação do Music Bank
@ITZYofficial
[🎥] YEJI 抵达音乐银行预录制
@ITZY官方 #예지 #있지 #YEJI #ITZY
原文 #黄礼志
Linux 内核里的 RCU：读不加锁，写不阻塞，凭啥？
说到并发控制，第一反应是锁——互斥锁、自旋锁、读写锁。但 Linux 内核里有个数据结构叫
听起来像是 Copy-on-Write，但关键区别在"等旧读者走完"这一步怎么判断。内核不会跟踪每个读者的进出（那等于又加了锁），而是引入了宽限期（grace period）的概念：一个 CPU 如果经历过了一次上下文切换或者一次 idle，就说明它已经离开了临界区——这叫静默状态（quiescent state）。当所有 CPU 都至少走过一次静默状态，宽限期结束，写者回调执行，把旧数据释放掉。
所以 RCU 的代价不是时间，是内存。旧版本的数据在宽限期内一直活着，读者各看各的，写者攒着回调等宽限期。这就解释了为什么 RCU 只适合读多写极少的场景——如果写频繁，内存累积的旧版本会炸。
实际代码里你会看到那如果宽限期里有个 CPU 一直不调度（比如跑着个死循环计算任务），RCU 回调是不是就一直挂着？是的，内核有个 机制会往这种 CPU 发 IPI 强制让它报告静默状态，甚至最终触发 CPU stall 警告。
RCU 在内核里用得极其广泛——从
#CS
说到并发控制，第一反应是锁——互斥锁、自旋锁、读写锁。但 Linux 内核里有个数据结构叫
struct rcu_head，对应一套完全不同的思路：RCU，Read-Copy-Update。核心想法很简单——读者啥锁都不拿，直接读；写者不原地改数据，而是拷贝一份修改后，等所有旧读者走完，再把指针切过去。听起来像是 Copy-on-Write，但关键区别在"等旧读者走完"这一步怎么判断。内核不会跟踪每个读者的进出（那等于又加了锁），而是引入了宽限期（grace period）的概念：一个 CPU 如果经历过了一次上下文切换或者一次 idle，就说明它已经离开了临界区——这叫静默状态（quiescent state）。当所有 CPU 都至少走过一次静默状态，宽限期结束，写者回调执行，把旧数据释放掉。
所以 RCU 的代价不是时间，是内存。旧版本的数据在宽限期内一直活着，读者各看各的，写者攒着回调等宽限期。这就解释了为什么 RCU 只适合读多写极少的场景——如果写频繁，内存累积的旧版本会炸。
实际代码里你会看到
rcu_read_lock() 和 rcu_read_unlock()，它们在非抢占内核下甚至不生成任何指令，直接编译成空操作，因为抢占禁用本身就是静默状态的边界。真正的开销全在写者一侧：synchronize_rcu() 等宽限期可能要几十毫秒，所以才有 call_rcu() 做异步回调。rcu_urgentRCU 在内核里用得极其广泛——从
hlist 遍历到 pid 查找到路由表更新，基本所有热路径的读端都在用它。Paul McKenney 为此维护了十几年，光论文就写了一堆。有意思的是这个思路不仅限于内核，用户态也有 liburcu，Meta 早期的系统里大量使用。#CS
黄金票据：一张伪造的通行证如何放倒整个域
想象这样一个场景：攻击者拿到了域控的最高权限，但你及时发现了，改了所有管理员密码，心想这下应该安全了——然而攻击者还在域里横着走，仿佛什么都没发生。这不是玄学，这是 Kerberos Golden Ticket 攻击。
Kerberos 认证的核心逻辑是：客户端向 KDC 申请票据，KDC 用只有自己知道的密钥签发 TGT，客户端拿着 TGT 去申请服务票据，整个过程信任链的根基就是 KDC 的 krbtgt 账户的密码哈希。Golden Ticket 的思路非常直接：如果你拿到了 krbtgt 的哈希，你就不需要再跟 KDC 打招呼了。你自己签 TGT，自己指定任意用户身份、任意组成员、任意票据有效期——KDC 看到这张票据，验签通过，就全盘接受。因为在 Kerberos 的设计里，krbtgt 的密钥就是信任的锚点，票据本身就是凭证，不存在二次校验。
这意味着几件让人不舒服的事：第一，即便域控已经被你重新加固，只要攻击者曾经拿到过 krbtgt 哈希并且没有被重置，他们就永远能伪造票据；第二，票据的有效期可以设成十年，比大多数企业的密码轮换周期还长；第三，伪造的用户可以是 Domain Admins 组成员，每一台机器都会认。
防御上最关键的一步是：重置 krbtgt 账户的密码，而且要连续重置两次 。为什么要两次？因为 Active Directory 在重置密码时，旧密码哈希会保留一次作为回退，攻击者用旧哈希签出的票据仍然有效，第二次重置才会彻底让旧哈希失效 。此外，域控的 krbtgt 密码在多域环境中每个域独立，需要逐域操作，不能漏。
整个攻击链本质上暴露的是 Kerberos 协议设计上的一个取舍：为了性能和可用性，票据一旦签发就是自包含的、离线可验证的，KDC 不维护票据状态表，也不主动撤销。这份"信任即凭证"的简洁，恰恰是黄金票据能成立的根因。
#Security
想象这样一个场景：攻击者拿到了域控的最高权限，但你及时发现了，改了所有管理员密码，心想这下应该安全了——然而攻击者还在域里横着走，仿佛什么都没发生。这不是玄学，这是 Kerberos Golden Ticket 攻击。
Kerberos 认证的核心逻辑是：客户端向 KDC 申请票据，KDC 用只有自己知道的密钥签发 TGT，客户端拿着 TGT 去申请服务票据，整个过程信任链的根基就是 KDC 的 krbtgt 账户的密码哈希。Golden Ticket 的思路非常直接：如果你拿到了 krbtgt 的哈希，你就不需要再跟 KDC 打招呼了。你自己签 TGT，自己指定任意用户身份、任意组成员、任意票据有效期——KDC 看到这张票据，验签通过，就全盘接受。因为在 Kerberos 的设计里，krbtgt 的密钥就是信任的锚点，票据本身就是凭证，不存在二次校验。
这意味着几件让人不舒服的事：第一，即便域控已经被你重新加固，只要攻击者曾经拿到过 krbtgt 哈希并且没有被重置，他们就永远能伪造票据；第二，票据的有效期可以设成十年，比大多数企业的密码轮换周期还长；第三，伪造的用户可以是 Domain Admins 组成员，每一台机器都会认。
防御上最关键的一步是：
整个攻击链本质上暴露的是 Kerberos 协议设计上的一个取舍：为了性能和可用性，票据一旦签发就是自包含的、离线可验证的，KDC 不维护票据状态表，也不主动撤销。这份"信任即凭证"的简洁，恰恰是黄金票据能成立的根因。
#Security