Skip to content

Commit e0b943f

Browse files
jsfakianeriknordmark
authored andcommitted
Added vendor dir to pkg/installer
Added the required vendor dir for the interactive mode of the installer Signed-off-by: Ioannis Sfakianakis <[email protected]>
1 parent db4f3f3 commit e0b943f

File tree

4,748 files changed

+1533696
-1
lines changed

Some content is hidden

Large Commits have some content hidden by default. Use the searchbox below for content that may be hidden.

4,748 files changed

+1533696
-1
lines changed

.codespellrc

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -4,4 +4,4 @@
44

55
[codespell]
66
skip = ./.git/*,*/vendor/*,./conf/v2tlsbaseroot-certificates.pem,./pkg/gpt-tools/patches/*,./pkg/new-kernel/*,./pkg/kernel/*,./pkg/fw/*
7-
ignore-words-list = uptodate,synopsys
7+
ignore-words-list = uptodate,synopsys,crate

.gitignore

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -26,3 +26,4 @@ pkg/external-boot-image/build.yml
2626
tools/compare-sbom-sources/vendor
2727
tools/get-deps/get-deps
2828
tools/get-deps/vendor
29+
pkg/installer/target

.spdxignore

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -9,3 +9,4 @@ pkg/recovertpm/src/vendor/
99
pkg/rngd/cmd/rngd/vendor/
1010
pkg/wwan/mmagent/vendor/
1111
tools/get-deps/vendor/
12+
pkg/installer/vendor/

.yetus-excludes

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -16,3 +16,4 @@
1616
^tests/eden/eclient/testdata/maridb\.txt
1717
^pkg/apparmor/etc/
1818
^eve-tools/bpftrace-compiler/examples/.+\.bt
19+
^pkg/installer/vendor/

.yetus/excludes.txt

Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -9,6 +9,7 @@
99
^pkg/kvm-tools/include
1010
^pkg/kvm-tools/dtrace
1111
^pkg/kube/kubevirt-operator.yaml
12+
^pkg/installer/vendor/
1213
^api/python/
1314
^api/go/
1415
^api/images/
Lines changed: 1 addition & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1 @@
1+
{"files":{"Cargo.toml":"ddcbd9309cebf3ffd26f87e09bb8f971793535955ebfd9a7196eba31a53471f8","FAQ.md":"9eb41898523ee209a0a937f9bcb78afe45ad55ca0556f8a4d4063558098f6d1e","LICENSE-APACHE":"a60eea817514531668d7e00765731449fe14d059d3249e0bc93b36de45f759f2","LICENSE-MIT":"0444c6991eead6822f7b9102e654448d51624431119546492e8b231db42c48bb","README.md":"d7f74d616a751bcca23d5d3b58a6daf556356a526c5f0b6aa0504715d176549a","build.rs":"23cbf4cf1b742e2c4da8bc58d06d1d021479dec80cec6a0bc3704c7172e2864a","rustfmt.toml":"e090969e99df9360705680cc0097cfaddae10c22dc2e01470592cf3b9787fd36","src/aes_hash.rs":"013602aec42150e59ba9ed6135525a624a4b42c1b1328b9857ec238aa12c3178","src/convert.rs":"54e49f93d51665366923d4d815cfd67790d3c769e84ab4386ba97f928d17d1bd","src/fallback_hash.rs":"a82451f6458a6e7a7e7da82a3c982e9bb825a2092ab79c41459d8011775fb0b1","src/hash_map.rs":"5ee97baa64fa528ba9c01bd018332c4974846c4813c6f8c30cee9f3546598f1c","src/hash_quality_test.rs":"1a560a181a804791bc6ad797df5352cdd87123fed7f19f659de0c2d883248bed","src/hash_set.rs":"360e55d066b44624f06e49efa140c03fda635fb17a59622cc29a83830bd1f263","src/lib.rs":"e2f4e7bfcf2807c73e3b8d3b1bd83c6789313b6b55edd59e15e04146e55e01b6","src/operations.rs":"38ed2b48a13d826c48ede5f304c9c2572c0c8f64ac8ac5a1ed4e112e536f3a97","src/random_state.rs":"03f40a654cfca2e00a2dabd21c85368ee50b8b6289efe98ea1745b25c721b9c6","src/specialize.rs":"56354db8a0f7e6ee1340a08f2ab6f79a0ff439fd61badac5e7e59fe4f4a653ba","tests/bench.rs":"7a425f564201560f9a8fb6c77f91f29bb88ec815b10bd27d15740c922a4f928e","tests/map_tests.rs":"e56b6f700e3b1176210e4b266d7a42b3263e966e5e565d53b1bc27af7a87168e","tests/nopanic.rs":"0d28a46248d77283941db1d9fd154c68b965c81a0e3db1fe4a43e06fc448da8f"},"package":"e89da841a80418a9b391ebaea17f5c112ffaaa96f621d2c285b5174da76b9011"}

pkg/installer/vendor/ahash/Cargo.toml

Lines changed: 167 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,167 @@
1+
# THIS FILE IS AUTOMATICALLY GENERATED BY CARGO
2+
#
3+
# When uploading crates to the registry Cargo will automatically
4+
# "normalize" Cargo.toml files for maximal compatibility
5+
# with all versions of Cargo and also rewrite `path` dependencies
6+
# to registry (e.g., crates.io) dependencies.
7+
#
8+
# If you are reading this file be aware that the original Cargo.toml
9+
# will likely look very different (and much more reasonable).
10+
# See Cargo.toml.orig for the original contents.
11+
12+
[package]
13+
edition = "2018"
14+
rust-version = "1.60.0"
15+
name = "ahash"
16+
version = "0.8.11"
17+
authors = ["Tom Kaitchuck <[email protected]>"]
18+
build = "./build.rs"
19+
exclude = [
20+
"/smhasher",
21+
"/benchmark_tools",
22+
]
23+
description = "A non-cryptographic hash function using AES-NI for high performance"
24+
documentation = "https://docs.rs/ahash"
25+
readme = "README.md"
26+
keywords = [
27+
"hash",
28+
"hasher",
29+
"hashmap",
30+
"aes",
31+
"no-std",
32+
]
33+
categories = [
34+
"algorithms",
35+
"data-structures",
36+
"no-std",
37+
]
38+
license = "MIT OR Apache-2.0"
39+
repository = "https://github.com/tkaitchuck/ahash"
40+
41+
[package.metadata.docs.rs]
42+
features = ["std"]
43+
rustc-args = [
44+
"-C",
45+
"target-feature=+aes",
46+
]
47+
rustdoc-args = [
48+
"-C",
49+
"target-feature=+aes",
50+
]
51+
52+
[profile.bench]
53+
opt-level = 3
54+
lto = "fat"
55+
codegen-units = 1
56+
debug = 0
57+
debug-assertions = false
58+
59+
[profile.release]
60+
opt-level = 3
61+
lto = "fat"
62+
codegen-units = 1
63+
debug = 0
64+
debug-assertions = false
65+
66+
[profile.test]
67+
opt-level = 2
68+
lto = "fat"
69+
70+
[lib]
71+
name = "ahash"
72+
path = "src/lib.rs"
73+
test = true
74+
doctest = true
75+
bench = true
76+
doc = true
77+
78+
[[bench]]
79+
name = "ahash"
80+
path = "tests/bench.rs"
81+
harness = false
82+
83+
[[bench]]
84+
name = "map"
85+
path = "tests/map_tests.rs"
86+
harness = false
87+
88+
[dependencies.atomic-polyfill]
89+
version = "1.0.1"
90+
optional = true
91+
92+
[dependencies.cfg-if]
93+
version = "1.0"
94+
95+
[dependencies.const-random]
96+
version = "0.1.17"
97+
optional = true
98+
99+
[dependencies.getrandom]
100+
version = "0.2.7"
101+
optional = true
102+
103+
[dependencies.serde]
104+
version = "1.0.117"
105+
optional = true
106+
107+
[dependencies.zerocopy]
108+
version = "0.7.31"
109+
features = ["simd"]
110+
default-features = false
111+
112+
[dev-dependencies.criterion]
113+
version = "0.3.2"
114+
features = ["html_reports"]
115+
116+
[dev-dependencies.fnv]
117+
version = "1.0.5"
118+
119+
[dev-dependencies.fxhash]
120+
version = "0.2.1"
121+
122+
[dev-dependencies.hashbrown]
123+
version = "0.14.3"
124+
125+
[dev-dependencies.hex]
126+
version = "0.4.2"
127+
128+
[dev-dependencies.no-panic]
129+
version = "0.1.10"
130+
131+
[dev-dependencies.pcg-mwc]
132+
version = "0.2.1"
133+
134+
[dev-dependencies.rand]
135+
version = "0.8.5"
136+
137+
[dev-dependencies.seahash]
138+
version = "4.0"
139+
140+
[dev-dependencies.serde_json]
141+
version = "1.0.59"
142+
143+
[dev-dependencies.smallvec]
144+
version = "1.13.1"
145+
146+
[build-dependencies.version_check]
147+
version = "0.9.4"
148+
149+
[features]
150+
atomic-polyfill = [
151+
"dep:atomic-polyfill",
152+
"once_cell/atomic-polyfill",
153+
]
154+
compile-time-rng = ["const-random"]
155+
default = [
156+
"std",
157+
"runtime-rng",
158+
]
159+
nightly-arm-aes = []
160+
no-rng = []
161+
runtime-rng = ["getrandom"]
162+
std = []
163+
164+
[target."cfg(not(all(target_arch = \"arm\", target_os = \"none\")))".dependencies.once_cell]
165+
version = "1.18.0"
166+
features = ["alloc"]
167+
default-features = false

pkg/installer/vendor/ahash/FAQ.md

Lines changed: 118 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,118 @@
1+
## How does aHash prevent DOS attacks
2+
3+
AHash is designed to [prevent an adversary that does not know the key from being able to create hash collisions or partial collisions.](https://github.com/tkaitchuck/aHash/wiki/How-aHash-is-resists-DOS-attacks)
4+
5+
If you are a cryptographer and would like to help review aHash's algorithm, please post a comment [here](https://github.com/tkaitchuck/aHash/issues/11).
6+
7+
In short, this is achieved by ensuring that:
8+
9+
* aHash is designed to [resist differential crypto analysis](https://github.com/tkaitchuck/aHash/wiki/How-aHash-is-resists-DOS-attacks#differential-analysis). Meaning it should not be possible to devise a scheme to "cancel" out a modification of the internal state from a block of input via some corresponding change in a subsequent block of input.
10+
* This is achieved by not performing any "premixing" - This reversible mixing gave previous hashes such as murmurhash confidence in their quality, but could be undone by a deliberate attack.
11+
* Before it is used each chunk of input is "masked" such as by xoring it with an unpredictable value.
12+
* aHash obeys the '[strict avalanche criterion](https://en.wikipedia.org/wiki/Avalanche_effect#Strict_avalanche_criterion)':
13+
Each bit of input has the potential to flip every bit of the output.
14+
* Similarly, each bit in the key can affect every bit in the output.
15+
* Input bits never effect just one, or a very few, bits in intermediate state. This is specifically designed to prevent the sort of
16+
[differential attacks launched by the sipHash authors](https://emboss.github.io/blog/2012/12/14/breaking-murmur-hash-flooding-dos-reloaded/) which cancel previous inputs.
17+
* The `finish` call at the end of the hash is designed to not expose individual bits of the internal state.
18+
* For example in the main algorithm 256bits of state and 256bits of keys are reduced to 64 total bits using 3 rounds of AES encryption.
19+
Reversing this is more than non-trivial. Most of the information is by definition gone, and any given bit of the internal state is fully diffused across the output.
20+
* In both aHash and its fallback the internal state is divided into two halves which are updated by two unrelated techniques using the same input. - This means that if there is a way to attack one of them it likely won't be able to attack both of them at the same time.
21+
* It is deliberately difficult to 'chain' collisions. (This has been the major technique used to weaponize attacks on other hash functions)
22+
23+
More details are available on [the wiki](https://github.com/tkaitchuck/aHash/wiki/How-aHash-is-resists-DOS-attacks).
24+
25+
## Why not use a cryptographic hash in a hashmap.
26+
27+
Cryptographic hashes are designed to make is nearly impossible to find two items that collide when the attacker has full control
28+
over the input. This has several implications:
29+
30+
* They are very difficult to construct, and have to go to a lot of effort to ensure that collisions are not possible.
31+
* They have no notion of a 'key'. Rather, they are fully deterministic and provide exactly one hash for a given input.
32+
33+
For a HashMap the requirements are different.
34+
35+
* Speed is very important, especially for short inputs. Often the key for a HashMap is a single `u32` or similar, and to be effective
36+
the bucket that it should be hashed to needs to be computed in just a few CPU cycles.
37+
* A hashmap does not need to provide a hard and fast guarantee that no two inputs will ever collide. Hence, hashCodes are not 256bits
38+
but are just 64 or 32 bits in length. Often the first thing done with the hashcode is to truncate it further to compute which among a few buckets should be used for a key.
39+
* Here collisions are expected, and a cheap to deal with provided there is no systematic way to generated huge numbers of values that all
40+
go to the same bucket.
41+
* This also means that unlike a cryptographic hash partial collisions matter. It doesn't do a hashmap any good to produce a unique 256bit hash if
42+
the lower 12 bits are all the same. This means that even a provably irreversible hash would not offer protection from a DOS attack in a hashmap
43+
because an attacker can easily just brute force the bottom N bits.
44+
45+
From a cryptography point of view, a hashmap needs something closer to a block cypher.
46+
Where the input can be quickly mixed in a way that cannot be reversed without knowing a key.
47+
48+
## Why isn't aHash cryptographically secure
49+
50+
It is not designed to be.
51+
Attempting to use aHash as a secure hash will likely fail to hold up for several reasons:
52+
53+
1. aHash relies on random keys which are assumed to not be observable by an attacker. For a cryptographic hash all inputs can be seen and controlled by the attacker.
54+
2. aHash has not yet gone through peer review, which is a pre-requisite for security critical algorithms.
55+
3. Because aHash uses reduced rounds of AES as opposed to the standard of 10. Things like the SQUARE attack apply to part of the internal state.
56+
(These are mitigated by other means to prevent producing collections, but would be a problem in other contexts).
57+
4. Like any cypher based hash, it will show certain statistical deviations from truly random output when comparing a (VERY) large number of hashes.
58+
(By definition cyphers have fewer collisions than truly random data.)
59+
60+
There are efforts to build a secure hash function that uses AES-NI for acceleration, but aHash is not one of them.
61+
62+
## How is aHash so fast
63+
64+
AHash uses a number of tricks.
65+
66+
One trick is taking advantage of specialization. If aHash is compiled on nightly it will take
67+
advantage of specialized hash implementations for strings, slices, and primitives.
68+
69+
Another is taking advantage of hardware instructions.
70+
When it is available aHash uses AES rounds using the AES-NI instruction. AES-NI is very fast (on an intel i7-6700 it
71+
is as fast as a 64 bit multiplication.) and handles 16 bytes of input at a time, while being a very strong permutation.
72+
73+
This is obviously much faster than most standard approaches to hashing, and does a better job of scrambling data than most non-secure hashes.
74+
75+
On an intel i7-6700 compiled on nightly Rust with flags `-C opt-level=3 -C target-cpu=native -C codegen-units=1`:
76+
77+
| Input | SipHash 1-3 time | FnvHash time|FxHash time| aHash time| aHash Fallback* |
78+
|----------------|-----------|-----------|-----------|-----------|---------------|
79+
| u8 | 9.3271 ns | 0.808 ns | **0.594 ns** | 0.7704 ns | 0.7664 ns |
80+
| u16 | 9.5139 ns | 0.803 ns | **0.594 ns** | 0.7653 ns | 0.7704 ns |
81+
| u32 | 9.1196 ns | 1.4424 ns | **0.594 ns** | 0.7637 ns | 0.7712 ns |
82+
| u64 | 10.854 ns | 3.0484 ns | **0.628 ns** | 0.7788 ns | 0.7888 ns |
83+
| u128 | 12.465 ns | 7.0728 ns | 0.799 ns | **0.6174 ns** | 0.6250 ns |
84+
| 1 byte string | 11.745 ns | 2.4743 ns | 2.4000 ns | **1.4921 ns** | 1.5861 ns |
85+
| 3 byte string | 12.066 ns | 3.5221 ns | 2.9253 ns | **1.4745 ns** | 1.8518 ns |
86+
| 4 byte string | 11.634 ns | 4.0770 ns | 1.8818 ns | **1.5206 ns** | 1.8924 ns |
87+
| 7 byte string | 14.762 ns | 5.9780 ns | 3.2282 ns | **1.5207 ns** | 1.8933 ns |
88+
| 8 byte string | 13.442 ns | 4.0535 ns | 2.9422 ns | **1.6262 ns** | 1.8929 ns |
89+
| 15 byte string | 16.880 ns | 8.3434 ns | 4.6070 ns | **1.6265 ns** | 1.7965 ns |
90+
| 16 byte string | 15.155 ns | 7.5796 ns | 3.2619 ns | **1.6262 ns** | 1.8011 ns |
91+
| 24 byte string | 16.521 ns | 12.492 ns | 3.5424 ns | **1.6266 ns** | 2.8311 ns |
92+
| 68 byte string | 24.598 ns | 50.715 ns | 5.8312 ns | **4.8282 ns** | 5.4824 ns |
93+
| 132 byte string| 39.224 ns | 119.96 ns | 11.777 ns | **6.5087 ns** | 9.1459 ns |
94+
|1024 byte string| 254.00 ns | 1087.3 ns | 156.41 ns | **25.402 ns** | 54.566 ns |
95+
96+
* Fallback refers to the algorithm aHash would use if AES instructions are unavailable.
97+
For reference a hash that does nothing (not even reads the input data takes) **0.520 ns**. So that represents the fastest
98+
possible time.
99+
100+
As you can see above aHash like `FxHash` provides a large speedup over `SipHash-1-3` which is already nearly twice as fast as `SipHash-2-4`.
101+
102+
Rust's HashMap by default uses `SipHash-1-3` because faster hash functions such as `FxHash` are predictable and vulnerable to denial of
103+
service attacks. While `aHash` has both very strong scrambling and very high performance.
104+
105+
AHash performs well when dealing with large inputs because aHash reads 8 or 16 bytes at a time. (depending on availability of AES-NI)
106+
107+
Because of this, and its optimized logic, `aHash` is able to outperform `FxHash` with strings.
108+
It also provides especially good performance dealing with unaligned input.
109+
(Notice the big performance gaps between 3 vs 4, 7 vs 8 and 15 vs 16 in `FxHash` above)
110+
111+
### Which CPUs can use the hardware acceleration
112+
113+
Hardware AES instructions are built into Intel processors built after 2010 and AMD processors after 2012.
114+
It is also available on [many other CPUs](https://en.wikipedia.org/wiki/AES_instruction_set) should in eventually
115+
be able to get aHash to work. However, only X86 and X86-64 are the only supported architectures at the moment, as currently
116+
they are the only architectures for which Rust provides an intrinsic.
117+
118+
aHash also uses `sse2` and `sse3` instructions. X86 processors that have `aesni` also have these instruction sets.

0 commit comments

Comments
 (0)