qemuとlapicとSMP環境
qemuでxv6のSMP対応の処理を追いかけていたらsmpオプションをつけているのに、lapicで1コア分しかapicidが取得できない事象が発生。xv6側の問題かと思って試行錯誤したが解消できず。SDMを見直したが間違いないように見える。結局、偶然qemu起動オプションでsockets/cores指定を行うことで解消できた。qemuマニュアルでは見つけられずちょっと苦戦。
問題発生時のqemu起動オプション
問題解消したqemu起動オプション
$qemu-system-i386 (中略) -smp 2,sockets=2,cores=1
環境
$qemu-system-i386 --version
QEMU emulator version 7.0.0
Copyright (c) 2003-2022 Fabrice Bellard and the QEMU Project developers
RHOSP17-beta
ふと見たらRHOSP17-betaがリリースされていた。Wallabyベースになったとのこと。
ただベースOSがRHEL9とさらっと難易度高そうなことが書かれている。
"This beta release of Red Hat OpenStack Platform is based on the OpenStack "Wallaby" release."
"This beta version of Red Hat OpenStack Platform runs on Red Hat Enterprise Linux version 9. "
メモ：Spectre Variant 2（CVE-2017-5715）とCPU側の対策(IBRS/eIBRS)とOS側の対策
随分前の話だけど、たまに関係性で混乱するのでメモ。
Spectre Variant 2の対策として、間接分岐の投機実行制限 (IBRS)がCPU側に実装された。
CPU側は、あくまで制限をかける手段を準備しただけなのでOS側の対応が必要。
最近のOSはintel社のCPU microcode updateを内包しているケースが多いので、BIOS更新をしなくてもOSを更新すれば緩和対策がほぼ実現できる。
CPU(intel社)の対策
- IBRS: CPU microcodeで実装,model-specific register (MSR)にIA32_SPEC_CTRL.IBRSを設けた。
- eIBRS: IBRSをハードウェアレベルで実装
OS側の対策
常時IBRSは、基本的にはkernel(ring 0)でMSRのIA32_SPEC_CTRL.IBRSに1を設定（必要な条件(HLT実行時等)では無効化再有効化を実施）。
ただ、間接分岐の投機実行制限するとCPUの処理能力が落ちる問題がある。
RHEL8とPodmanでKindを動かす。
Qemuモニター機能で低レイヤーを確認する
L1TF(CVE-2018-3646)とESXiとESXi サイドチャネル対応スケジューラ（SCAv2）
ずいぶん前に話題になったCPU脆弱性のL1TF。HWの問題のため、緩和策対応は可能だが性能劣化が懸念されて悩ましいと考えていたが、最近VMwareの別のKB（56931）を見ると、緩和策で用いるESXi サイドチャネル対応スケジューラ(SCA) には2種類あると書かれていることに気づいた。
■vSphere 用 Intel プロセッサにおける「L1 Terminal Fault」(L1TF - VMM) 投機的実行の脆弱性に対する VMware の対応 CVE-2018-3646 (55806)
■HTAware 軽減策ツールの概要および使用法 (56931)
- SCAv1
ハイパー スレッド対応コアの 1 つの論理プロセッサ（ハイパースレッド）にのみスケジュールを設定します。 その結果、このスケジューラを有効にすると、使用可能なホスト キャパシティが減少し、現在使用可能なホスト キャパシティに応じて仮想マシンのパフォーマンスが影響を受ける可能性があります。 - SCAv2
ESXi 6.7u2以降で導入された機構で、仮想マシンから仮想マシンや仮想マシンからハイパーバイザーへの情報漏洩を抑止する一方で SCAv1 で確認されたパフォーマンスの問題が改善されています。
以下ホワイトペーパーに記載があるが、SCAv2は保護の範囲を少し緩めることでセキュリティとパフォーマンスのバランスを取る選択肢に見える。
