Add a RAID1C (raid1 + crypto) softraid(8) discipline.

The RAID1C discipline encrypts data like the CRYPTO discipline, and accepts
multiple chunks during creation and assembly like the RAID1 discipline.

To deal with failing disks a RAID1C volume may be assembled with a smaller
number of chunks than the volume was created with. The volume will then come
up in degraded state. If the volume is now detached and assembled again with
the correct number of chunks, any re-added chunks will require a rebuild.

Consequently, assembling RAID1C volumes requires careful attention to the
chunks passed via 'bioctl -l'.  If a chunk is accidentally omitted from the
command line during volume assembly, then this chunk will need to be rebuilt.

At least one known-good chunk is required in order to assemble the volume.

Like CRYPTO, RAID1C supports passphrase and key-disk authentication.
Key-disk based volumes are assembled automatically if the key disk is present
while the system is booting up.

Unlike CRYPTO and RAID1, there is no boot support for RAID1C yet.

RAID1C largely reuses existing code of RAID1 and CRYPTO disciplines.
At present RAID1C's discipline-specific data structure is shared with that
of the CRYPTO discipline to allow re-use of existing CRYPTO code. A custom
RAID1C data structure would require CRYPTO code to access struct sr_crypto
via a pointer instead of via a member field of struct sr_discipline.

ok jsing@

1 files changed, 22 insertions, 1 deletions

diff --git a/sys/dev/softraidvar.h b/sys/dev/softraidvar.h
index 54909577ab7..e66adcc2b0c 100644
--- a/sys/dev/softraidvar.h
+++ b/sys/dev/softraidvar.h
@@ -1,4 +1,4 @@
-/* $OpenBSD: softraidvar.h,v 1.171 2020/07/22 13:16:04 krw Exp $ */
+/* $OpenBSD: softraidvar.h,v 1.172 2021/02/08 11:20:04 stsp Exp $ */
 /*
  * Copyright (c) 2006 Marco Peereboom <marco@peereboom.us>
  * Copyright (c) 2008 Chris Kuethe <ckuethe@openbsd.org>
@@ -444,6 +444,19 @@ struct sr_raid6 {
 TAILQ_HEAD(sr_crypto_wu_head, sr_crypto_wu);
 #define SR_CRYPTO_NOWU		16
 
+/*
+ * The per-I/O data that we need to preallocate. We cannot afford to allow I/O
+ * to start failing when memory pressure kicks in. We can store this in the WU
+ * because we assert that only one ccb per WU will ever be active during crypto.
+ */
+struct sr_crypto_wu {
+	struct sr_workunit		 cr_wu;		/* Must be first. */
+	struct uio			 cr_uio;
+	struct iovec			 cr_iov;
+	struct cryptop	 		*cr_crp;
+	void				*cr_dmabuf;
+};
+
 struct sr_crypto {
 	struct sr_meta_crypto	*scr_meta;
 	struct sr_chunk		*key_disk;
@@ -455,12 +468,18 @@ struct sr_crypto {
 	u_int8_t		scr_key[SR_CRYPTO_MAXKEYS][SR_CRYPTO_KEYBYTES];
 	u_int8_t		scr_maskkey[SR_CRYPTO_MAXKEYBYTES];
 	u_int64_t		scr_sid[SR_CRYPTO_MAXKEYS];
+
+	struct sr_raid1		scr_raid1; /* for RAID1C */
 };
 
 #define SR_CONCAT_NOWU		16
 struct sr_concat {
 };
 
+/* RAID 1C */
+#define SR_RAID1C_NOWU		16
+/* Uses sr_crypto */
+
 struct sr_chunk {
 	struct sr_meta_chunk	src_meta;	/* chunk meta data */
 
@@ -505,6 +524,7 @@ struct sr_discipline {
 	/* SR_MD_RAID4 was 7. */
 #define	SR_MD_RAID6		8
 #define	SR_MD_CONCAT		9
+#define	SR_MD_RAID1C		10
 	char			sd_name[10];	/* human readable dis name */
 	u_int16_t		sd_target;	/* scsibus target discipline uses */
 
@@ -707,6 +727,7 @@ void			sr_raid5_discipline_init(struct sr_discipline *);
 void			sr_raid6_discipline_init(struct sr_discipline *);
 void			sr_crypto_discipline_init(struct sr_discipline *);
 void			sr_concat_discipline_init(struct sr_discipline *);
+void			sr_raid1c_discipline_init(struct sr_discipline *);
 
 /* Crypto discipline hooks. */
 int			sr_crypto_get_kdf(struct bioc_createraid *,