xzにsshのバックドア

久しぶりにセキュリティー界騒然の事態ですね.劇場型のやり取りなどで3年がかりでxzのメインテナーに加わった人物がxzにsshのバックドアを仕組んだそうで,スパイ映画さながらです.

問題になるのは,xz (liblzma) 5.6.0と5.6.1だそうです.日常的なファイルの圧縮展開に利用されるばかりでなく,圧縮効率が高いため多くのdistroがパッケージをxzで圧縮して配布していてます.

手元のMac miniではMacPortsを使っているのでxzが入っているはずです.調べてみると(注意: xzコマンドを発行してバージョンを調べるのは危険かもしれません),

まさにドンピシャのものが入ってました.早速,

port selfupdate
port upgrade outdated

をかけたら,安全とされる古いバージョンに戻りました.

ちなみに,手元のいくつかのdistroで調べたところ,Slackware64とARM (32bit)の15.0は5.2.5で問題なし,Debian BookwormとRaspberry Pi OS Bookwormも5.4.1で問題なしですが,ManjaroはAMD64, ARM64とも5.6.1で今のところupdateは来てません(2024年4月4日09:35JST現在)

圧縮のスピードはかなり遅いですが😅
ただし,Slackware AArch64 currentは5.6.1です.他のアーキテクチャーのcurrentも5.6.1の可能性が高いです.
Manjaroは配布パッケージの圧縮にgzipを使っているようなので.ユーザーがxzをなにかの目的で使わなければ大丈夫なのかもしれません.

DOSBoxメモ (8) 目標の整理と現状・今後の方針

すっかり取り散らかして,何を目標にしているか自分でもわからなくなりそうなのでまず整理します.

最終目標は,Raspberry Pi 5 Model B (RPi5) で日本語DOSアプリ,Log200(DOS版)を動かすことです.

もともとSlackware 14.x (x86 32bit版)でdosemu + FreeDOS + 日本語FONT + 鳳を動かして,そこでLog200を動かしていました.

前項の表にあるように,現有の環境では唯一Manjaro AMD64でdosemuが動きます.かつて,Slackware x86 32bit版で動かしていたFreeDOSのディレクトリーが残っていて,それをManjaroにコピーして,dosemuを起動すると,Log200が見事に起動するのです.

Manjaro AMD64上にインストールしたdosemuによって,かつて使用していたdosemu用ファイルツリーからブートしてLog200の起動に成功

鳳による単漢変換ですが漢字入力もできます.

なんとかこの環境を,dosemuでないPC/DOSエミュレーターに移植して,最終的にRaspberry Pi上で使えないか,と考えたわけです.

dosemuはx86系のハードウェアでしか動かず,プリミティブな印象がありますが,ホストのLinuxファイルシステム上のサブディレクトリーを仮想HDDとしてC:やD:ドライブとしてマウントできるばかりでなく,そこからブートもできてしまうという秀逸な機能があります.

もし同じことがDOSBox(-X)やBochsでできれば,話はここで終わりにできました.

DOSBox(-X)ではホストのLinuxファイルシステムのサブディレクトリーをdosemuのようにドライブとしてマウントはできますが,そこからブートはできません.

Bochsに至ってはx86 PCを忠実に再現しているのでホストのサブディレクトリーをHDDに見立てるような機能はそもそもありません.

それでまた,dosemuはホストのLinuxファイルシステムを仮想ドライブとしてブートした上で,別に仕立てた仮想ディスクイメージをフォーマットして,内容をコピーすればちゃんとそのイメージから起動することができるようになります.

ここまできたら,その仮想ディスクイメージをDOSBox(-X)やBochsにマウントすればいいじゃないか,と思ったのですが,そこがなかなかうまくいきません.テストして確認したところでは,DOSBox(-X)とBochsの仮想ディスクイメージはコンパチで使い回せますが,dosemuとは方式が違うようです.

さきほどchatGPTに変換する方法はないか聞いてみたので,その回答をもとに変換できないか試してみることにします.

Linuxのext4のファイルツリーとして.

DOSBox メモ (7) エミュレーター動作まとめ

Tested DOS/PC Emulators

PCOSDosemuDOSBoxDOSBox-XBochs
Mac mini 2018 (Core i7)macOS Sonoma 14.4.1 (w/ MacPorts)N/ABuild failsInstalled and RunningInstalled and Running
Macbook Retina 12″ 2017 (Core i7)macOS Ventura 13.6.6 (w/ MacPorts)N/ABuild failsInstalled and RunningInstalled and Running
PC Core i7-4790SManjaro AMD64Installed and RunningInstalled and RunningN/A *2N/A
Debian AMD64 Bookworm 12.5N/AInstalled and Ran *3N/A *2Installed but NOT working *5
Raspberry Pi 4 Model BSlackware ARM (32bit) 15.0N/A *1N/AN/A *2 *4Installed and Running
Raspberry Pi 5 Model BRaspberry Pi OS Bookworm 12.5N/A *1Installed and RunningN/A *2Installed but NOT working *5
Slackware AArch64 currentN/A *1N/AN/A *2 *4Installed and Running
Manjaro ARM (64bit)N/A *1Installed and RunningN/A *2N/A
Notes
*1 Dosemu requires x86/AMD CPU.
*2 Maybe available via Flatpak
*3 No longer installed for certain reasons.
*4 Flatpak installation fails on the respective environment.
*5 Drops into the debugger at every start-up.
すべて当社調べ.

Slackware AArch64でSDDM動く

当社調べ

当サイトの情報はすべて「当社調べ」であり,これらの情報を直接的あるいは間接的に利用して直接的・間接的な損害が発生しても,当サイトの保有者および運営者および記事の執筆者は一切の責任を負いません.

