回复: a couple question about my fde setup
发件人: owner-m...@openbsd.org 代表 Shadrock Uhuru 发送时间: 2023年11月28日 09:23 收件人: openbsd 主题: Re: a couple question about my fde setup >>From: Nick Holland >>To: misc@openbsd.org >>Date: Mon, 20 Nov 2023 07:47:40 -0500 >>Subject: Re: a couple question about my fde setup >>On 11/19/23 18:09, Shadrock Uhuru wrote: >>> hi all >>> a couple question about my fde >>> first, i have fde setup using a keydisk on my laptop, encryption and >>> decryption works fine >>> when i reboot with the key inserted it doesn't find the key, >>> i have to shut the machine down and restart it then the key is detected, >>> is this normally how a reboot works with fde and keydisk ? >> >i've noticed a few things during the booting with and without the keydisk. > >without keydisk with keyfisk > >disk hd0 cd0 sr0* disk hd0 hd1 sr0* >>> openbsd/amd64 BootX64 3.63 >> openbsd/amd64 Bootx64 3.62 >failed (1) will try bsd failed (22) will try bsd > >also i have no idea why i have hd devices showing up at boot time >and i have sd devices in dmesg. > >shadrock I’m no expert, but it looks to me like your computer is booting from your key disk (why: different errors, different EFI versions between booting with and without key disk). Does your key disk have an EFI boot partition for some reason? Can you make sure your computer is set to not boot from USB? Re hd in boot menu, sd in dmesg: as far as I know, this is just due to different naming conventions in the boot loader and the kernel. ‘sr’ in the boot loader is your softraid encrypted disk. Nathan
Re: Softraid crypto metadata backup
>On Sat, Jan 07, 2023 at 02:33:31PM +0000, Nathan Carruth wrote: >>The way I see it, this depends on one's use case. >>There certainly are cases where it is important to be able >>to irrevocably destroy all data in an instant. But there are >>also use cases where one is only interested in making sure >>that the average person couldn’t access one’s data if one lost >>one’s laptop/external drive. >> >>I still think that anyone with the second use case could benefit >>from more documentation as I suggested, but I get the feeling >>this opinion is in the distinct minority here. > >If you're part of that supposed minority: count me in. If it's true >that the headers of encrypted disks on Openbsd are set up in a similar >way as on e.g. Linux, then it's actually a good idea to be able to >have precise knowledge about how to backup that header on OBSD. > From what I learned the preparation for that failure includes first a >copy of the data on that encrypted disk to a second or - even better - >a third encrypted one. > >But copying back a whole disk because on the original broken one it's >just the header that went south might be an effort that is a least >avoidable. And this when part two of disaster preparation might be >helpful: the so-called header backup. > >I don't know how often, and if, such header corruptions on encrypted >disks happen on OBSD, but on LUKS/cryptsetup encrypted disks on >Linux this does not seem to be that unusual - from the LUKS FAQ: > >"By far the most questions on the cryptsetup mailing list are from > people that managed to damage the start of their LUKS partitions, > i.e. the LUKS header. In most cases, there is nothing that can be done > to help these poor souls recover their data. Make sure you understand > the problem and limitations imposed by the LUKS security model BEFORE > you face such a disaster! In particular, make sure you have a current > header backup before doing any potentially dangerous operations." > >https://gitlab.com/cryptsetup/cryptsetup/-/blob/main/FAQ.md > >And so, that no one is getting me wrong: I don't expect anyone to >create the documentation for me. Definitively not. But if disk header >corruption can be a problem on Openbsd, too, then this very >possibility helps at least to understand the point the OP was trying >to make when starting this thread. > >Regards, >Wolfgang I wasn't going to say anything more, but after reading this I figured I ought to at least suggest an update to the documentation. Since I'm definitely not qualified to document the details, all I can really do is something like what is posted below (these should be diffs to the current versions of src/share/man/man4/softraid.4 and www/faq/faq14.html on CVS). Thanks, Nathan For softraid.4: @@ -270,0 +271,4 @@ +.Pp +The CRYPTO discipline emphasizes confidentiality over integrity. +In particular, corruption of the on-disk metadata will render all encrypted +data permanently inaccessible. For faq14.html: @@ -835,0 +836,9 @@ +Note + +Decryption requires the use of on-disk metadata documented in the +https://cvsweb.openbsd.org/src/sys/dev/softraidvar.h;>source. +Corruption of this metadata can easily render all encrypted data +permanently inaccessible. +There is at present no automated way to backup this metadata. +
Softraid crypto metadata backup
The way I see it, this depends on one's use case. There certainly are cases where it is important to be able to irrevocably destroy all data in an instant. But there are also use cases where one is only interested in making sure that the average person couldn’t access one’s data if one lost one’s laptop/external drive. I still think that anyone with the second use case could benefit from more documentation as I suggested, but I get the feeling this opinion is in the distinct minority here. So — thanks to everyone for the answers, I’m signing off this question now. Take care and stay secure, Nathan >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. > >
回复: 回复: 回复: 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.
回复: Softraid crypto metadata backup
Thank you for your response (apologies that I just saw this). I will have a look at the file you mentioned. I am curious what you mean by this: “ Backing up, restoring or otherwise messing with the softraid metadata without using the standard tools is an advanced subject” as far as I know there aren’t any standard tools for doing any of this? If there is, it is probably all I need. On Thu, Jan 05, 2023 at 05:13:05AM +, Nathan Carruth wrote: > I presume that OpenBSD also writes on-disk metadata of the > same sort somewhere. Where? Look at /usr/src/sys/dev/softraidvar.h. The structures that contain the softraid metadata are defined there. There is general softraid metadata, and crypto specific metadata. These are stored near the beginning of the RAID partition as defined in the disklabel. In fact, they are SR_META_OFFSET blocks from the start, which is currently 8192 bytes. You can also look at this on your own disk with dd and hexdump to familiarise yourself with what the layout looks like, (useful for future reference). Or read my article about resizing softraid volumes for some examples. > I know I could dig this out of > the source code The source code is the definitive reference. And it can change. > As it stands, the documentation gives no hint that softraid > crypto gives any additional risk of data loss. Just about any additional layer on top of a storage volume increases the complexity of the system, which some people might regard as 'additional risk'. This is in no way specific to softraid crypto. > If there are in > fact e.g. salt values written in an unknown location on the > disk It's not unknown, it's documented quite clearly in the source code. > whose loss renders THE ENTIRE DISK cryptographically > inaccessible, surely this ought to be documented somewhere? By definition, losing the salt value used with any effective crypto system _should_ make it inaccessible! This is even considered a feature, because you can effectively erase the disk just by destroying the metadata. > 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? The source code is the definitive documentation. Backing up, restoring or otherwise messing with the softraid metadata without using the standard tools is an advanced subject, so it's quite reasonable to expect anybody wanting to do this to read and understand the source rather than having it spelt out in a manual page or other documentation. If it was documented elsewhere, that documentation would have to be kept up to date with the current source, otherwise it could end up causing more problems than it solves. In any case, what you are proposing to do, (back up the softraid crypto metadata), is almost certainly a waste of time, as it is extremely unlikely that you will ever be in a situation where such a backup would be useful. Additionally, if you _do_ decide to go ahead with this, then in the very unlikely event that you corrupt the metadata on the main disk and want to restore it from a backup, please do your research _before_ trying to restore it. It would be very easy to corrupt the disk further by dd'ing the wrong data to the wrong place. There have been a lot of posts to the mailing lists in the past by people who have tried to fix disk partitioning problems by themselves and made the situation worse. What you are proposing sounds to me like a foot gun.
回复: 回复: 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 stora
回复: Softraid crypto metadata backup
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. 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 bye-bye someday. I don't see a benefit to trying to protect against some single failure mode when all the other failure modes still exist. If you have good backups, you are good. If you don't, dealing with a 1% problem isn't going to change much. Nick.
Softraid crypto metadata backup
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. Thanks, Nathan Carruth
