2月17日発売の『Software Design』誌に、C++23の解説記事を書きました！ https://twitter.com/gihyo_hansoku/status/1622448412074606594…
Retweeted by Fadis
retweeted at 22:46:41
| Stats | Twitter歴 4,600日（2010/07/06より） |
ツイート数 129,873（28.2件/日） |
表示するツイート :
2023年02月06日(月)1 tweetsource
2023年02月05日(日)8 tweetssource
うーん、割り算はいまでも可変サイクル数だし、かつては掛け算命令もそうだった。デノーマル数が出てくるかどうかで浮動小数点演算命令一通りサイクル数が違うとかもあった気がする https://twitter.com/fadis_/status/1622168267619192832…
Retweeted by Fadis
retweeted at 19:02:21
この動きを受けてIntelの中の人がDOITモードについての説明をカーネルメーリングリストに投げた。それによるとDOITモードはDDPやFSFPといったプリフェッチによる実行時間の揺れを起こらなくする為の物で、計算対象の値に依存して実行時間が変化する命令は現状存在しないし今後も作る予定は無いらしい
posted at 18:40:31
この結果、LinuxカーネルではIce Lake以降のCPUでは常にDOITモードを有効にすべきではないか、という提案が出てきた。Ice Lake以降のIntel CPUはData Operand Dependent Timing(DODT)脆弱性があるCPUと見做され、MitigationとしてDOITモードを常時オンにするパッチが用意された
posted at 18:40:30
Intelの説明ではDOITモードは性能が落ちる可能性がある為必要な所でのみ有効にすべきとされているが、Linuxカーネルは至る所でサイドチャネル攻撃で解読されては困るデータを扱っていてそれら全ての前後でDOITモードを切り替えるのは現実的ではなかった
posted at 18:40:29
x86_64の命令セットには今までオペランドの値によって計算時間が変わるような演算命令は無かった。x86_64における暗号の実装はこれを前提に作られていた為、IceLake以降ではDOITモードを有効にしないと安全に暗号を扱えないのでは、という懸念が生じた
posted at 18:40:28
暗号を処理するコードはデータや鍵の値によって計算にかかる時間が変化しないように慎重に実装する必要がある。さもないとそのコードを何度でも実行できる状況にある攻撃者は計算にかかる時間の変化から鍵を特定する可能性がある。このようなコードではデータで計算時間が変わる命令は避ける必要がある
posted at 18:40:27
Data Operand Independent Timing(DOIT)モードはIce Lake以降のIntel CPUに備わっている機能で、MSRで有効にする事で命令の実行にかかる時間がデータに依存して変化しなくなる。Ice Lake以前のIntel CPUにはこの機能はないが、それらはDOITモードが有効な場合と等価に振る舞う
https://www.intel.com/content/www/us/en/developer/articles/technical/software-security-guidance/best-practices/data-operand-independent-timing-isa-guidance.html…
posted at 18:40:27
Intelの中の人が今Linuxで問題になっているIntel CPUのDOITについて、心配しているような物ではないという説明をしている話。既存のDOITの説明ではDOITMがoffだと安全に暗号を扱えない可能性があり、LinuxではDOITM対応のCPUを脆弱性のあるCPUと見做す用意が進められていた
https://www.phoronix.com/news/Intel-DOIT-DOITM-Details…
posted at 18:40:26
2023年02月04日(土)10 tweetssource
@rero_carnelian 巻くだけ簡単
posted at 01:49:27
海鮮太巻。全形の海苔に酢飯をのせる。その上に大葉、とびっこ、錦糸卵を乗せる。鮭、まぐろ、いかの冊を細長く切って乗せる。かに風味かまぼこをほぐして乗せる。巻き簾で巻いて完成 https://pic.twitter.com/0P37P6qFk9
posted at 00:57:54
さらに変更ではarchの互換関係 x86_64⊂x86_64-v2 ⊂x86_64-v3 ⊂x86_64-v4が設定される。これによってyumはx86_64-v3のホストでまずx86_64-v3のパッケージが無いか調べ、無かったらx86_64-v2のパッケージが無いか調べ、無かったらx86_64(v1)のパッケージが無いか調べるという動きができるようになる
posted at 00:51:07
これを実現する為にはx86_64(v1)のバイナリが入ったパッケージとx86_64-v2のバイナリが入ったパッケージを別のアーキテクチャとして区別できる必要がある。そこで変更ではarchにx86_64-v2 x86_64-v3 x86_64-v4を指定できるようにしている。それぞれの意味はgccのFeature Levelの定義そのまま
posted at 00:51:07
そこでディストリはまず全てのパッケージをx86_64(v1)で提供した上で、用意できる範囲でより高いFeature Levelのパッケージを追加で用意したい。yum installがホストのCPUに合わせてできるだけ高いFeature Levelのパッケージを選択できれば、古いCPUのユーザも新しいCPUのユーザもハッピーになれる
posted at 00:51:06
x86_64-v4はx86_64-v3に加えて近年のCPUに比較的良く載っている一部のAVX-512の拡張命令が使われるようになる。ディストリはx86_64(v1)でバイナリを用意すれば全てのCPUで手堅く動くようにできるが、新しいCPUを使うユーザはより高いFeature Levelのバイナリを欲している
posted at 00:51:05
x86_64-v2はNehalem(2008年)以降のCPUで実行される事を想定する。それまでに入ったSSSE3 SSE4.1 SSE4.2 POPCNTといった拡張命令が使われるようになる。x86_64-v3はHaswell(2013年)以降のCPUで実行される事を想定する。それまでに入ったAVX AVX2 FMA等の拡張命令が使われるようになる
posted at 00:51:03
gcc11ではx86_64のCPUを拡張命令の対応具合で4段階に分類するMicroarchitecture Feature Levelsが定義された。x86_64(v1)はAthlon64(2003年)以降のCPUで実行される事を想定する。これが指定された場合一切の拡張命令は使われなくなる
posted at 00:51:02
x86_64は初代Athlon64が登場してから既に20年近くが経過しており、今日のCPUでは「x86_64の基本の命令セット」の上に大量の拡張命令が追加されている。「x86_64なら動く」パッケージを作る場合拡張命令を一切使わないバイナリを作る必要があるが、拡張命令の有無はしばしば大きな性能差を生じさせる
posted at 00:51:01
RPMのパッケージのarch(どのアーキテクチャ向けのバイナリが入っているか)として従来からあるx86_64に加えてx86_64-v2、x86_64-v3、x86_64-v4を指定できるようになった話。それぞれのアーキテクチャ名の意味はgccで定義されているMicroarchitecture Feature Levelsと同義
https://www.phoronix.com/news/RPM-x86_64-Feature-Levels…
posted at 00:51:01
2023年02月02日(木)2 tweetssource
ワカモレとフライドチキン。でかい鶏肉は油で揚げても中まで火が通らない。王道の解決方法はBBQグリルでゆっくり加熱する方法だけど、スパイスと鶏肉をフリーザーバッグに入れて熱湯と一緒に魔法瓶に入れて放置してから最後に表面だけ揚げる方法でも割とそれっぽくなる https://pic.twitter.com/ttfPnO0Axo
posted at 00:12:26
@ipv6labs ローカルネットワークとローカルネットワークの間でBGP始めました
posted at 00:06:38
2023年02月01日(水)7 tweetssource
この問題はメインメモリが2GB未満のUbuntuマシンにおいてはデスクトップを上げられるかどうかに関わる問題になるらしく、10年も放置されている使われていないOpenGL用の実装は削除してしまえ、という話になったらしい
posted at 23:29:30
この結果、NVIDIAドライバが入っている環境ではCairoを使うアプリケーションを起動すると問答無用でNVIDIAドライバが準備を始め、Cairoを使うプロセスの数は多いので大量のメモリがNVIDIAドライバに持っていかれる事になった。実際にはCairoのOpenGLを使う実装は試験的な物なので滅多に使われない
posted at 23:29:28
最近のNVIDIAのOpenGLのドライバはglvndから使われる事を期待していて、libGLがロードされた時点でアプリケーションはすぐにNVIDIAのGPUを使う気があると判断して積極的にリソースの確保を行う
posted at 23:29:26
CairoのOpenGLのサポートは古いコードなのでglvndを経由していない。glvndは複数のベンダーのOpenGLの実装をアプリケーションが選んで使えるようにする仕組みで、使うGPUが選ばれた時点でそのベンダーのlibGLが動的にロードされる。Cairoの実装はglvndを使わないのでlibGLを直接リンクしている
posted at 23:29:25
Cairoは基本的にCPUでベクタ画像を描画するが、2010年にOpenGLを使ったGPUでのベクタ画像の描画が試験的に導入された。しかし、CairoのAPIと互換を保ちながらGPUで性能が出るように実装するのは難しく、この実装は以降ほぼ放置された状態になっていた
posted at 23:29:24
Cairoはベクタグラフィクスをレンダリングする為のライブラリで、GTK+等がベクタ画像の描画手段として使っている為Linuxデスクトップ環境の多くのアプリケーションが間接的にCairoに依存している
posted at 23:29:23
CairoからOpenGLバックエンドが削除されたらしい。CairoのOpenGLバックエンドは10年程前に試験的に実装されたが、以降特に進展は無く試験的な実装のまま今日まで放置されていた。OpenGLバックエンドはほぼ使われていないが、使わなくても存在するだけで厄介な問題が生じていた
https://www.phoronix.com/news/Cairo-Drops-OpenGL…
posted at 23:29:23
2023年01月29日(日)7 tweetssource
バッファローウィングといんげんフライ。バッファローウィングは手羽先、塩、胡椒、おろしにんにくをビニール袋に入れて揉み冷蔵庫で寝かせ、170度の油で揚げ、チリソースをあえる。いんげんフライは茹でたいんげんに薄力粉、塩、ベーキングパウダー、水の衣を付け、パン粉をつけて170度の油で揚げる https://pic.twitter.com/hEaUzL86Ya
posted at 16:05:39
Googleのベンチマークによると、Light AVXを使うと単純な128bit制限の場合と比較して0.1から0.2%の性能向上が見られたらしい。一方256bit制限で実行した場合128bit制限の場合と比較して数%の性能低下が見られたらしい。LightAVXは長いレジスタでの演算で動作周波数が落ちないCPUには影響がない
posted at 15:05:24
特にload/store命令は長いレジスタをフルに使ってもCPUの動作周波数が落ちない事が知られている。そこで演算には128bit制限をかけるけど、load/storeしかしないmemcpyのような処理では256bitまで使うようにするのがLight AVX
posted at 15:05:23
この問題を回避する為にSkylakeやIceLakeのXeon等の古いCPU向けの最適化ではAVXのレジスタを128bit分までしか使わない-mprefer-vector-width=128が用いられる。しかし長いレジスタを使っても動作周波数が落ちるかどうかは命令に依る為、全ての処理を128bitに制限するのは保守的すぎる
posted at 15:05:22
最近のCPUでは問題なくなったが、古いx86_64のCPUでは複雑なAVX2の命令やAVX-512の命令を実行すると消費電力や発熱がCPUの設計上許容できる上限を超え、強制的に動作周波数が落ちる。CPUの動作周波数が落ちる事による性能低下はしばしば長いレジスタで計算する事による性能向上を打ち消して余る
posted at 15:05:18
x86_64 CPUはAVXで256bitのSIMDレジスタを導入し、AVX-512で512bitのSIMDレジスタを導入した。沢山の値を一度に処理すれば速いというシンプルなアイデアだが、沢山の演算器を一度に動かすことなる為消費電力が大きくなる
posted at 15:05:17
Googleの中の人がLLVMに「Light AVX(軽いAVX)」のサポートを追加した話。最適化属性+allow-light-256-bitがセットされるとclangは-mprefer-vector-width=128でSIMD演算の最大長が128bitに制限されていても256bitのload/storeを使うようになる
https://www.phoronix.com/news/LLVM-Google-Light-AVX-Option…
posted at 15:05:16
2023年01月27日(金)2 tweetssource
BGPってそういう用途で気軽に使って良いんだぜ! ってのはCalicoから学んだ(
posted at 00:19:58
家の中に複数セグメントあるローカルネットワークの経路情報をbirdを使ってiBGPで投げ合うようにしてみた。これでいろんなホストに経路情報を設定してまわらなくて良くなる
posted at 00:08:21
2023年01月25日(水)9 tweetssource
茄子とししとうの揚げ浸し、豆腐の唐揚げ。豆腐の唐揚げは水切りした木綿豆腐を食べやすい大きさに切り、塩、片栗粉、薄力粉、水を混ぜた衣を付けて170度の油で2度揚げ、七味唐辛子をかける https://pic.twitter.com/qs5yVgqLo5
posted at 01:25:06
armv8mにはMMUが無い為分岐ターゲット識別非対応のコードとの共存は考慮されない。armv8mでは分岐ターゲット識別をグローバルに有効にして間接ジャンプやプログラムカウンタの書き換えが行われると状態レジスタに専用のフラグが立ち、フラグが立った状態でBTI命令以外が実行されるとCPU例外が飛ぶ
posted at 01:12:06
分岐ターゲット識別はジャンプ先のコードに対応が必要な為、armv8aの分岐ターゲット識別ではページテーブルに、その領域へのジャンプで分岐ターゲット識別が使えるかどうか(BTIが置かれているかどうか)のフラグを用意して既存のコードと分岐ターゲット識別を使うコードの共存を実現していた
posted at 01:12:06
スタックにジャンプ先のアドレスが積まれていて、そのスタックを破壊できる不具合がある場合RoPと同様にそのアドレスを書き換える事で攻撃者が意図した処理を実行できる(JoP)。しかし分岐ターゲット識別が有効な場合飛べる先が限定される為、JoPで攻撃者が意図した処理を行うのが極めて難しくなる
posted at 01:12:05
分岐ターゲット識別はジャンプした先の最初の命令が着地用命令(BTI)でなかった場合にCPU例外を飛ばす機能。関数ポインタ等のジャンプ先のアドレスを持ち回して必要な時に呼び出すコード(間接分岐)で、呼び出される事を意図していないアドレスへのジャンプをできなくする
posted at 01:12:04
armv8mのポインタ認証では署名をチェックする命令がアドレスで指されている先を触る命令とは別に用意される。このポインタ認証が期待通りに機能する為には、コンパイラがポインタとセットで署名をスタックに積み、アドレスが使われる前にアドレスに対応する署名をチェックする命令を挟む必要がある
posted at 01:12:04
armv8aでは64bitアドレス空間のうち限られた範囲しか使われていない事を利用して空いている上位ビットに署名を挿入する仕様だったが、armv8mはアドレス長が32bitなので署名を書ける余裕がない。そこでarmv8mのポインタ認証では署名をアドレスとは別のレジスタに置く
posted at 01:12:03
ポインタ認証は特権モードでしか触れない鍵を使ってポインタの値に署名を付ける。専用の命令で生のアドレスを署名付きアドレスにできる。攻撃者がスタック破壊を起こせる不具合を使って戻りアドレスを書き換えても(RoP)、そのアドレスには署名が無い為攻撃者が指定した飛び先には飛ばず、CPU例外が飛ぶ
posted at 01:12:02
gccにARM Cortex-M85に備わっているPACBTIのサポートが追加されたらしい。PACBTIはPointer Authentication and Branch Target Identificationの略で、新しめのarmv8a CPUに備わっているポインタ認証と分岐ターゲット識別に近い機能をarmv8mのマイコンでも使えるようにする
https://www.phoronix.com/news/GCC-13-Arm-Cortex-M85…
posted at 01:12:02
2023年01月20日(金)5 tweetssource
提案されている変更はMesaのd3d12をXBOXのGDK上でも動くようにする物。これによってGLon12がXBOX上でも使えるようになり、OpenGLなゲームを大きく書き換える事なくXBOXで動かせるようになる。デモではSDLのOpenGLのサンプルプログラムを実機のXBOXの上で実行している
posted at 05:07:21
マイクロソフトはWindowsとXBOX向けにGame Development Kit(GDK)を提供しているが、Windows版とXBOX版では仕様が異なりGLon12は従来Windows上でしか動かなかった。XBOX Series X/SでGPUを使う為に用意されているAPIはDirectX 12のみなので、OpenGLな古いゲームを移植するのは容易ではなかった
posted at 05:07:21
マイクロソフトはWindows上でOpenGLのAPIを提供する為にGLon12と呼ばれるOpenGLをDirectX 12に変換するライブラリを用意しているが、これはMesaにDirectX 12バックエンドを実装する事で実現されている。このバックエンドはd3d12と呼ばれ、現在は本家のMesaにマージされている
posted at 05:07:20
XBOX Series X/SでOpenGLを使えるようにする試みの話。MesaのDirectX 12バックエンド(d3d12)を拡張してXbox GDKの上でも動くようにして、GLon12をXBOX上でできるようにする。OpenGL向けに書かれた古いゲームをXBOX Series X/Sに移植するのが容易になる
https://www.phoronix.com/news/Mesa-Adds-Xbox-GDK…
posted at 05:07:20
家のLinuxマシンのユーザ管理をsystemd-homedにしてfscryptで暗号化されたホームディレクトリをログイン時にシュッと読めるようにしようと思ったんだけど、systemd-homedの諸々はsshからログインした時には動いてくれなくて深い悲しみに包まれながら古典的なLinux環境のユーザ管理に戻した
posted at 01:12:33