V3D instead

これまで,気づいていたことは,同じRaspberry Pi 5 Model B (RPi5)やRaspberry Pi 4 Model B (RPi4)で動かしていても,Slackware ARM/AArch64よりもRaspberry Pi OS (RPiOS)方がデスクトップ環境もアプリも動作がきびきびしているということです.

そして,Slackware ARM (32bit) 15.0やSlackware AArch64 CurrentではSDDMが動かない.

Firmware的な違いとしては,RPiOSではGraphics ProcessorがV3Dなのに対し,Slackware ARM/AAarch64ではllvmpipeであるということです.

そんなものなのかなあと思って使ってきましたが,昨日のことですが,Slackware ARM/AArch64の/boot/config.txtでは,

# Enable DRM VC4 V3D driver
dtoverlay=vc4-kms-v3d
max_framebuffers=2

なのに対して,RPiOSでは,

# Enable DRM VC4 V3D driver
dtoverlay=vc4-kms-v3d-pi5
max_framebuffers=2

となっているのに気が付きました. “-pi5” が必要なのか! ということで,Slackware AArch64にも “-pi5” をつけたところ,ちゃんとKDEのAboutでV3DがGraphics Processorとして使用されていることが確認できました.

同様に,RPi5におけるManjaro ARM(64bit)とRPi4におけるSlackware ARM(32bit) 15.0でもV3DがGraphics Processorになっていることを確認しました.

V3Dだと,Slackware ARM (32bit)およびAArch64でSDDMが動きますし,KDE Plasma DesktopのいくつかのDesktop Effectが利用できるようになります.

そして,Firefoxが付いてないSlackware ARM 15.0のWebブラウザーであるFalconとKonquarorがなんとか耐えられるレスポンスで動くようになりました.

ただし調子に乗ってFalconでhttps://fast.com/を開くとデスクトップが固まります😅

当然ながらRPi4の場合は,
# Enable DRM VC4 V3D driver 
dtoverlay=vc4-kms-v3d-pi4 
max_framebuffers=2

です.

QEMUでDOSアプリを動かす(1)

Windows 10をMac mini (Intel)のVMWareで動かしていますが,その目的は現在ではDOSアプリであるアマチュア無線用ログソフト(以下 “ログソフト”)を動かすためだけです

Windows 10になってDOS窓内での日本語入力ができなくなってしまいました.そこで現在,日本の地名などもローマ字書きしています.そのWindows 10のサポートは既にメインストリームサポート期間を終了して,セキュリティー対策等だけの延長サポート期に入っています.延長サポートも2025年10月15日に終了するそうなので,そろそろ対策を考え始めないといけません.

現在Windows 11が動くハードウエアも仮想マシンも持っていません.11でも多分DOS窓内で日本語入力は保証されていないでしょうから,そのDOS窓を開くだけのためにハードや仮想マシンやWindowsのライセンスへの新たな投資はバカバカしいです.

ずいぶん昔はLinuxマシン上でDOSEMUというi486エミュレーター上に日本語サポートされたFreeDOSを走らせてそこでログソフトを動かしていました.しかし,x86系のCPUを搭載したLinuxマシンを常用しなくなったこともあり,Windows 8.1→10のDOS窓内で動かしていた次第です.

DOSEMUの開発はとっくに終わっていて,今日のGCCでは自力でbuildもできません.

しかし世の中には同じようなことを必要としたりより高いスキルで解決したりする人がいるようで,自分が今日いじっているdistroを確認したところ,Manjaroには正規にパッケージがあります.また,Slackwareは好事家が作ったパッケージをまとめているサイトSlackBuildsbuild用スクリプトがあります.

Debianについては,開発元が開発をやめた関係で,4年前にUnstableからも外されていました

早速試してみたところ,Manjaroはそれこそ,

pacman -S dosemu

だけでインストールが済みました.また,SlackBuildsも,

sbopkg -i gcc5
sbopkg -i dosemu
sbopkg -i dosemu-fonts

で,かつてx86で動かしていたサブディレクトリーをコピーしてからC:, D:にそれぞれ割り付けることで動作確認できました(Manjaroは動作確認してません).

DOSEMUのいいところは,LinuxのファイルシステムのサブディレクトリーをC: D:ドライブに割り当てることができることで,他のエミュレーターのようにディスクイメージが必須ではありません(ディスクイメージも使えます).

これはなかなか塩梅が良く,DOS用ログソフトのデータファイルをLinuxのファイルシステムにおいたまま読み書きし(ログソフトでは新しい交信データを追記していくのがほとんどです),Linux上で自作スクリプトでMariaDBとやりとりできますし,Linux用のバックアップソフトでも更新したデータだけのバックアップで済みます.

ただ問題点としては,DOSEMUはCPUのエミュレートはしないため,x86のシステム上でしか動かず,Raspberry Piでは使えません.前述のように,今日x86のLinuxは常用していないのでできればRaspberry Piで動かしたいです.

いちおう,x86マシン上でDOSEMUを動かすというのは保険としてとっておいて,次はなんとかRaspberry Pi上でQEMUを使ってDOSを動かし,目的のログソフトを動かすことを目指します.

あとがき

呆れたことに,全く同じことを3年半前にやろうとしたようです.その成果が残っていないので頓挫したようです.

数年前までは,2〜3のWindows用アプリも動かしていました.
使いやすさが売りのManjaroがこうしたオタクしか使わないパッケージをサポートしているのは意外なようですが,大もとがオタクなArchLinuxなので普通にあるようです.