Multipath Statistics

Multipath Statistics

[Lan]

Hi all,

Thought it would be a good time to bring up a discussion on the type
of statistics that dm-multipath would find useful, e.g. for a load
balancing path selection algorithm or for users. This is a list of
statistics provided by an IBM multipathing product. (The discussion of
how to gather these type of statistics would also require another
discussion). Any thoughts/suggestions?

Per Path Information:	 
- Number of times the path was selected for I/O
- Number of I/O errors on this path
	
Per Adapter Information	:
- The number of times this adapter was selected for I/O
- The number of errors on all paths attached to this adapter
- The number of paths attached to this adapter
- The number of functional paths attached to this adapter (i.e.
Exclude failed or offline paths)
   
Path Performance Information (more specific breakdown):  	
Total Read I/O:	Total number of completed read requests
Total Read Sector:	Total number of sectors that have been read
Total Write I/O:	Total number of completed write requests
Total Write Sector:	Total number of sectors that have been written
Active Read I/O:	Total number of read requests in process
Active Read Sector:	Total number of sectors to read in process
Active Write I/O:	Total number of write requests in process
Active Write Sector:	Total number of sectors to write in process
Maximum I/O:	The maximum number of active I/O requests
Maximum Sector:	The maximum number of active sectors to read or write
Transfer Size:	
<= X , (X = {512, 4K, 16K, 64K})	The number of I/O requests received
whose transfer size is X bytes or less
> 64K 	The number of I/O requests received whose transfer size is greater than 64KB
	
Adapter Performance Information:
** identical to Path performance information except no "Transfer Size'" info


Thanks!
Lan

dm-crypt userland key patch

[Bjorn Andersson]

[-- Attachment #1: Type: text/plain, Size: 280 bytes --]

Hello

Patch to the dm-crypt module so that it hides the crypto-key from
userland. (dmsetup table)

Adds an extra option (DM_CRYPT_NULLKEYSTATUS) to
config/menuconfig/whateverconfig, under dm-crypt, so you can toggle the
patch.


Code by Bjorn Andersson and Erik Ekman.

// Bjorn

[-- Attachment #2: dm-crypt-nullkey.patch --]
[-- Type: text/x-patch, Size: 1710 bytes --]

diff -ur linux-2.6.11-gentoo-r4/drivers/md/Kconfig linux-2.6.11-gentoo-r4-mod/drivers/md/Kconfig
--- linux-2.6.11-gentoo-r4/drivers/md/Kconfig	2005-03-18 14:44:33.000000000 +0100
+++ linux-2.6.11-gentoo-r4-mod/drivers/md/Kconfig	2005-04-12 15:46:03.000000000 +0200
@@ -207,6 +207,18 @@
 
 	  If unsure, say N.
 
+config DM_CRYPT_NULLKEYSTATUS
+	bool "Hide key from userspace"
+	depends on DM_CRYPT
+	---help---
+	  When executing 'dmsetup table' it prints the crypto-key for all 
+	  mounted dm-crypt-devices. See dmsetup(8).
+
+	  This hides the real key and returns a key of zeros instead.
+
+	  If paranoid or unsure, say Y.
+	  If you need to see your keys in runtime, say N.
+
 config DM_SNAPSHOT
        tristate "Snapshot target (EXPERIMENTAL)"
        depends on BLK_DEV_DM && EXPERIMENTAL
diff -ur linux-2.6.11-gentoo-r4/drivers/md/dm-crypt.c linux-2.6.11-gentoo-r4-mod/drivers/md/dm-crypt.c
--- linux-2.6.11-gentoo-r4/drivers/md/dm-crypt.c	2005-04-12 12:51:28.000000000 +0200
+++ linux-2.6.11-gentoo-r4-mod/drivers/md/dm-crypt.c	2005-04-12 15:36:35.000000000 +0200
@@ -518,6 +518,7 @@
 /*
  * Encode key into its hex representation
  */
+#ifndef CONFIG_DM_CRYPT_NULLKEYSTATUS
 static void crypt_encode_key(char *hex, u8 *key, unsigned int size)
 {
 	unsigned int i;
@@ -528,6 +529,7 @@
 		key++;
 	}
 }
+#endif
 
 /*
  * Construct an encryption mapping:
@@ -900,8 +902,11 @@
 		if (cc->key_size > 0) {
 			if ((maxlen - sz) < ((cc->key_size << 1) + 1))
 				return -ENOMEM;
-
+#ifdef CONFIG_DM_CRYPT_NULLKEYSTATUS
+			memset(result + sz, '0', cc->key_size << 1);	
+#else
 			crypt_encode_key(result + sz, cc->key, cc->key_size);
+#endif
 			sz += cc->key_size << 1;
 		} else {
 			if (sz >= maxlen)

[-- Attachment #3: Type: text/plain, Size: 0 bytes --]

Re: dm-crypt userland key patch

[Molle Bestefich]

Bjorn Andersson wrote:
> Patch to the dm-crypt module so that it hides the crypto-key from
> userland. (dmsetup table)

Does it also overwrite the key in memory when unloading dm-crypt, make
sure that the memory is pinned so the key doesn't leak to swap, unload
the key before a 'hibernate', and that sort of stuff?

Re: dm-crypt userland key patch

[Bjorn Andersson]

> Bjorn Andersson wrote:
> > Patch to the dm-crypt module so that it hides the crypto-key from
> > userland. (dmsetup table)
> 
> Does it also overwrite the key in memory when unloading dm-crypt, make
> sure that the memory is pinned so the key doesn't leak to swap, unload
> the key before a 'hibernate', and that sort of stuff?
> 
> --
> dm-devel mailing list
> dm-devel@redhat.com
> https://www.redhat.com/mailman/listinfo/dm-devel

No, this does only report a key of zeros when the status is requested.

The unloading thing is no problem to fix, but how should the
'hibernate' thing work? When you resume after a 'hibernate' you probably
expect that the device is there, especially if it's on the root
partition. But I clearly see your point.

// Bjorn

Re: dm-crypt userland key patch

[Molle Bestefich]

Bjorn Andersson wrote:
> > > Patch to the dm-crypt module so that it hides the crypto-key from
> > > userland. (dmsetup table)
> >
> > Does it also overwrite the key in memory when unloading dm-crypt, make
> > sure that the memory is pinned so the key doesn't leak to swap, unload
> > the key before a 'hibernate', and that sort of stuff?
>
> No, this does only report a key of zeros when the status is requested.
> 
> The unloading thing is no problem to fix, but how should the
> 'hibernate' thing work? When you resume after a 'hibernate' you probably
> expect that the device is there, especially if it's on the root
> partition. But I clearly see your point.

*Scratches head*, I'd expect the default to be "doing the safe thing",
eg. picking up on hibernation and nuking the key (disabling any crypto
devices).  If there's a lean no-hassles user interface to get the
password entered and the devices up again when the machine is resumed,
I'd imagine most users to be happy about it, especially when they're
told that it's done to protect their encrypted data?

There might be a few people annoyed by it?  Or there might even be
some obscure technical reason why you'd want your keys to survive
hibernation..  For those cases there could be an option to disable
"hibernation protection" or what not.

Dunno, IANA expert :-o.