From a733f9a4a40d77e5a21edccaffc0228499806350 Mon Sep 17 00:00:00 2001 From: Stefan Sperling Date: Mon, 8 Feb 2021 11:20:05 +0000 Subject: 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@ --- sys/dev/softraidvar.h | 23 ++++++++++++++++++++++- 1 file changed, 22 insertions(+), 1 deletion(-) (limited to 'sys/dev/softraidvar.h') 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 * Copyright (c) 2008 Chris Kuethe @@ -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 *, -- cgit v1.2.3