mirror of
https://github.com/openeuler-riscv/boringssl.git
synced 2026-04-28 08:23:03 +00:00
Use relative links in markdown files
Our repository is sometimes copied into other repositories, at which point all the absolute links don't work. README.md used "./whatever", which seems to work most consistently, so copy that. Change-Id: I63bbf01b8f3870112d1df571adaa6cc82f58e5eb Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/64347 Commit-Queue: David Benjamin <davidben@google.com> Auto-Submit: David Benjamin <davidben@google.com> Commit-Queue: Bob Beck <bbe@google.com> Reviewed-by: Hubert Chao <hchao@google.com> Reviewed-by: Bob Beck <bbe@google.com>
This commit is contained in:
committed by
Boringssl LUCI CQ
parent
58906eab92
commit
90004f080d
@@ -1,7 +1,7 @@
|
|||||||
# BoringSSL API Conventions
|
# BoringSSL API Conventions
|
||||||
|
|
||||||
This document describes conventions for BoringSSL APIs. The [style
|
This document describes conventions for BoringSSL APIs. The [style
|
||||||
guide](/STYLE.md) also includes guidelines, but this document is targeted at
|
guide](./STYLE.md) also includes guidelines, but this document is targeted at
|
||||||
both API consumers and developers.
|
both API consumers and developers.
|
||||||
|
|
||||||
|
|
||||||
|
|||||||
@@ -8,7 +8,7 @@
|
|||||||
|
|
||||||
The standalone CMake build is primarily intended for developers. If embedding
|
The standalone CMake build is primarily intended for developers. If embedding
|
||||||
BoringSSL into another project with a pre-existing build system, see
|
BoringSSL into another project with a pre-existing build system, see
|
||||||
[INCORPORATING.md](/INCORPORATING.md).
|
[INCORPORATING.md](./INCORPORATING.md).
|
||||||
|
|
||||||
Unless otherwise noted, build tools must at most five years old, matching
|
Unless otherwise noted, build tools must at most five years old, matching
|
||||||
[Abseil guidelines](https://abseil.io/about/compatibility). If in doubt, use the
|
[Abseil guidelines](https://abseil.io/about/compatibility). If in doubt, use the
|
||||||
|
|||||||
@@ -1,7 +1,7 @@
|
|||||||
# Incorporating BoringSSL into a project
|
# Incorporating BoringSSL into a project
|
||||||
|
|
||||||
**Note**: if your target project is not a Google project then first read the
|
**Note**: if your target project is not a Google project then first read the
|
||||||
[main README](/README.md) about the purpose of BoringSSL.
|
[main README](./README.md) about the purpose of BoringSSL.
|
||||||
|
|
||||||
If you are porting BoringSSL to a new platform see
|
If you are porting BoringSSL to a new platform see
|
||||||
["go/boringssl-on-new-platform"](https://goto.corp.google.com/boringssl-on-new-platform) (Google
|
["go/boringssl-on-new-platform"](https://goto.corp.google.com/boringssl-on-new-platform) (Google
|
||||||
@@ -68,7 +68,7 @@ outside of the CMake environment, these intermediates are generated once and
|
|||||||
checked into the incorporating project's source repository. This avoids
|
checked into the incorporating project's source repository. This avoids
|
||||||
incorporating projects needing to support Perl and Go in their build systems.
|
incorporating projects needing to support Perl and Go in their build systems.
|
||||||
|
|
||||||
The script [`util/generate_build_files.py`](/util/generate_build_files.py)
|
The script [`util/generate_build_files.py`](./util/generate_build_files.py)
|
||||||
expects to be run from the `third_party/boringssl` directory and to find the
|
expects to be run from the `third_party/boringssl` directory and to find the
|
||||||
BoringSSL source code in `src/`. You should pass it a single argument: the name
|
BoringSSL source code in `src/`. You should pass it a single argument: the name
|
||||||
of the build system that you're using. If you don't use any of the supported
|
of the build system that you're using. If you don't use any of the supported
|
||||||
@@ -76,7 +76,7 @@ build systems then you should augment `generate_build_files.py` with support
|
|||||||
for it.
|
for it.
|
||||||
|
|
||||||
The script will pregenerate the intermediate files (see
|
The script will pregenerate the intermediate files (see
|
||||||
[BUILDING.md](/BUILDING.md) for details about which tools will need to be
|
[BUILDING.md](./BUILDING.md) for details about which tools will need to be
|
||||||
installed) and output helper files for that build system. It doesn't generate a
|
installed) and output helper files for that build system. It doesn't generate a
|
||||||
complete build script, just file and test lists, which change often. For
|
complete build script, just file and test lists, which change often. For
|
||||||
example, see the
|
example, see the
|
||||||
|
|||||||
@@ -21,7 +21,7 @@ would be a sandbox escape.
|
|||||||
|
|
||||||
This document attempts to describe these baseline OS dependencies and long-lived
|
This document attempts to describe these baseline OS dependencies and long-lived
|
||||||
internal resources. These dependencies may change over time, but we aim to
|
internal resources. These dependencies may change over time, but we aim to
|
||||||
[work with sandboxed consumers](/BREAKING-CHANGES.md) when they do. However,
|
[work with sandboxed consumers](./BREAKING-CHANGES.md) when they do. However,
|
||||||
each sandbox imposes different constraints, so, above all, sandboxed consumers
|
each sandbox imposes different constraints, so, above all, sandboxed consumers
|
||||||
must have ample test coverage to detect issues as they arise.
|
must have ample test coverage to detect issues as they arise.
|
||||||
|
|
||||||
|
|||||||
@@ -8,11 +8,11 @@ Please note that we cannot answer questions about FIPS, nor about using BoringSS
|
|||||||
|
|
||||||
BoringCrypto has undergone the following validations:
|
BoringCrypto has undergone the following validations:
|
||||||
|
|
||||||
1. 2017-06-15: certificate [#2964](https://csrc.nist.gov/Projects/Cryptographic-Module-Validation-Program/Certificate/2964), [security policy](/crypto/fipsmodule/policydocs/BoringCrypto-Security-Policy-20170615.docx) (in docx format).
|
1. 2017-06-15: certificate [#2964](https://csrc.nist.gov/Projects/Cryptographic-Module-Validation-Program/Certificate/2964), [security policy](./policydocs/BoringCrypto-Security-Policy-20170615.docx) (in docx format).
|
||||||
1. 2018-07-30: certificate [#3318](https://csrc.nist.gov/Projects/Cryptographic-Module-Validation-Program/Certificate/3318), [security policy](/crypto/fipsmodule/policydocs/BoringCrypto-Security-Policy-20180730.docx) (in docx format).
|
1. 2018-07-30: certificate [#3318](https://csrc.nist.gov/Projects/Cryptographic-Module-Validation-Program/Certificate/3318), [security policy](./policydocs/BoringCrypto-Security-Policy-20180730.docx) (in docx format).
|
||||||
1. 2019-08-08: certificate [#3678](https://csrc.nist.gov/Projects/Cryptographic-Module-Validation-Program/Certificate/3678), [security policy](/crypto/fipsmodule/policydocs/BoringCrypto-Security-Policy-20190808.docx) (in docx format).
|
1. 2019-08-08: certificate [#3678](https://csrc.nist.gov/Projects/Cryptographic-Module-Validation-Program/Certificate/3678), [security policy](./policydocs/BoringCrypto-Security-Policy-20190808.docx) (in docx format).
|
||||||
1. 2019-10-20: certificate [#3753](https://csrc.nist.gov/Projects/Cryptographic-Module-Validation-Program/Certificate/3753), [security policy](/crypto/fipsmodule/policydocs/BoringCrypto-Android-Security-Policy-20191020.docx) (in docx format).
|
1. 2019-10-20: certificate [#3753](https://csrc.nist.gov/Projects/Cryptographic-Module-Validation-Program/Certificate/3753), [security policy](./policydocs/BoringCrypto-Android-Security-Policy-20191020.docx) (in docx format).
|
||||||
1. 2021-01-28: certificate [#4156](https://csrc.nist.gov/Projects/Cryptographic-Module-Validation-Program/Certificate/4156), [security policy](/crypto/fipsmodule/policydocs/BoringCrypto-Android-Security-Policy-20210319.docx) (in docx format).
|
1. 2021-01-28: certificate [#4156](https://csrc.nist.gov/Projects/Cryptographic-Module-Validation-Program/Certificate/4156), [security policy](./policydocs/BoringCrypto-Android-Security-Policy-20210319.docx) (in docx format).
|
||||||
1. 2021-04-29: certificate [#4407](https://csrc.nist.gov/projects/cryptographic-module-validation-program/certificate/4407).
|
1. 2021-04-29: certificate [#4407](https://csrc.nist.gov/projects/cryptographic-module-validation-program/certificate/4407).
|
||||||
|
|
||||||
## Running ACVP tests
|
## Running ACVP tests
|
||||||
@@ -89,7 +89,7 @@ The most obvious cause of relocations are out-calls from the module to non-crypt
|
|||||||
|
|
||||||
Offsets to these functions cannot be known until the final link because only the linker sees the object files containing them. Thus calls to these functions are rewritten into an IP-relative jump to a redirector function. The redirector functions contain a single jump instruction to the real function and are placed outside of the module and are thus not hashed (see diagram).
|
Offsets to these functions cannot be known until the final link because only the linker sees the object files containing them. Thus calls to these functions are rewritten into an IP-relative jump to a redirector function. The redirector functions contain a single jump instruction to the real function and are placed outside of the module and are thus not hashed (see diagram).
|
||||||
|
|
||||||

|

|
||||||
|
|
||||||
In this diagram, the integrity check hashes from `module_start` to `module_end`. Since this does not cover the jump to `memcpy`, it's fine that the linker will poke the final offset into that instruction.
|
In this diagram, the integrity check hashes from `module_start` to `module_end`. Since this does not cover the jump to `memcpy`, it's fine that the linker will poke the final offset into that instruction.
|
||||||
|
|
||||||
@@ -121,7 +121,7 @@ In order to actually implement the integrity test, a constructor function within
|
|||||||
|
|
||||||
Initially the known-good value will be incorrect. Another script (`inject_hash.go`) calculates the correct value from the assembled object and injects it back into the object.
|
Initially the known-good value will be incorrect. Another script (`inject_hash.go`) calculates the correct value from the assembled object and injects it back into the object.
|
||||||
|
|
||||||

|

|
||||||
|
|
||||||
### Comparison with OpenSSL's method
|
### Comparison with OpenSSL's method
|
||||||
|
|
||||||
@@ -141,4 +141,4 @@ Some of the similarities are worth noting:
|
|||||||
|
|
||||||
1. OpenSSL has all out-calls from the module indirecting via the PLT, which is equivalent to the redirector functions described above.
|
1. OpenSSL has all out-calls from the module indirecting via the PLT, which is equivalent to the redirector functions described above.
|
||||||
|
|
||||||

|

|
||||||
|
|||||||
Reference in New Issue
Block a user