* Add cgroup package

* Refactor procGgroup

* Add testdata generation

* Add v1 testdata generation

* Move scripts around

* Add integration test in CI

* Remove cgroup v1

* Move to cgroup struct

* Remove half-core test as it's redundant

This prevents panics on 256-core systems, and has a 300-core system use
255 CPUs (the max) rather than 44 CPUs (300 casted to a uint8).

Signed-off-by: Joe Richey <joerichey@google.com>
[ebiggers: also set TruncationFixed at the end of getHashingCosts()]
Signed-off-by: Eric Biggers <ebiggers@google.com>

github.com/golang/protobuf/proto has been deprecated in favor of
google.golang.org/protobuf/proto, so migrate to the non-deprecated one.

Running `crypto.PassphraseHash` in a loop allocates a lot of memory.
Golang is not always prudent about collecting the garbage from previous
runs, resulting in a OOM error on memory-pressured systems.

With a `maxMemoryBytes` of 128 MiB, this change reduces the maximum
resident memory for `fscrypt setup` to 141 MiB (was perviously 405 MiB)

Signed-off-by: Joe Richey <joerichey@google.com>

On systems with high memory pressure, using half of the entire RAM for
hashing can result in fscrypt getting OOM killed.

Signed-off-by: Joe Richey <joerichey@google.com>

ErrBadConfig:
	Fix backwards wrapping, include the bad config, and make it
	clear that this is an internal error.

ErrBadConfigFile:
	Fix backwards wrapping, include the config file location, and
	adjust the suggestion slightly.

ErrConfigFileExists:
	Include the config file location.

ErrNoConfigFile:
	Include the config file location, and adjust the suggestion
	slightly.

v2 encryption policies are now recommended, due to various security and
usability advantages over v1 policies.  Many people have been running
into the usability problems with v1, so it's desirable to get people
onto v2 without having to manually opt-in.

Therefore, when 'fscrypt setup' creates /etc/fscrypt.conf, enable
policy_version 2 automatically if the kernel supports it.

I decided to go with this solution over the policy_version "auto" I
suggested originally because this way is simpler, it can still be
changed to "auto" later if desired, and "auto" might require changing
how we parse the config file (since currently the config file is mapped
directly to a protobuf where policy_version is an 'int' and is shared
with EncryptionOptions).

Resolves https://github.com/google/fscrypt/issues/182

There's no real need to allow users to choose the key description prefix
(a.k.a. the "service"), since on ext4 and f2fs we can just use "ext4"
and "f2fs" for compatibility with all kernels both old and new, and on
other filesystems we can just use "fscrypt".  So, let's do that.

Since this removes the point of the "--legacy" option to 'fscrypt setup'
and the "compatibility" field in /etc/fscrypt.conf, remove those too.

Specifically, we start ignoring the "compatibility" in existing config
files and not writing it to new ones.  The corresponding protobuf field
number and name are reserved.  We stop accepting the "--legacy" option
at all, although since it was default true and there was no real reason
for anyone to change it to false, probably no one will notice.  If
anyone does, they should just stop specifying the option.

Note that this change only affects user keyrings and thus only affects
v1 encryption policies, which are deprecated in favor of v2 anyway.

Linux v5.4 and later supports v2 encryption policies.  These have
several advantages over v1 encryption policies:

- Their encryption keys can be added/removed to/from the filesystem by
  non-root users, thus gaining the benefits of the filesystem keyring
  while also retaining support for non-root use.

- They use a more standard, secure, and flexible key derivation
  function.  Because of this, some future kernel-level fscrypt features
  will be implemented for v2 policies only.

- They prevent a denial-of-service attack where a user could associate
  the wrong key with another user's encrypted files.

Prepare the fscrypt tool to support v2 encryption policies by:

- Adding a policy_version field to the EncryptionOptions, i.e. to the
  config file and to the policy metadata files.

- Using the kernel-specified algorithm to compute the key descriptor for
  v2 policies.

- Handling setting and getting v2 policies.

Actually adding/removing the keys for v2 policies to/from the kernel is
left for the next patch.

If the user has set a restrictive umask, e.g. 0077, then
/etc/fscrypt.conf would be created without the world-readable bit set.
Fix it by overriding the umask when creating the file.

Resolves https://github.com/google/fscrypt/issues/151