Inferencium/website
1
0
Fork 0
Code Issues Activity

Fix line lengths to conform to code style

Browse Source
This commit is contained in:
inference 2023-10-08 08:56:52 +01:00
parent 30134a21a0
commit 1e4e4e0314
Signed by: inference
SSH Key Fingerprint: SHA256:FtEVfx1CmTKMy40VwZvF4k+3TC+QhCWy+EmPRg50Nnc
2 changed files with 35 additions and 30 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

50
documentation/hardened_malloc.html
View File

@ -5,7 +5,7 @@
<!-- Copyright 2023 Jake Winters -->
<!-- SPDX-License-Identifier: BSD-3-Clause -->
<!-- Version: 1.0.2-alpha.2+14 -->
<!-- Version: 1.0.2-alpha.3+15 -->
<html>
@ -33,11 +33,12 @@
<h1 id="introduction"><a href="#introduction">Documentation - GrapheneOS hardened_malloc</a></h1>
<p>This documentation contains instructions to use
<a href="https://github.com/GrapheneOS/hardened_malloc">GrapheneOS hardened_malloc</a>
memory allocator as the system's default memory allocator. These instructions apply to both musl
and glibc C libraries on Unix-based and Unix-like systems. hardened_malloc can also be used
per-application and/or per-user, in which case root permissions are not required; this
documentation focuses on system-wide usage of hardened_malloc, assumes root privileges, and
assumes the compiled library will be located in a path readable by all users of the system.</p>
memory allocator as the system's default memory allocator. These instructions apply to
both musl and glibc C libraries on Unix-based and Unix-like systems. hardened_malloc can
also be used per-application and/or per-user, in which case root permissions are not
required; this documentation focuses on system-wide usage of hardened_malloc, assumes
root privileges, and assumes the compiled library will be located in a path readable by
all users of the system.</p>
<p>For the complete hardened_malloc documentation, visit its
<a href="https://github.com/GrapheneOS/hardened_malloc#hardened_malloc">official documentation</a>.</p>
<p>This documentation is also available in portable AsciiDoc format in my
@ -57,8 +58,9 @@
</section>
<section id="memory_pages">
<h2 id="memory_pages"><a href="#memory_pages">Increase Permitted Amount of Memory Pages</a></h2>
<p>Add <code>vm.max_map_count = 1048576</code> to <code>/etc/sysctl.conf</code>
to accommodate hardened_malloc’s large amount of guard pages.</p>
<p>Add <code>vm.max_map_count = 1048576</code> to
<code>/etc/sysctl.conf</code> to accommodate hardened_malloc’s large
amount of guard pages.</p>
</section>
<section id="clone_source_code">
<h2 id="clone_source_code"><a href="#clone_source_code">Clone hardened_malloc Source Code</a></h2>
@ -71,25 +73,27 @@
<section id="compile">
<h2 id="compile"><a href="#compile">Compile hardened_malloc</a></h2>
<p><p><code>$ make &lt;arguments&gt;</code></p>
<p><code>CONFIG_N_ARENA=<var>n</var></code> can be adjusted to increase parallel
performance at the expense of memory usage, or decrease memory usage at the
expense of parallel performance, where <var>n</var> is an integer. Higher values
prefer parallel performance, lower values prefer lower memory usage. The number
of arenas has no impact on the security properties of hardened_malloc.
<p><code>CONFIG_N_ARENA=<var>n</var></code> can be adjusted to increase
parallel performance at the expense of memory usage, or decrease memory
usage at the expense of parallel performance, where <var>n</var> is an
integer. Higher values prefer parallel performance, lower values prefer
lower memory usage. The number of arenas has no impact on the security
properties of hardened_malloc.
<ul>
<li>Minimum number of arenas: 1</li>
<li>Maximum number of arenas: 256</li>
</ul>
<p>For extra security, <code>CONFIG_SEAL_METADATA=true</code> can be used in
order to control whether Memory Protection Keys are used to disable access to
all writable allocator state outside of the memory allocator code. It’s
currently disabled by default due to a significant performance cost for this use
case on current generation hardware. Whether or not this feature is enabled, the
metadata is all contained within an isolated memory region with high entropy
random guard regions around it.</p>
<p>For low-memory systems, <code>VARIANT=light</code> can be used to compile the
light variant of hardened_malloc, which sacrifices some security for much less
memory usage.</p>
<p>For extra security, <code>CONFIG_SEAL_METADATA=true</code> can be
used in order to control whether Memory Protection Keys are used to
disable access to all writable allocator state outside of the memory
allocator code. It’s currently disabled by default due to a significant
performance cost for this use case on current generation hardware.
Whether or not this feature is enabled, the metadata is all contained
within an isolated memory region with high entropy random guard regions
around it.</p>
<p>For low-memory systems, <code>VARIANT=light</code> can be used to
compile the light variant of hardened_malloc, which sacrifices some
security for much less memory usage.</p>
<p>For all compile-time options, see the
<a href="https://github.com/GrapheneOS/hardened_malloc#configuration">configuration section</a>
of hardened_malloc’s extensive official documentation.</p>

15
documentation/openssl_selfsigned_certificate_chain.html
View File

@ -5,7 +5,7 @@
<!-- Copyright 2023 Jake Winters -->
<!-- SPDX-License-Identifier: BSD-3-Clause -->
<!-- Version: 1.0.2-alpha.1+9 -->
<!-- Version: 1.0.2-alpha.2+10 -->
<html>
@ -31,12 +31,13 @@
</div>
<section id="introduction">
<h1 id="introduction"><a href="#introduction">Documentation - OpenSSL Self-signed Certificate Chain</a></h1>
<p>This documentation contains the complete set of commands to create a new OpenSSL self-signed
certificate chain with V3 subjectAltName (SAN) extensions enabled. Multiple SANs can be included
in a certificate by adding each domain as a comma-delimited string. Each key can be encrypted or
unencrypted, with multiple encryption options; AES (<code>aes128</code> or <code>aes256</code>)
is recommended. Optional verification can also be performed between multiple levels of
certificates to ensure the chain of trust is valid.</p>
<p>This documentation contains the complete set of commands to create a new OpenSSL
self-signed certificate chain with V3 subjectAltName (SAN) extensions enabled. Multiple
SANs can be included in a certificate by adding each domain as a comma-delimited string.
Each key can be encrypted or unencrypted, with multiple encryption options; AES
(<code>aes128</code> or <code>aes256</code>) is recommended. Optional verification can
also be performed between multiple levels of certificates to ensure the chain of trust
is valid.</p>
<p>This documentation is also available in portable AsciiDoc format in my
<a href="https://src.inferencium.net/Inferencium/doc/src/branch/stable/security/openssl_selfsigned_certificate_chain.adoc">documentation source code repository</a>.
</section>