もともと、Linux Kernelのソースコードの一部なので、GPLv2扱いになる（はずの認識）。
https://www.kernel.org/doc/html/latest/index.html
Licensing documentation
The following describes the license of the Linux kernel source code (GPLv2), how to properly mark the license of individual files in the source tree, as well as links to the full license text.
https://www.kernel.org/doc/html/latest/process/license-rules.html#kernel-licensing
Kernel Self-Protection（の続き）
Probabilistic defenses
While many protections can be considered deterministic (e.g. read-only memory cannot be written to), some protections provide only statistical defense, in that an attack must gather enough information about a running system to overcome the defense.
多くのprotectionは決定的ですが（例えば、read only memoryには書き込むことはできない）、いくつかのprotectionは統計的な保護になります。これは、攻撃者は防御を降服するためにに、稼働中のシステムに十分な情報を得ようとします。
While not perfect, these do provide meaningful defenses.
これは完全ではありませんが、価値のある防御になります。
Canaries, blinding, and other secrets
It should be noted that things like the stack canary discussed earlier are technically statistical defenses, since they rely on a secret value, and such values may become discoverable through an information exposure flaw.
これまで議論してstack canaryのようなものは、統計的な防御技術である。隠された値に関連付けられ、情報漏洩の欠陥によって、発見される可能性があります。
.
Blinding literal values for things like JITs, where the executable contents may be partially under the control of userspace, need a similar secret value.
ユーザー空間の制御化で実行可能コンテンツが存在する可能性がある、JITのようにリテラル値を不可視にする場合にも、隠された値が必要になります。
.
It is critical that the secret values used must be separate (e.g. different canary per stack) and high entropy (e.g. is the RNG actually working?) in order to maximize their success.
隠された値は分離されていなければならない（例えば、stack事に異なるcanaryである）、あるいは、高いエントロピーを持つ（RNGを実際に動かす）ことが重要である。この成果を最大化するためには。
Kernel Address Space Layout Randomization (KASLR)
Since the location of kernel memory is almost always instrumental in mounting a successful attack, making the location non-deterministic raises the difficulty of an exploit.
カーネルメモリの位置は多くの場合攻撃を成功させるための手段になります。場所を非特定的にすることで、攻撃の難易度を高められます。
(Note that this in turn makes the value of information exposures higher, since they may be used to discover desired memory locations.)
（これにより、情報漏洩の可能性が高くなることに注意してください。情報漏洩は必要なメモリ市を発見するためにも使用されます）。
Text and module base
By relocating the physical and virtual base address of the kernel at boot-time (CONFIG_RANDOMIZE_BASE), attacks needing kernel code will be frustrated.
起動時にカーネルにとっての、物理と仮想を再定義することでカーネルコードに対する攻撃は挫折するでしょうす(CONFIG_RANDOMIZE_BASE)。、
Additionally, offsetting the module loading base address means that even systems that load the same set of modules in the same order every boot will not share a common base address with the rest of the kernel text.
更に、moduleをロードするベースアドレスをオフセットすることで、ブート頃に同じモジュール集合を同じ順番でロードしても、カーネルのテキスト領域と共通のベースアドレスを共有しなくなります。
Stack base
If the base address of the kernel stack is not the same between processes, or even not the same between syscalls, targets on or beyond the stack become more difficult to locate.
カーネルスタックのベースアドレスがプロセス間で一致しない場合、同じsyscalls館で同様または違っていても、stack上、あるいはstackを越えたターゲットを発見するのが更に難しくなります。
Dynamic memory base
Much of the kernel’s dynamic memory (e.g. kmalloc, vmalloc, etc) ends up being relatively deterministic in layout due to the order of early-boot initializations.
kernelの動的確保されるメモリの多くは、初期の希望時点の順番によって、レイアウトが比較的確定的になります（kmalloc,vmalloc等）。
If the base address of these areas is not the same between boots, targeting them is frustrated, requiring an information exposure specific to the region.
これらの領域のベースアドレスが起動時に一致しない場合、それらを対象とすることは難しくなり、領域に対して情報が必要となります。
Structure layout
By performing a per-build randomization of the layout of sensitive structures, attacks must either be tuned to known kernel builds or expose enough kernel memory to determine structure layouts before manipulating them.
機密情報の構造体のレイアウトをビルド毎にランダム化することで、既知のkernel buildに合わせて攻撃を調整するか、操作する前に構造を判断できるだけの十分なkernel memoryの露出が必要となります。
Preventing Information Exposures
Since the locations of sensitive structures are the primary target for attacks, it is important to defend against exposure of both kernel memory addresses and kernel memory contents
機密情報の構造体の位置が、攻撃する際の主な対象となるため、kernel memory addressとkernel memory contentsの両方の露出を防ぐことが重要です。
(since they may contain kernel addresses or other sensitive things like canary values).
（kernel addressやカナリア値のような他の機密情報が含まれている可能性があります）
Kernel addresses
Printing kernel addresses to userspace leaks sensitive information about the kernel memory layout.
ユーザー空間に対してカーネルのアドレスを表示する事は、カーネルのメモリレイアウトに関して機密情報を漏洩しています。
Care should be exercised when using any printk specifier that prints the raw address, currently %px, %p[ad], (and %p[sSb] in certain circumstances [*]).
生のアドレスを出力するprintk記述子を使用する場合には、十分な注意が必要になります（現在は、 %px, %p[ad], 特定の状況では %p[sSb] 。[*] 参照)。
Any file written to using one of these specifiers should be readable only by privileged processes.
これらの記述子を利用して書き込まれたファイルは、特権権限あるプロセスによってのみ読み込み可能であるべきです。
.
Kernels 4.14 and older printed the raw address using %p.
4.14とそれ以前のカーネルでは、生のアドレス表示には%pを使って出力していました。
As of 4.15-rc1 addresses printed with the specifier %p are hashed before printing.
4.15-rc1以降では、アドレスは表示する前に%p記述子はマスクハッシュ化されます。
.
[*] If KALLSYMS is enabled and symbol lookup fails, the raw address is printed.
KALLSYMSが有効で、symbol lookup が失敗した場合、raw addressが表示されます。
If KALLSYMS is not enabled the raw address is printed.
KALLSMYSが有効ではない場合、raw addressが表示されます。
.
Unique identifiers
Kernel memory addresses must never be used as identifiers exposed to userspace.
カーネルメモリアドレスは、ユーザー空間に公開される識別子として使用しないでください。
Instead, use an atomic counter, an idr, or similar unique identifier.
その代わりに、atomic counter、idr、類似のユニークな識別子を用いてください。
Memory initialization
Memory copied to userspace must always be fully initialized.
ユーザー空間にコピーされるメモリは、必ず完全に初期化されなければならない。
If not explicitly memset(), this will require changes to the compiler to make sure structure holes are cleared.
明示的にmemset()できていない場合には、コンパイラが構造体の穴を防ぐように変更しなければならない。
Memory poisoning
When releasing memory, it is best to poison the contents, to avoid reuse attacks that rely on the old contents of memory.
メモリを解放したときに、メモリの古いコンテンツを再利用される攻撃を防ぐためには、コンテンツを汚染するのが最良です。
E.g., clear stack on a syscall return (CONFIG_GCC_PLUGIN_STACKLEAK), wipe heap memory on a free.
例えば、syscall から復帰したときのstackをクリアする(CONFIG_GCC_PLUGIN_STACKLEAK)で、解放されたheap memoryを拭うことができます。
This frustrates many uninitialized variable attacks, stack content exposures, heap content exposures, and use-after-free attacks.
これは、多くの、未初期化変数攻撃、スタックコンテキスト露出、heapコンテンツ露出、未開放メモリ攻撃を防ぐことができます。
Destination tracking
To help kill classes of bugs that result in kernel addresses being written to userspace, the destination of writes needs to be tracked.
カーネルアドレスがユーザー空間に書き込まれる原因となるクラスを止めるためには、書き込み先を追跡する必要があります。
If the buffer is destined for userspace (e.g. seq_file backed /proc files), it should automatically censor sensitive values.
バッファがuserspaceを出力とするならば（例えば、/proc filesを背景とするseq_file)、機密値は自動的に検閲されます。