純粋なPython / Javaで書かれたサービスまたはオペレーティングシステム全体の方が安全でしょうか？
多くのWindowsおよびLinuxサービスは、CまたはC++で記述されています。そのため、メモリセキュリティが不足しているため（バッファオーバーフローなど）、いくつかの方法で悪用される可能性があります。
Python/Javaで書かれたサービスは、C/C++で書かれたサービスよりも安全ですか？ Java/Pythonベースのオペレーティングシステム全体（可能な場合でも）は、現在のオペレーティングシステムの選択肢よりも安全ですか？
まあ、Javaについてはわかりませんが、標準のPython実装はC-Pythonと呼ばれ、C言語で記述されています。したがって、（可能な場合でも）Pythonは最終的にCを使用して構築されます。
さらに、プログラミング言語について考えるとき、ほとんどはOSの作成ではなくアプリケーションの作成を対象としており、プログラマーは言語の実装に依存してシステムと対話します。私が考えることができる2つの主要な例外は次のとおりです。
- アセンブリ言語s：機械命令を直接書き込むことができ、ハードウェアに簡単にアクセスできます。異なる命令セットを持つプロセッサを使用する場合は、すべてを書き直す必要があります...
- 外部ライブラリなしでメモリマップされたハードウェアレジスタに簡単にアクセスでき、（リアルモードで使用する場合）フルシステムメモリにアクセスできるC言語-C++も同じレベルで使用できます。 KernighanとRitchieによって最初のUnix OSを構築するために発明され、最初のCバージョンは、高級言語ではなく、実際にマクロアセンブリ言語に近く見えました。
反対に、JavaおよびPythonは物理的な既知のアドレスでメモリにアクセスすることを意図しておらず、プログラマはシステムライブラリ（Cで作成されることが多い）を使用して対話する） OSで。
最後に、C言語は評判が良くありません。エラーや警告のないプログラムには重大な間違いが多く含まれている可能性があり、メモリアドレスにアクセスできるため、間違ったものを簡単に使用できるため、初心者や慎重でないプログラマによく噛まれます。そして、正しく機能豊富なプログラムを書くことは、通常CではPythonまたはJavaよりも）長くなります。
以下は、私の意見であり、異なる言語での40年以上のプログラミングによってのみ導かれます。プログラムのセキュリティを構成するのはその言語ではなく、プログラマーの熟練度であり、何よりもベストプラクティスの尊重 =。その中で：
- 予想されるおよび病理学的なユースケースに対して記述されたテスト（正しい入力が与えられた場合、プログラムは正常に動作し、ごみが与えられた場合、プログラム自体とシステムを保護する必要があります）
- 広範なピアレビュー-フェローは、あなたが別のポイントに焦点を合わせていたために、あなたが少し早く書いた疑わしいコードを指摘します。
- 楕円形のホイールを再発明するのではなく、十分に確立されたパターン（使用する言語とフレームワークに依存する）を使用する
- 読みやすく理解しやすいコードのみを記述し、低レベルの最適化のための理論的根拠と原則に関するコメントを追加する
これは確かに顕著なオーバーヘッドを追加します。しかし、堅牢なコードには代償が伴います。そして、これは実際にJavaまたはPythonがCが不要な場合に使用する本当の理由です。これは、使用するコード行が少なくなり、より簡単になるためです。査読者のために読むことです。したがって、作成された堅牢なアプリケーションプログラムはPythonまたはJavaはCで同じものよりも安くなります。しかし、低レベルのOSパーツにJavaまたはPython=を使用するのは意味がありません。
CまたはC++の代わりにJavaまたはPython=を使用すると、実際には（ほぼ）バッファオーバーフローなどのリスクが完全に排除されます。このようなサービスが自動的に安全になるわけではありません。またはさらに安全-完全にメモリの安全性とは無関係の脆弱性のクラス全体があります（チェックアウト OWASPトップ1 ）。
Python of JavaでOSを書くのは良い考えですか？それがどのように機能するかは明らかではありません。OSは直接メモリ管理を実行する必要があります。このような高水準言語では実際にそれを行うことはできません。さらに、パフォーマンスの問題が発生します。もっと現実的なアプローチは、Rustのようなメモリセーフな低水準言語でOSを記述することです。
しかし、結局のところ、私のような怠惰なWeb開発者を雇えば、信頼できないデータをSQLクエリに直接連結するだけです。そして、世界中のすべてのメモリの安全性は、それを助けることはできません。
メモリの安全性は脆弱性の非常に一般的な原因であり、完全に回避可能です。明らかにそれは行くべきです。ただし、ソフトウェアを安全でないものにする方法は他にもたくさんありますが、メモリの安全性では直接対処できません。
100％Pure Java は、Sunの商標およびマーケティングキャンペーンでした。それは、アプリケーションが使用できないほどプラットフォームに依存しないことを必要としました。インターフェースが非常に小さい場合もありますが、明らかに、ある時点で基礎となるシステムと対話する必要があります。 JDK内では、Javaコードがメモリ/タイプセーフティ違反を引き起こしたバックドアを使用していた場合、非常にまれに脆弱性がありました（ただし、ほとんどの主張は異なる脆弱性を誤って報告しています）。少なくとも1つのケース、JVM自体は、特定の構成で配列の境界チェックを誤って計算する可能性があります。
セキュリティが導入されるとき、それは通常それなしでは考えられないであろう何かをすることを容易にすることです。 Javaオペレーティングシステムの取り組みの典型的な例は、プロセスを分離せずに実行しようとしましたが、これは明らかにひどい悪い考えです。これの理由の1つは、Javaの動的な性質が高いオーバーヘッドにつながることです。別のケースはJava 2セキュリティモデル（モバイルコード用）です。その試みまたは以前の試みを使用して、グローバルステートを許可する場合は、ガッツが発生します。
Rustベースのオペレーティングシステムでは、多くの試みが行われています。 Rustガベージコレクションされていない、手動追跡手法を使用したメモリセーフな言語です。ただし、gc自体が唯一のパフォーマンスの問題ではありません。配列の境界チェックがおそらくより重要です。チェックは動的な性質のため、Javaで最適化するのは困難です。
2か月分のハードウェア開発のパフォーマンスを、はるかに安全で高速なシステム開発に交換しますか？ほとんどの場合、それは本当に簡単です。 OSで費やされる重要なプロセッサ時間はどれくらいですか？アプリケーションコードを実行したい！ 1％の場合、パフォーマンスの問題は、マシンが文字通り昨日のハードウェアとして機能していることです。ただし、新しいOSを牽引することは容易ではありません。 C/UNIX以外のOSの場合、実際には不可能です。
また、ハードリアルタイムはトリッキーです。