【IT】脆弱性が多いプログラミング言語、第2位はPHP - 第1位は?
■ このスレッドは過去ログ倉庫に格納されています
WhiteSource Softwareは3月19日(米国時間)、「Is One Programming Language More Secure Than The Rest?」において、過去の脆弱性情報を集計し、どのプログラミング言語がより多くの脆弱性とかかわりを持っていたのかについて伝えた。
脆弱性情報が多い順にまとめたプログラミング言語ランキングとしては、以下が報告されている。
C言語 (47%)
PHP (17%)
Java (12%)
JavaScript (11%)
Python (6%)
C++ (6%)
Ruby (5%)
データソースはNVD (National Vulnerability Database)、各種セキュリティアドバイザリ、GitHub、そのほか人気の高いトラッキングシステムなどで集計された脆弱性情報など。対象のプログラミング言語は、過去数年間にオープンソースコミュニティで使われたプログラミング言語の中から特に人気の高いものが選択されている。
記事では、関連する脆弱性が多いからといって必ずしもそのプログラミング言語がセキュリティに対して脆弱ということを意味するわけではないと説明。例えば、C言語のシェアは50%近いが、これは長期にわたって使われていること、インフラストラクチャを構成するソフトウェアに使われており注目度が高いことなども関係しているという。
https://news.mynavi.jp/article/20190326-795188/ >>136
上で書いたオブジェクトはいわゆるゲームオブジェクトと呼ばれるもので、ゲーム中にゲーム固有の振る舞いをさせる為に実装するもの(移動、AI、定型的な動き演出など)
描画関連のオブジェクトやリソースは全く別
画面に表示する可能性のある3Dオブジェクトはシーン中に数千から万越えは珍しく無いし、パーティクルだとその数は更に増える
> 1ms単位で削りたいなら、アセンブラで書いたら？(w
SIMD 命令は intrinsics を使うので最適化のためにアセンブラでコードを書くことはまずない
非効率なコードが生成されていないか逆アセンブルされたコードを確認することが稀にあるくらい
FF15みたいな有名タイトルだとこうやって具体的な内容も表に出てるし、かなり細かな最適化をたくさんしている
自分が書いた程度の内容で話を盛ってるとか思われるのは心外だよ
http://jp.gamesindustry.biz/article/1609/16090501/ 仮想関数呼び出しってCで同じことやろうとしたら結局インスタンスごとに分岐や関数ポインタ使うことになって同じ時間かかるだろ？
まあ予測当たるように大まかにソートしておくとかすればいいんだが
仮想関数だろうがやることは変わらない >>131
ハードにもよるけど、例えばDSは、SDKはあったけど、Vブランク割り込みとかは、普通にコールバックで受け取って処理してたね >>132
プリエンティブなスレッドは、バグの再現性の低いバグが出たときに全然追えないからなー
世の中にはコルーチンですらまともに排他制御できない人もいるからね、、、
でも、最近のUnityはやっと高速化にも力を入れはじめて、キャッシュヒットを考慮した作りにしたり、ワーカースレッドに処理を逃がす仕組みを作ったり、精度が低いけど高速な数学関数用意したりして >>138
関数テーブルでやらんでもいいだろと。
条件分岐の羅列でもなんでも >>141
分岐の羅列でも関数テーブルでも分岐予測が外れたらストールするのは同じ
逆に予測が当たるならテーブルの方が命令数減るぶんだけ速くなる。
実データが一種類ならBTBで常に予測が成功するからね 【速報】金券500円分タダでもらえる
https://pbs.twimg.com/media/D2zNwP2UwAARLRa.jpg
①スマホのApp Storeから「タイムバンク」をインストール（iOS、Android両バージョンあります）
②会員登録
③マイページへ移動する。
④招待コード→招待コードを入力する [Rirz Tu]（スペース必要無し）
コードを入力した方に600円もらえます
今なら更に500円ギフト券を貰った残高からただで買えます。
貰ったギフティプレモはAmazonギフト券（チャージタイプ）に交換できます（電子マネー払いにて）
数分で出来るので是非ご利用下さい >>1
Perlは鉄壁のセキュリティ
Perl最強伝説がまた証明された >>142
分岐羅列のほうがキャッシュミスヒット減るだろな。
一連のアドレスにあるから。 >>146
分岐するブロック全体の予測成功確率は何しようが変わらない
CPU上の予測リソースの使い方が変わるだけ
多段になると各分岐命令でストールが起こるため予測失敗時のペナルティが大きくなる 関数型言語のコンパイラ実装者だったら関数を多用した場合のパフォーマンスの出し方色々知ってそう >>1
そもそも、一つの言語でアプリケーションソフトを開発することに無理がある switch文で数値の連続性が高く、分岐先が多い場合コンパイラがテーブル化するのはそっちの方が速いからだよ ■
つまり
１、オブジェクト指向を取り入れて、さらに
２、関数型 取り入れたら、
こういう順番になる。 >>58
マルチスレッドが出来たら世界のエースクラスだな。 人間もC言語やPHPな気風を孵化して止まないモンは誰にも制御不能
つーか、そんな外的インタラプトはすべて排除します
これは、飼い主の尾っぽを振って御仕舞な犬じゃなく
狼、ウルフ言語といいませうか？ 犬リーマンで生を終えて満足できる「桁落ち」には使い熟せないと思う Cを自由自在に転がしてこそヒカル「PHP」
文脈の基礎の無いバーカが弄るな 「脆弱性」を読めないばかりか
間違った読み方をわざわざスタッフに教えていた医者がいた
普通、医者ならほぼ100%読める単語なのだが
なぜだかアンタッチャブルらしくその後も絶賛出世中
その地区の方々は本当にご愁傷様です >>144
ふつーにGPUを使っている例を教えてください！
GDCでもそういった内容の発表は過去に無かったと思います >>130
>バッファオーバーランは言語によってセキュリティが向上する部分だろ
Cコンパイラーがバッファーオーバーフロー・オーバーランのチェックをやってはいけない決まりはない（-fsanitize=undefinedか-fsanitize=signed-integer-overflow,-fsanitize=bounds,fsanitize=object-size,-fsanitize=vla-bound等の個別指定）
コンパイラがチェックをするのは当たり前すぎるが、そうした機能を知らない連中がセキュリティーが大変だと大騒ぎしている
言語の規格がサポートするしないに関わらず、アナライザーやチェッカーを使えば十分に排除できる（又は自前の共通マクロでチェック箇所をラップする）
言語指定のチェッカーはやり過ぎる嫌いがあるし、どうでも良いところに分岐を入れられるとシリアル化されて最適化が犠牲になる
Pythonのように完全に排除してしまうと、余計な命令が増えILP最適化が弱まるためパフォーマンスは悪化する
勝手にパフォーマンスを激減させるような命令を入れられるのは迷惑このうえない。記憶ではRustでもリリースモードでチェックをしないはずだし、チェックも完璧なはずはないので
油断してバグ（セキュリティかパフォーマンス）を入れる可能性はゼロではない
どの言語でもリグレッションテストを可能な限りやるだけなので、意図しない余計なアセンブリ言語がないぶんにおいてCのデバッグ時の簡易さは貴重だ >>161
Rustでは常に境界チェックが行われるそうだ
Rust の Index bounds check の性能影響を調べてみた
http://gifnksm.hatenablog.jp/entry/2016/06/01/010152
Rust の配列 (Vec<T> や [T] など) では、インデックスアクセス時に境界チェック (index bounds check) が常に行われます。
常に行われる、というのはビルドの種類 (リリースビルド・デバッグビルド) に依存しないという意味です。
とにかく安全性を重視する Rust らしい仕様であると言えます。
他のプログラミング言語に目を向けて見ると、常にチェックが行われるシステムプログラミング言語というのも珍しい気がします。
すべてがプログラム作成者の責任になる C では当然何のチェックも行われませんし、
安全なシステムプログラミング言語という意味で Rust と立ち位置が近い D では、
デバッグビルドの場合のみ境界チェックが行われます (リリースビルドでは行われない)。 >>163
ということはSPECTOR系に狙われやすいんだな 境界チェックの正否に関わらずCPUがメモリ先読みしているお陰でパフォーマンス低下が押さえられていたんだな >>163
>常に行われる、というのはビルドの種類 (リリースビルド・デバッグビルド) に依存しないという意味です。
本当にRustが見境なく全てのアクセスで「境界」チェックをしているのなら、有難迷惑と考える方が多いだろう
リリースモード（ビルド）では最適化レベルがopt-level=3かopt-level=2のいずれかのはずで、本来であればそうしたチェックは最適化されないといけない
Rustコンパイラは、境界チェックをO(1)に「最適化」するはずなので、全てに境界チェックをするというのは誤りだろう
--emit asmで見たら最適化でコンパイラが不要と判断したチェックは消されているはずだ。時間があったら試して見てみると良い（LLVM自体の基本機能のはずだ）
>>164 の言うようなSpectreの例はともかく、言語が裏で勝手に色々とやるのはセキュリティーやパフォーマンスのデバッグをする際には邪魔でしかない
https: //people.csail.mit.edu/vlk/spectre11.pdf
Rust doesn't optimize bounds checks that Go 1.11 does
https:// github.com/rust-lang/rust/issues/51709
さらにループが複雑化すると、Rustコンパイラは最適化をしないと考えるべきで、ペナルティを払う必要が出てくる可能性もある
Why is my Rust implementation of InsertionSort slower than my C version?
https:// stackoverflow.com/questions/30965257/why-is-my-rust-implementation-of-insertionsort-slower-than-my-c-version >>166
境界チェックではないが、Rustのオーバーフロー系のチェックは大昔からの問題を蒸し返しているだけで、これを持って最終解決策と主張するのには無理がある
https://github.com/nikomatsakis/rfcs/blob/integer-overflow/text/0000-integer-overflow.md
Rust, at least, does not have to worry about memory safety violations, but it is still possible for overflow to lead to bugs. Moreover,
Rust's safety guarantees do not apply to unsafe code, which carries the same risks as C code when it comes to overflow. Unfortunately,
banning overflow outright is not feasible at this time. Detecting overflow statically is not practical, and detecting it dynamically can be costly.
Therefore, we have to steer a middle ground.
Rustコンパイラがデフォルトでチェックのために分岐命令を追加するのは、パフォーマンス的にはのぞましくなく、誤ったチェックを自動的に入れる可能性も排除できない
例えるならCコンパイラのコンパイルオプション（-fsanitize=undefined）をデフォルトで有効設定にしたビルドを使うだけで狂喜しているだけだ そりゃCだろ、メモリ管理自分でやると簡単にオーバーフローやらかすｗ
数値計算系のFortoranとかは起こしようが無い >>166
Why is my Rust implementation of InsertionSort slower than my C version?
https://stackoverflow.com/questions/30965257/why-is-my-rust-implementation-of-insertionsort-slower-than-my-c-version
Test on C:
ARRAY SIZE: 100000
< counting_sort: 0.003602
< insertion_sort: 8.273647
< heap_sort: 0.017918
Test on Rust:
ARRAY SIZE: 100000
< counting_sort: PT0.039530982S
< insertion_sort: PT276.529915469S
< heap_sort: PT0.117946209S 一般論として、プログラミングにおいてコンパイラに最適化を任せるというのは日常的なことだ
可能な限りコンパイラの最適化を利用するのは良いし、自明で基本的な最適化はコンパイラに任せるべきだ
ただコンパイラやツールにも限界があり、本当にボトルネックがあるなら調査や分析、ボトルネック回避の修正が必要となる
言語の規格レベルでガチガチに制限されると自由度は下がるので、最適化できる箇所・範囲が狭められる
Cで単にチェックをしたいなら、-fstack-protector、-D_FORTIFY_SOURCE=2、-fsanitize=undefined等を指定すれば良い なんかオプションまで語り始める奴ｗｗｗ
こいつ前もこれ系のスレに出没してたやつと一緒だな 意味不明なランキングだな、C言語の脆弱性が多いって
世の中結局C言語で書いてる、Pythonでもなんでも この調査結果で
日本語プログラム言語ひまわりは脆弱性が全く存在しない
とはならんだろ ネットで使われる言語はハッキングの試みが多いから、より脆弱性が発見されやすいんでね？ 多分ここにコメした奴が使ってる言語と作ったソフトに脆弱性が多いと思うわｗ 境界のチェックなんてJavaでやられていることで有名だったと思うのだが…
なんでこうなるかな そもそも、C言語は安全装置をつけないかわりに高速で何でもできるってのが利点だから当然でしょ？
安全装置がついてるけれど遅くてできることも限られる言語と同列にされても
コンピュータ制御で簡単に飛ばせるができることが限られるドローンと、
操縦が超難しいけれど宙返りでもなんでもできるラジコンヘリの違いみたいに >>183
それでもRustは高速さを売りにしているところが違うのだが
どちらかというとC/C++は配管むき出しの工場しか作れない言語
C/C++で住宅をつくると住人がけがをしてしまう >>184
そのRustで高速さを追求したコードはCのSIMDライブラリーを使い、SIMDを使用していない（C言語で）コードしたプログラムのパフォーマンスに匹敵すると主張する連中がいるようだが
明らかにC++に慣れていないプログラマーがコードしたマルチスレッドプログラムに匹敵するパフォーマンスが出たと言われても説得力はない
C++で生ポインターを使うべきでない程度の至極当たり前のことを、できないという奇妙な前提で使いもしない生ポインターの危険性でC++を批判したり、優位点が一々チグハグな印象しかない
「R.E.S.F」「Rust Evangelism Strike Force」（Rust伝道攻撃部隊）に寄せられる最大の批判は、他の言語に対するありもしない批判にかまけて、
肝心の実装をするための時間を無駄にし、シンプルなC/C++ベースのコードのポートだけしかできていない点だ
LLVMはC++でコードされているわけで、危険なC++のコードに依存している段階で問題がある >>170
同じ「C」で始まるけど、コボルは堅固性最高
しかし、C言語は素早く処理できなければ意味のない「通信」に適した人工言語
開放性と柔軟性があるがため、最初に決めるべきものはキッチリ決めとかないと、後はシラネーよ
コボルは、実に調教と馴致が簡単に出来る
C馬さんて、ジャジャ馬、調教がかなり難しい >>184
もしかして、テンプレートとかも知らない、かわいそうな子？ ■ このスレッドは過去ログ倉庫に格納されています
