並び順

ブックマーク数

期間指定

  • から
  • まで

1 - 8 件 / 8件

新着順 人気順

アーカイブファイル linuxの検索結果1 - 8 件 / 8件

  • コンパイラが作ったバイナリをつなぎ合わせるプログラム 「lld」の作者が語る、リンカの仕組み

    Kernel/VM探検隊はカーネルや仮想マシンなどを代表とした、低レイヤーな話題でワイワイ盛り上がるマニアックな勉強会です。植山氏は、制作中のリンカである「mold」について発表しました。全2回。前半は、リンカの概要について話しました。 LLVMのリンカ「lld」オリジナルの作者 植山類氏:植山類です。今僕が作っているmoldというリンカについて発表します。 今回の発表の概要です。リンカが何かを知っている人はそんなにたくさんいないと思うので、まず説明します。次に、「mold」のポイントは速いことなのですが、速いと何がうれしいのかを説明します。そのあと、どれくらい速いのかを説明した上で、どう実現されているのか、概要を紹介します。詳細になると何時間あっても終わらないので、かなりハイレベルな話をします。 自己紹介のスライドを入れていませんが、僕はリンカを何度か作ったことがあって、LLVMのlld

      コンパイラが作ったバイナリをつなぎ合わせるプログラム 「lld」の作者が語る、リンカの仕組み
    • Wiresharkによるパケット解析講座 8:HTTPSトラフィックの復号

      By Brad Duncan August 21, 2020 at 6:00 AM Category: Tutorial, Unit 42, Unit 42 Tags: tutorial, Wireshark, Wireshark Tutorial This post is also available in: English (英語) 概要 本シリーズは、疑わしいネットワークアクティビティの調査やネットワークトラフィックのパケットキャプチャ(pcap)の確認を業務で行っておられるセキュリティ専門家を読者として想定しています。このため本稿での手順説明は読者の皆さんがWiresharkの使いかたをご存知であることを前提としています。また、本稿にて利用するWiresharkのバージョンは主に3.xとなります。 昨今、対象となる疑わしいネットワークアクティビティのトラフィックが暗号化されているこ

        Wiresharkによるパケット解析講座 8:HTTPSトラフィックの復号
      • Dirty Pipe(CVE-2022-0847)の発見経緯が面白かった - knqyf263's blog

        最初に断っておくと今回は万人向けの記事ではないです。面白かったので自分が忘れないようにまとめているだけです。 本記事の位置付け はじめに 発見経緯 CRCのエラー HTTPアクセスログ 壊れたgzipのtrailerを見てみる 壊れたファイルの法則性 月次ログファイルの生成 Linuxカーネルのバグの可能性 バグ混入の歴史 ログ破損の原因 8バイトの謎 PoCの制約 まとめ 本記事の位置付け Dirty Pipe(CVE-2022-0847)三部作の最後です。ダークナイト三部作で言うとダークナイト ライジングにあたります。ダーティとダークって似てませんか。 spliceを使って高速・省メモリでGzipからZIPを作る 20分で分かるDirty Pipe(CVE-2022-0847) Dirty Pipe(CVE-2022-0847)の発見経緯が面白かった(本記事) 上の1, 2を前提知識と

          Dirty Pipe(CVE-2022-0847)の発見経緯が面白かった - knqyf263's blog
        • コンテナランタイムの仕組みと、Firecracker、gVisor、Unikernelが注目されている理由。 Container Runtime Meetup #2

          Docker MeetupとかCloud Native Daysの運営をしながら、無限にスケールするインフラはないかなって、日々もやもやと考えています。 さっそく本題に入っていきましょう。 コンテナってそもそも何ですかっていうと、まず「chroot」というLinuxの機能があって、これはrootディレクトリを特定のディレクトリに切り替えて、そこから下を別のファイルシステムとして確立する、といった技術です。 そこに対して「namespace」という機能で、ユーザー、プロセス、ネットワークを個別に割り当てて、さらにリソースにも制限をかけると、まるでVM(仮想マシン)のように動いて面白いね、というのがコンテナですよ、という説明はよくされると思います。 これを図にしました。 まず、対象のディレクトリに対して「pivot_root」という機能を使ってファイルシステムのルートを作ります。 そのうえで「

            コンテナランタイムの仕組みと、Firecracker、gVisor、Unikernelが注目されている理由。 Container Runtime Meetup #2
          • Linuxシステムの勉強に役立つコマンドの紹介 - セキュアスカイプラス

            こんにちは、SSTでWeb脆弱性診断用のツール(スキャンツール)開発をしている坂本(Twitter, GitHub)です。 先日の記事では Linux のネットワークインターフェイス名を出発点として systemd や udev について調査しました。 どうやって調査したかというと、 検索キーワードをあれこれ試してみて、見つかった記事から気になるコマンドや設定ファイルがあれば、実際の内容を確認し、 そこからmanページを辿ってパッケージ情報にさかのぼり、パッケージがインストールした他のコマンドや設定ファイルの一覧から構成を把握し、 さらに関連するコマンドや設定ファイルをmanページで辿って・・・ というサイクルを繰り返しました。 時には同じmanページを数度に渡って辿り直し、読み直したりして自分の中の情報を整理しました。 読者の皆様は、そのような時どうされますか? 初めて触るLinuxディ

              Linuxシステムの勉強に役立つコマンドの紹介 - セキュアスカイプラス
            • 【ハッキングに挑戦】脆弱性が残された仮想イメージ公開プラットフォーム(VulnHub)で練習をする - Qiita

              これからサイバーセキュリティについて手を動かしながら勉強に取り組んでいきたいと検討されている方に向けて「意図的に脆弱性が残された仮想イメージ公開プラットフォーム(VulnHub)で練習をする」として本稿をまとめていきたいと思います。 VulnHubとは 「Vulnerable By Design ~ VulnHub」(https://www.vulnhub.com/、以下 VulnHub)とは、意図的に脆弱性が残された仮想イメージを無料で!!公開しているプラットフォームです。 創設者のg0tmi1kは、『誰もがデジタルセキュリティ、コンピューターアプリケーション、およびネットワーク管理の実践的な経験を得ることができる資料を提供する』という目標を掲げ、その運用を開始しました。年々登録される仮想イメージの数は増加しており、VulnHub公式 Twitterアカウント(@VulnHub)のTwe

                【ハッキングに挑戦】脆弱性が残された仮想イメージ公開プラットフォーム(VulnHub)で練習をする - Qiita
              • 2021年にmrubyを始める皆さまへ - ローファイ日記

                2021年3月5日に、mruby 3.0.0 のリリースがされました。おめでとうございます! mruby.org これに関連してなのか、mrubyをこれから始めようとか、ここのところどうなっていますかという質問をちょくちょく受けたり、ツイートを拝見したりするようになりました。 一方で、どうしても情報が古い、あるいは多くのmgemのメンテナンス状況が悪いように見える、などの初学者にとっては難しい状況が広がっており、厳しい気持ちになったり、厳しい感想を述べたりされている方もいるように思います。そして、その感想中には誤解も含まれているようです。 ここでいったん、少しでも「心構え」ができるように、これから触ってみる方々に対しての自分の考えをまとめておこうと思いました。 (さらにいうと、基本的に本原稿はいちユーザ、それもWebインフラに関わるユーザとしての解釈なので、Matzをはじめとした他のmru

                  2021年にmrubyを始める皆さまへ - ローファイ日記
                • バックアップの圧縮形式を変更して CPU 使用率を改善する - Pepabo Tech Portal

                  はじめまして。技術部プラットフォームグループの sugy です。 私は主に弊社で運用しているカラーミーショップというサービスのインフラ周りの担当をしています。 本記事では、カラーミーショップのバックアップサーバでデータ圧縮形式を変更して CPU 使用率を改善した話を書きます。 経緯 カラーミーショップではサービス利用者の方々の大切なデータをお預かりしているのですが、システムの可用性の確保のためにそれらのデータのバックアップを行っています。しかし、しばらくバックアップサーバの CPU 使用率が高い状態が継続していました。この状態が更に進むとバックアップ処理が完了する前に次のバックアップ処理が開始されてしまい慢性的なリソース不足になる懸念がありました。 バックアップデータは各サービス提供用サーバから、バックアップ用サーバにデータを同期した後、アーカイブ・圧縮して AWS S3 に転送・保管する

                    バックアップの圧縮形式を変更して CPU 使用率を改善する - Pepabo Tech Portal
                  1