Re: 回复: 回复: 回复: 回复: Softraid crypto metadata backup
Nathan Carruth writes: > permanently and irrevocably destroy all data on your entire disk”. This is a feature. More so, it's the very point in an encrypted filesystem. If you haven't planned for this failure scenario then what are you doing using a device which *by design* can irrevocably trash its contents in an instant? Matthew
回复: 回复: 回复: 回复: Softraid crypto metadata backup
None of those issues are of the form “a hundred bad bytes will permanently and irrevocably destroy all data on your entire disk”. Unless I am mistaken, crypto header corruption is. On Jan 05 22:22:44, n.carr...@alum.utoronto.ca wrote: > Given that one of the goals of the OpenBSD project is to produce > reliable documentation, I would have expected that this kind of potential > corruption would have been at least mentioned > somewhere. Surely we don’t expect every user to read the code for > all the software they use to be sure there are no well-known but > undocumented data holes? If a ffs's superblocks get corrupted, the fs will be unusable. If a file's inode gets corrupted, the file will bu unusable. Should this be mentioned in the respective manpages? Also, libc.so corruption will break all dynamicaly linked binaries. And if /bsd gets corrupted, the system will be unbootable. Are these undocumented data holes? Are you distressed to find so potentially huge an issue completely undocumented? Jan > Even just a line like this would be useful: > > “Note: bioctl(8) writes header information (such as salt values for > crypto volumes) at the start of the original partition. See [relevant source > file] for details. If this information should become corrupted, the > softraid(4) > volume will become unusable.” > > Thanks! > Nathan > > PS I have been using OpenBSD since 2010. I like it very much in many > ways, but I am distressed to find so potentially huge an issue completely > undocumented. > >
Re: 回复: 回复: 回复: Softraid crypto metadata backup
On Jan 05 22:22:44, n.carr...@alum.utoronto.ca wrote: > Given that one of the goals of the OpenBSD project is to produce > reliable documentation, I would have expected that this kind of potential > corruption would have been at least mentioned > somewhere. Surely we don’t expect every user to read the code for > all the software they use to be sure there are no well-known but > undocumented data holes? If a ffs's superblocks get corrupted, the fs will be unusable. If a file's inode gets corrupted, the file will bu unusable. Should this be mentioned in the respective manpages? Also, libc.so corruption will break all dynamicaly linked binaries. And if /bsd gets corrupted, the system will be unbootable. Are these undocumented data holes? Are you distressed to find so potentially huge an issue completely undocumented? Jan > Even just a line like this would be useful: > > “Note: bioctl(8) writes header information (such as salt values for > crypto volumes) at the start of the original partition. See [relevant source > file] for details. If this information should become corrupted, the > softraid(4) > volume will become unusable.” > > Thanks! > Nathan > > PS I have been using OpenBSD since 2010. I like it very much in many > ways, but I am distressed to find so potentially huge an issue completely > undocumented. > >
回复: 回复: 回复: Softraid crypto metadata backup
> On 2023-01-05, Nathan Carruth wrote: >> Thank you for your response. >> >> To clarify: I am not asking about backups proper >> (though I appreciate the suggestions). My only >> question is how to make a copy of the crypto metadata. > >dd the start of the partition, it's stored 16 blocks (8k) into the partition >and for the current version of softraid it's 64 blocks (32k) long. > >But it's useless without the data so unless you are doing unsupported things >like poking at the softraid partition size, etc, and want to make a backup >before doing that then I don't see how it helps you. (And if you *are* doing >that then I'd hope you don't have to ask how to back it up first). > >And unless you detach the softraid device first (or don't attach in the first >place) it will be marked dirty. Thank you, this is exactly what I was looking for. For the record: I want a way to save the metadata for restoration in case of accidental corruption. Security concerns aside, I don’t see why this is any different from backing up partition and disklabel information as Nick suggested. I understand both GELI and cgd provide standard and documented ways of doing this. When I first learned about header corruption in LUKS I was relieved that it wasn’t an issue in OpenBSD. Then a year later I suddenly learned otherwise — from a non-OpenBSD source. Given that one of the goals of the OpenBSD project is to produce reliable documentation, I would have expected that this kind of potential corruption would have been at least mentioned somewhere. Surely we don’t expect every user to read the code for all the software they use to be sure there are no well-known but undocumented data holes? Even just a line like this would be useful: “Note: bioctl(8) writes header information (such as salt values for crypto volumes) at the start of the original partition. See [relevant source file] for details. If this information should become corrupted, the softraid(4) volume will become unusable.” Thanks! Nathan PS I have been using OpenBSD since 2010. I like it very much in many ways, but I am distressed to find so potentially huge an issue completely undocumented.
Re: 回复: 回复: Softraid crypto metadata backup
On 2023-01-05, Nathan Carruth wrote: > Thank you for your response. > > To clarify: I am not asking about backups proper > (though I appreciate the suggestions). My only > question is how to make a copy of the crypto metadata. dd the start of the partition, it's stored 16 blocks (8k) into the partition and for the current version of softraid it's 64 blocks (32k) long. But it's useless without the data so unless you are doing unsupported things like poking at the softraid partition size, etc, and want to make a backup before doing that then I don't see how it helps you. (And if you *are* doing that then I'd hope you don't have to ask how to back it up first). And unless you detach the softraid device first (or don't attach in the first place) it will be marked dirty.
回复: 回复: Softraid crypto metadata backup
Thank you for your response. To clarify: I am not asking about backups proper (though I appreciate the suggestions). My only question is how to make a copy of the crypto metadata. On 2023-01-03, Nathan Carruth wrote: > I am with you 100% on backups. My real question was, How > does one backup crypto volume metadata? Given that > it can be backed up, clearly it should be, but there is no > information in any of the cited documentation as to where > the metadata is or how to back it up. There doesn't seem to be much point in backing up *just* the metadata, how will that help you get data back? I think your options to backup the encrypted data are: - backup from the mounted filesystem using some backup tool that has a way to encrypt. There's a wide choice of backup software, including borg and restic, that do this in a nice way, that will also allow cross-OS restores if needed, restoring individual files, etc. You can also use e.g. dump or tar, piping the output through an encryption tool before storing. - backup the whole disk partition/s e.g. with dd. This might be a bit impractical as to keep things consistent I think you'll want to unmount, detach the softraid device, backup, reattach, remount. Restoration is much more fiddly too. Additionally this isn't designed as an archival format; it would seem that it will be much more fragile.
回复: 回复: Softraid crypto metadata backup
Thank you for your response. Perhaps I should have clarified my use case. I have data which is potentially legally privileged and which I also cannot afford to lose. Thus an unencrypted backup is out of the question, and my first thought was to use full-disk encryption for the backup. Perhaps header is the correct term rather than metadata. Both LUKS (see, e.g., https://gitlab.com/cryptsetup/cryptsetup/-/wikis/LUKS-standard/on-disk-format.pdf, p. 2) as well as FreeBSD’s GELI (see the man page, e.g. https://www.freebsd.org/cgi/man.cgi?query=geli=0=0=FreeBSD+13.1-RELEASE+and+Ports=default=html) use on-disk metadata (for LUKS, I understand this includes e.g. salt values, I presume it is similar for GELI), and both systems provide explicit methods for backing up this metadata. I presume that OpenBSD also writes on-disk metadata of the same sort somewhere. Where? I know I could dig this out of the source code but I don’t have time right now. As it stands, the documentation gives no hint that softraid crypto gives any additional risk of data loss. If there are in fact e.g. salt values written in an unknown location on the disk, whose loss renders THE ENTIRE DISK cryptographically inaccessible, surely this ought to be documented somewhere? I understand that there are use cases where it would be better for the data to be lost entirely than to be disclosed to the wrong people. But this is not true in every use case. While I agree with you that there are definite security risks in backing up such metadata, surely the decision as to what to do ought to be left to the end user, rather than being enforced by lack of documentation? Thanks! Nathan On 1/2/23 23:54, Nathan Carruth wrote: > Thank you for the response. > > I am with you 100% on backups. My real question was, How > does one backup crypto volume metadata? Given that > it can be backed up, clearly it should be, but there is no > information in any of the cited documentation as to where > the metadata is or how to back it up. There appears to be no intended way to backup this crypto metadata you are worried about. Not that I'd really want extra copies of anything related to a crypto disk floating around anywhere if I could help it. Not sure what you are hoping to get "backed up", but it sure sounds like something useful to the wrong people. Encrypted disks are supposed to "fail closed". If that scares you, your backup sucks or you shouldn't be running encrypted drives. (well...you COULD # dd bs=1m if=/dev/rsd0c of=/mnt/someotherdevice/disk.img and that would get your meta data, your data, your microdata your macrodata and possibly your first born). So let me offer you this, instead. A backup of potentially someday useful disk data: for DISK in $(sysctl -n hw.disknames|tr ',' ' '); do D=$(echo $DISK| cut -f1 -d:) print print "== $DISK ===" fdisk $D disklabel $D done (note: this script is surely missing edge and special cases. It has been run on three different machines. I do not wish to talk about how much time I've spent making it look prettier. I guarantee it is worth about what you paid for it and nothing more). Run that periodically, redirect the output to a file, get that file to another place, and you have full info about your disk partitions, both fdisk and disklabel, in case you overwrite them someday. Far more likely than a crypto failure that can be recovered by some crypto metadata backup. And the cool thing since the prefix "meta" basically boils down to "sounds cool, no idea what it means", we can call this metadata. :) (Yes, the disklabel info is stored by security(8), ... kinda. Spot checking two of my systems right now, I see both are missing drives...and I'm not sure why, I suspect there's a good reason. But fdisk output is NOT there, and I'd rather prefer it be there too on fdisk platforms). Nick. > > Thanks! > Nathan > >> Does a softraid(4) crypto volume require metadata backup? (I am >> running amd64 OpenBSD 6.9 if it is relevant, will probably >> upgrade in the next few months.) >> >> I understand FreeBSD GELI (e.g.) requires such a backup to protect >> against crypto-related metadata corruption rendering the encrypted >> volume inaccessible. >> >> Neither the OpenBSD disk FAQ nor the man pages for softraid(4) or >> bioctl(8) have anything to say about the matter. Web searches also >> turn up no relevant information. > > Storage requires backup. > Encrypted storage is (by design) more fragile than unencrypted storage. > Sounds like you are trying to protect against ONE form of storage > failure and avoid the solution you really need to have: a good backup > system, to deal with *all* forms of storage failure. > > I'd suggest a good backup system...to deal with ALL forms of data loss. > Yes, encrypted storage implies a certain care has to be taken with the > backups as well, you need to pick a solution that is appropriate for > your needs -- or accept that yeah, stuff will go
