Linuxのkernel TLSでnginxのSSL_sendfileを試してみた · hnakamur's blog
2021-10-31 はじめに OpenSSLのSSL_sendfileとパッチを当てたnginxでLinuxのkTLSを試してみた · hnakamur’s blog を書いてから1年半経って状況が変わっていたので再度試してみました。 9日前に SSL: SSL_sendfile() support with kernel TLS. · nginx/nginx@1fc61b7 で Linux の kernel TLS を使って sendfile するコードが nginx に入っていました。 コミットメッセージによると enable-tls オプションを有効にした OpenSSL 3.0 が必要とのことです。 検証環境 $ cat /etc/os-release | grep ^VERSION= VERSION="20.04.3 LTS (Focal Fossa)" $ uname -r
libimobiledevice · A cross-platform FOSS library written in C to communicate with iOS devices natively.
A cross-platform FOSS library written in C to communicate with iOS devices natively. ... and a bunch of libraries and command-line utilities. Get Started Native Protocols The library implements the native protocols needed to communicate with services running on iOS devices. Due to the reimplemention it does not depend on using or bundling any existing libraries from Apple. Cross-Platform The C pro
Raspberry Pi PicoをWSL(Windows Subsystem for Linux)で使う - Qiita
Raspberry Pi Picoを買ってみました。 環境構築の方法はGetting started with Raspberry Pi Picoに載っていますが、開発環境はRaspberry Pi 4上で構築するのが基本となっているようです。Windowsでのやり方も一応載っていますが、コマンドライン上での操作となるとWSL(Windows Subsystem for Linux)を使うのが便利なので、その方法をまとめてみました。 必要なもの Raspberry Pi Pico本体 (できれば2枚) 2枚あると片方をデバッグプローブにすることでJTAGデバッグが可能になるので便利です。 ピンヘッダ Raspberry Pi Picoにはピンヘッダがマウントされていないので、ブレッドボードに挿すためのピンヘッダを別途用意して、基板にはんだ付けする必要があります。 Picoの基板には両側に2
Linuxカーネルの起動時トレースの話 - Qiita
カーネル起動時トレース Linuxカーネルの起動処理は、様々なことが行われるのにそれをデバッグする方法はprintkだったり、逆にkgdbを外部デバッガから繋いだりと、結構な手間がかかっていました。カーネルが起動してしまえば、ftraceにperf, BPF, systemtapと複数の手段が使えるのに、起動時のデバッグは細かいことが出来ません。これは、起動時に指定できるオプションが大雑把になるのが大きな理由の一つでした。シェル芸ではないですが、1行プログラミングだけで様々なことをするのは大変です。 そこで導入されたのがExtra Boot Configuration (bootconfig)です。Bootconfigについては前回の記事を参考にしてください。 ここではカーネルコマンドラインのトレースオプションと、Bootconfigによって拡張されたBoot-time trace（CON
Big Sky :: sudo の特権昇格バグはなぜ起こったのか
« Microsoft Word を Markdown に変換するコマンド「docx2md」を作った。 | Main | VimConf 2019 を終えて » Linux の sudo に root 権限を奪取できるバグが見つかった。 Linuxの「sudo」コマンドにroot権限奪取の脆弱性。ユーザーID処理のバグで制限無効化 - Engadget 日本版 この脆弱性は、sudoコマンドのユーザーIDに-1もしくは4294967295を指定すると、誤って0(ゼロ)と認識して処理してしまうというもの。0(ゼロ)はrootのユーザーIDであるため、攻撃者は完全なrootとしてコマンドを実行できることになります。 https://japanese.engadget.com/2019/10/14/linux-sudo-root-id/ 既に Ubuntu 等にはパッチが配布され始めているらしい
Linuxがブートできる自作RISC-VシミュレータをGitHubにアップロードした - FPGA開発日記
自作RISC-Vシミュレータがある程度落ち着いてきたので、キリがいいところでGitHubで公開することにした。 github.com まあSpike(riscv-isa-sim)の劣化Cloneだと言ってしまえばそれまでなので、あまり意味はないのだけれど。。。 図. 自作RISC-Vシミュレータの外部インタフェース 使い方はGitHub上のREADME.mdに書いてある。BSDライセンスなので自由に改造してやってください。 まあこういうツールの場合BSDライセンスが良いのかどうかもよく変わっていないけれども？ RISC-Vの精神に基づいてみた。 Spikeシミュレータとの差分点としては、デバッグ情報がしっかり出力できるようにした。レジスタアクセス情報からメモリアクセスの情報まで、--debugオプションによりしっかり情報を出力する。 その影響で--debugオプションをかなり遅くなってしま
Linux:パフォーマンスに影響あるデバッグオプションがどれだけ影響あるか試してみた - φ(・・*)ゞ ｳｰﾝ カーネルとか弄ったりのメモ
なんとなくやってみた系ですね。 今回はCONFIG_DEBUG_OBJECTSのところです。 CONFIG_DEBUG_OBJECTS_FREEがkmalloc/kfreeをヘヴィにつかうような場合にパフォーマンス劣化するよーなんていってます。 まずはCONFIG_DEBUG_OBJECTSの項目を全部無効にした場合。 この時点でもロック周りに時間取ってますね。 hackbenchを引数 10 process 20000 で実行してる時の様子がこんな感じです。 次にCONFIG_DEBUG_OBJECTSの項目を全部無効にした場合。 起動した時点でかなりの時間をロックで使ってます。 そして、hackbenchを同じく実行するとこうこうなります／(^o^)＼ このときはこんな感じになっていてもうどうにもならない感がありますね。 説明に書いてあるとおり、ほんと遅くなりますね。 ( ´ー｀)ﾌｩ
エンジニア・光成 滋生の「バグを突き止める技術」 | サイボウズ式
サイボウズ・ラボの西尾 泰和さんが「エンジニアの学び方」について探求していく連載の第18回（これまでの連載一覧）。サイボウズ・ラボの光成 滋生さんにお話を伺うシリーズ（1）です。 本連載は、「WEB+DB PRESS Vol.80」（2014年4月24日発売）に掲載された「エンジニアの学び方──効率的に知識を得て，成果に結び付ける」の続編です。（編集部） 文：西尾 泰和 イラスト：歌工房 この連載では「エンジニアの学び方」をテーマにインタビューを行い、どういう「学び方」をしているのか探求していきたいと思っています。第2弾は、サイボウズ・ラボのエンジニアとして、楕円曲線などの難しい数学を使った暗号の論文を読んで実装したり、サイボウズが遭遇した問題の原因を掘り下げていって最終的にLinuxのバグを修正したり、と幅広い活動をされている光成滋生さんです。 光成さんが、どういうプロセスで問題の原因を
bashスクリプトをデバッグする方法 - Qiita
#!/bin/bash exec 5> debug_output.txt BASH_XTRACEFD="5" PS4='$LINENO: ' set -x するとdebug_output.txtにログが出力される。 exec 5>はファイルディスクリプタ5番をdebug_output.txtにするという意味。 PS4はトレース出力の際に表示されるプロンプト。$LINENOにより行番号を表示している。 set -xは実行するコマンドをトレース出力させる。 元記事にはbashdb、log4bash、Eclipse、Visual Studioo Codeを使う方法なども紹介されているが、これが一番手軽でほとんどの場合十分だと思う。 Register as a new user and use Qiita more conveniently You get articles that match
QEMU上のLinuxカーネルをGDBでデバッグする
プログラムがセグメンテーションフォルトで不正終了した場合に、GDBで原因 調査するというのはよく聞く話である。しかし、こういったソフトウェア開発 の後行程で使用するだけではなく、前行程でも使うべきである。これは挙動が よく分からないプログラムの動作確認にGDBが有効であるからだ。 今回は特にprint文が動作しない段階のLinuxカーネルの動作をGDBで確認する。 ただし、あくまでQEMU上での動作である為、QEMUでサポートしていないハード やQEMUが再現しきれていないハードの動作部分については未対応である。そう いった場合はICEなどの治具を用いる必要がある。 1. カーネルコンフィグの設定 CONFIG_DEBUG_KERNELを有効にする。 Symbol: DEBUG_KERNEL [=y] Type : boolean Prompt: Kernel debugging Loca
Linus様がSystemdにぶちきれる
systemdは、/proc/cmdlineをパースして、もし、その中に"debug"という文字列を発見した場合、大量の冗長なデバッグメッセージをdmsegに出力する。これは様々な問題を引き起こす。まず、"debug"というあまりに一般的すぎる文字列に勝手に反応してしまうことがひとつ。dmseg、すなわちカーネルのリングバッファーをsystemdの冗長なデバッグメッセージだけで溢れ返させてしまうことがひとつ。そして、なぜかLinuxカーネルのブートに失敗してしまうことがひとつ。 Bug 76935 – Do not parse "debug" command line parameter カーネルコマンドラインに"debug"を与えると、systemdによりパースされる。適当なassertに引っかかると、こんな風にぶっ放される。 [ 150.308000] systemd-journald
RHEL(CentOS)6系でトラフィックをたくさん捌くサーバが死ぬ問題は6.5のkernel-2.6.32-431.el6以降で多分直る - このブログはURLが変更になりました
タイトルで言いたいことはすべて言った。 経緯 うちの場合はLVS+keepalivedなロードバランサなんだけど、ちょくちょくkernel panicになる問題が発生してた。 そこでcrashコマンドで解析してみた。crashコマンドの使い方はこちらが参考になる。Linux crash dump 読み方入門 # crash /boot/System.map-2.6.32-279.14.1.el6.x86_64 /usr/lib/debug/lib/modules/2.6.32-279.14.1.el6.x86_64/vmlinux /var/crash/127.0.0.1-2013-09-27-16\:21\:01/vmcore (snip) SYSTEM MAP: /boot/System.map-2.6.32-279.14.1.el6.x86_64 DEBUG KERNEL: /usr
シェル・スクリプトのデバッグ・ツール、bashdb | OSDN Magazine
Bash Debugger Project（bashdb）を使うと、bashスクリプトにブレークポイントを設定したり変数を調べたりバックトレースしたり1行ずつ実行したりすることができる。bashdbは、C/C++デバッガー並みの技法でbashスクリプトをデバッグするツールだ。 インストールされているbashがbashdbをサポートしているかどうかは、次のコマンドを実行してみればわかる。下に示したbashdbのプロンプトが表示されなければ、bashdbをインストールする必要がある。 $ bash --debugger -c "set|grep -i dbg" ... bashdb<0> bashdbのパッケージはUbuntu Intrepidのリポジトリーにはあるが、openSUSE 11やFedora 9のリポジトリーにはない。試用マシンは64-bit Fedora 9マシンなので、通常の
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
ptraceとELFとLinuxレジスタ : sonots:blog