Age | Commit message (Collapse) | Author |
|
Should help debugging https://github.com/rfjakob/gocryptfs/issues/363
|
|
master key.
Further raises the bar for recovering keys from memory.
|
|
Mostly detected with the 'codespell' utility, but also includes some
manual grammar fixes.
|
|
File holes and -fsck can cause unaligned read accesses, which means
we have to decrypt one extra plaintext block.
xfstests generic/083 manage to crash -fsck like this:
generic/083 2018/07/14 15:25:21 wrong len=266240, want=131072
panic: wrong len=266240, want=131072
goroutine 1 [running]:
log.Panicf(0x67fc00, 0x15, 0xc4204fec90, 0x2, 0x2)
/usr/local/go/src/log/log.go:333 +0xda
github.com/rfjakob/gocryptfs/internal/contentenc.(*bPool).Put(0xc4200d4800, 0xc4202f2000, 0x21000, 0x41000)
/home/jakob/go/src/github.com/rfjakob/gocryptfs/internal/contentenc/bpool.go:27 +0x15d
github.com/rfjakob/gocryptfs/internal/fusefrontend.(*File).doRead(0xc4200b4500, 0xc42019e000, 0x0, 0x20000, 0x28400, 0x20000, 0xc42019e000, 0xc4204ff008, 0x435164, 0xc420000180)
/home/jakob/go/src/github.com/rfjakob/gocryptfs/internal/fusefrontend/file.go:227 +0xba9
github.com/rfjakob/gocryptfs/internal/fusefrontend.(*File).Read(0xc4200b4500, 0xc42019e000, 0x20000, 0x20000, 0x28400, 0x0, 0x0, 0x0)
/home/jakob/go/src/github.com/rfjakob/gocryptfs/internal/fusefrontend/file.go:246 +0x23e
main.(*fsckObj).file(0xc420069320, 0xc42001a630, 0x21)
/home/jakob/go/src/github.com/rfjakob/gocryptfs/fsck.go:126 +0x21f
main.(*fsckObj).dir(0xc420069320, 0xc420014dc0, 0x1d)
/home/jakob/go/src/github.com/rfjakob/gocryptfs/fsck.go:76 +0x387
main.(*fsckObj).dir(0xc420069320, 0xc42021dae0, 0x19)
/home/jakob/go/src/github.com/rfjakob/gocryptfs/fsck.go:74 +0x347
|
|
Make sure we get only 1 warning output per
problem.
Also, add new corruption types to broken_fs_v1.4.
|
|
At the moment, only for reverse mode.
https://github.com/rfjakob/gocryptfs/issues/217
|
|
...to account for unaligned reads.
I have not seen this happen in the wild because the kernel
always seems to issue 4k-aligned requests. But the cost
of the additional block in the pool is low and prevents
a buffer overrun panic when an unaligned read does happen.
|
|
Our byte cache pools are sized acc. to MAX_KERNEL_WRITE, but the
running kernel may have a higher limit set. Clamp to what we can
handle.
Fixes a panic on a Synology NAS reported at
https://github.com/rfjakob/gocryptfs/issues/145
|
|
The encrypt and decrypt path both had a copy that were equivalent
but ordered differently, which was confusing.
Consolidate it in a new dedicated function.
|
|
Using firstBlockNo as the counter is confusing, create a
copy named "blockNo" and use that.
|
|
https://goreportcard.com/report/github.com/rfjakob/gocryptfs#misspell
|
|
On MacOS, building and testing without openssl is much easier.
The tests should skip tests that fail because of missing openssl
instead of aborting.
Fixes https://github.com/rfjakob/gocryptfs/issues/123
|
|
Saves 3% for the tar extract benchmark because we skip the allocation.
|
|
This gets us a massive speed boost in streaming reads.
|
|
bPool verifies the lengths of slices going in and out.
Also, add a plaintext block pool - pBlockPool - and use
it for decryption.
|
|
We use two levels of buffers:
1) 4kiB+overhead for each ciphertext block
2) 128kiB+overhead for each FUSE write (32 ciphertext blocks)
This commit adds a sync.Pool for both levels.
The memory-efficiency for small writes could be improved,
as we now always use a 128kiB buffer.
|
|
128kiB = 32 x 4kiB pages is the maximum we get from the kernel. Splitting
up smaller writes is probably not worth it.
Parallelism is limited to two for now.
|
|
This allows easy parallelization in the future.
|
|
Collect all the plaintext and pass everything to contentenc in
one call.
This will allow easier parallization of the encryption.
https://github.com/rfjakob/gocryptfs/issues/116
|
|
One out-of-date and the other with a typo.
|
|
This should never happen in normal operation and is a sign of
data corruption. Catch it early.
|
|
Log the message ourselves and return EINVAL.
Before:
gocryptfs[26962]: go-fuse: can't convert error type: ParseHeader: invalid version: got 0, want 2
After:
gocryptfs[617]: ParseHeader: invalid version: want 2, got 0. Returning EINVAL.
|
|
This can happen during normal operation, and is harmless since
14038a1644f17f50b113a05d09a2a0a3b3e973b2
"fusefrontend: readFileID: reject files that consist only of a header"
causes dormant header-only files to be rewritten on the next write.
|
|
...and fix a few golint issues and print a scary warning message on mount.
Also, force the fs to ro,noexec.
|
|
Force decode of encrypted files even if the integrity check fails, instead of
failing with an IO error. Warning messages are still printed to syslog if corrupted
files are encountered.
It can be useful to recover files from disks with bad sectors or other corrupted
media.
Closes https://github.com/rfjakob/gocryptfs/pull/102 .
|
|
If you truncate a ciphertext file to 19 bytes, you could get the
impression that the plaintext is 18446744073709551585 bytes long,
as reported by "ls -l".
Fix it by clamping the value to zero.
|
|
...but keep it disabled by default for new filesystems.
We are still missing an example filesystem and CLI arguments
to explicitely enable and disable it.
|
|
There is no security reason for doing this, but it will allow
to consolidate the code once we drop compatibility with gocryptfs v1.2
(and earlier) filesystems.
|
|
We want all panics to show up in the syslog.
|
|
Running xfstests generic/075 on tmpfs often triggered a panic
for what seems to be a tmpfs bug.
Quoting from the email to lkml,
http://www.spinics.net/lists/kernel/msg2370127.html :
tmpfs seems to be incorrectly returning 0-bytes when reading from
a file that is concurrently being truncated.
|
|
|
|
Also pull all the deterministic nonce code into fusefrontend_reverse
to greatly simplify the normal code path.
|
|
GCM-SIV is not yet finalized, and the reference implemenation is
painfully slow at about 2 MB/s. Switch to AES-SIV.
|
|
128-bit IVs are NOT used everywhere.
|
|
This will be used for strong symlink encryption in reverse mode.
|
|
|
|
Also add ReverseDummyNonce nonce generation.
|
|
|
|
|
|
Add the reverse variant of DecryptBlocks etc:
* EncryptBlocks
* JointPlaintextRange
* ExplodeCipherRange
|
|
Previously caused an integer underflow.
|
|
|
|
These are large complicated implementations that will share some
code.
|
|
The name could be misunderstood and actually caused a bug:
doWrite used to always preallocate 4128 instead of the actual
data length.
|
|
We were growing the file block-by-block which was pretty
inefficient. We now coalesce all the grows into a single
Ftruncate. Also simplifies the code!
Simplistic benchmark: Before:
$ time truncate -s 1000M foo
real 0m0.568s
After:
$ time truncate -s 1000M foo
real 0m0.205s
|
|
Let's have shorter names, and merge *_api.go into the "main"
file.
No code changes.
|
|
tlog is used heavily everywhere and deserves a shorter name.
Renamed using sed magic, without any manual rework:
find * -type f -exec sed -i 's/toggledlog/tlog/g' {} +
|
|
Go 1.4 and older do not support 128-bit IVs which caused
the tests to panic.
|
|
|
|
|