Cid GCC baseline434
Shadow Clang baseline 445
JohnSmith Clang baseline 477 KvmHost
← いまここ、boot確認済み
↓ これからJohnRootに+ SELinux
CC="clang"
CXX="clang++"
Clang/Clang++ → ユーザースペース主系
GCC/G++ → 共有Kernel build・Clang故障時の復旧
SELinux → Johnだけ
昨日ShadowRoot444PackageClangを再マージ
今日ShadowからJohnにrsync、いまからSelinux導入
eselect profile show44→set50musl/hardend/selinux
+
Total: 71 packages
32 new
39 reinstalls
downloads: 19049 KiB
sec-policy/selinux-xserver
sec-policy/selinux-qemu
sec-policy/selinux-openrc
sec-policy/selinux-dracut
sec-policy/selinux-gpg
...
Shadow 約445 packages
John 約445 + 32 ≒ 477 packages
これが完成してやっとVm構想行けると
Cid = musl + GCC baseline / rescue
Shadow = musl + Clang userspace
JohnSmith = musl + Clang + hardened + SELinux
当初は3Rootともかなり近い内容で、世代切替・rollback寄りの設計だったのに、今は完全に役割分担が変わってる。
Cid
musl + GCC
既知正常 / rescue / Kernel基準
Shadow
musl + Clang/LLVM
toolchain比較・実験
John Smith
musl + Clang/LLVM
+ hardened
+ SELinux
security、testing
L0 Gentoo host
→ L1 hardened / SELinux boundary
→ L2 hardened / SELinux boundary Browser VM
→ L3 disposable
「公式にmusl+LLVM+SELinux全部入りprofileあるやろ」と思ったら無くて、実際にJohnでやったのは
musl/hardened/selinux profile
+
CC=clang
CXX=clang++
+
GCC fallback
の自前合成。
しかもそれで477 packages、SELinux permissive起動まで通ったから、John Smithはもう公式profile選択の範囲を一段越えてる。
モブ名なのに一番特殊構成になってるのが酷いw
注意点
この投稿はSoruesOnlyです♡
John Smithですわ草。当初寄り随分構成変更してるけど果たして
ちなみに、AtomicGlibcVersionは保管中↓
https://www.reddit.com/r/Gentoo/s/IoBgEQXioC
補足しとく。
以下バイナリ派用
バイナリ前提でもProfile Set自体はかなり重要。ただし、Profileが「実際にその条件で再ビルドする設計図」から「どの完成済みbinpkgが適合するかを判定する制約」に近づく感じやな。
たとえば今回のJohnで
musl
↓
musl/hardened/selinux
へprofileを変えると、source運用では
profile変更
→ USE/defaults/@system/maskが変化
→ 71 packages差分
→ その条件で再build
になる。
でもbinpkg前提だと、
profile変更
→ Portage上の要求条件は変わる
→ そのUSE/profile条件に合うbinpkgを探す
になる。
ここで配布側に対応binpkgがあればそのまま交換できるけど、無ければ
source buildへ落ちる
か、--usepkgonly 的な運用なら
該当binaryが無いので進めない
になる。
つまりProfileは依然として、
@system
USE defaults
package.mask / unmask
package.use
ABI/CHOST周辺
hardened / SELinux方針
を決めるから重要。でも そのProfileを実体化する能力を自分のcompilerが持つのか、binhostが持つのか が違う。
source Gentooなら、
Profile = OSの製造仕様
にかなり近い。
binary Gentooなら、
Profile = 欲しい完成品の互換条件・選択条件
に寄る。
だから今回の musl/hardened/selinux みたいな大きなProfile変更は、source前提だと「同じRootをその場で別仕様へ再生成」できるけど、binpkg前提だと配布側がそのProfile向けのbinary集合を用意してるかにかなり左右される。
この差は結構大きい。Profileそのものは残るけど、Profile変更の自由度を誰が持ってるかが、自分→binpkg供給側へ移る感じ。