From: joeyli <jlee@suse.com> To: Stephan Mueller <smueller@chronox.de> Cc: "Lee, Chun-Yi" <joeyli.kernel@gmail.com>, "Rafael J . Wysocki" <rjw@rjwysocki.net>, Pavel Machek <pavel@ucw.cz>, linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org, keyrings@vger.kernel.org, "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>, Chen Yu <yu.c.chen@intel.com>, Oliver Neukum <oneukum@suse.com>, Ryan Chen <yu.chen.surf@gmail.com>, David Howells <dhowells@redhat.com>, Giovanni Gherdovich <ggherdovich@suse.cz>, Randy Dunlap <rdunlap@infradead.org>, Jann Horn <jannh@google.com>, Andy Lutomirski <luto@kernel.org> Subject: Re: [PATCH 1/5 v2] PM / hibernate: Create snapshot keys handler Date: Mon, 07 Jan 2019 15:33:27 +0000 [thread overview] Message-ID: <20190107153327.GB4210@linux-l9pv.suse> (raw) In-Reply-To: <4539995.kc8yiMsNgQ@tauon.chronox.de> Hi Stephan, First, thanks for your review! On Sun, Jan 06, 2019 at 09:01:27AM +0100, Stephan Mueller wrote: > Am Donnerstag, 3. Januar 2019, 15:32:23 CET schrieb Lee, Chun-Yi: > > Hi Chun, > > > This patch adds a snapshot keys handler for using the key retention > > service api to create keys for snapshot image encryption and > > authentication. > > > > This handler uses TPM trusted key as the snapshot master key, and the > > encryption key and authentication key are derived from the snapshot > > key. The user defined key can also be used as the snapshot master key > > , but user must be aware that the security of user key relies on user > > space. > > [...snip] > > +static int calc_hash(u8 *digest, const u8 *buf, unsigned int buflen, > > + bool may_sleep) > > +{ > > + struct shash_desc *desc; > > + int err; > > + > > + desc = kzalloc(sizeof(struct shash_desc) + > > + crypto_shash_descsize(hash_tfm), > > + may_sleep ? GFP_KERNEL : GFP_ATOMIC); > > Why not using SHASH_DESC_ON_STACK? > Because security concern and bad runtime performance. Please looking at c2cd0b08e1e patch for hibernation. And reference: https://lore.kernel.org/lkml/CA+55aFzCG-zNmZwX4A2FQpadafLfEzK6CC=qPXydAacU1RqZWA@mail.gmail.com/T/#u https://lwn.net/Articles/749064/ > > + if (!desc) > > + return -ENOMEM; > > + > > + desc->tfm = hash_tfm; > > + desc->flags = may_sleep ? CRYPTO_TFM_REQ_MAY_SLEEP : 0; > > + err = crypto_shash_digest(desc, buf, buflen, digest); > > + shash_desc_zero(desc); > > + kzfree(desc); > > + > > + return err; > > +} > > + > > +static int calc_key_hash(u8 *key, unsigned int key_len, const char *salt, > > + u8 *hash, bool may_sleep) > > +{ > > + unsigned int salted_buf_len; > > + u8 *salted_buf; > > + int ret; > > + > > + if (!key || !hash_tfm || !hash) > > + return -EINVAL; > > + > > + salted_buf_len = strlen(salt) + 1 + SNAPSHOT_KEY_SIZE; > > strlen on binary data? I guess that will not work. May I suggest to hand down > the length of salt to this function? > hm... The salt is actually a "salt string" that's gave from snapshot_get_auth_key() or snapshot_get_enc_key(). So I use strlen() here. I will change the name to salt_string to avoid confusion. > > + salted_buf = kzalloc(salted_buf_len, > > + may_sleep ? GFP_KERNEL : GFP_ATOMIC); > > + if (!salted_buf) > > + return -ENOMEM; > > + > > + strcpy(salted_buf, salt); > > + memcpy(salted_buf + strlen(salted_buf) + 1, key, key_len); > > + > > + ret = calc_hash(hash, salted_buf, salted_buf_len, may_sleep); > > + memzero_explicit(salted_buf, salted_buf_len); > > + kzfree(salted_buf); > > + > > + return ret; > > +} > > This function looks very much like a key derivation. May I strongly propose to Actually key derivation function is modified from the get_derived_key() from the encrypted.c file in encrypted key. > use an official KDF type like SP800-108 or HKDF? > > You find the counter-KDF according to SP800-108 in security/keys/dh.c (search > for functions *kdf*). > > Or we may start pulling in KDF support into the kernel crypto API via the > patches along the line of [1]. > > [1] http://www.chronox.de/kdf.html > Thanks for your suggestion. I didn't touch any key derivation standard before. I will study it. But I still want to use my original function currently. Because the same logic is also used in trusted key. I will happy to move to SP800-108 or HKDF when it's available in kernel. > > + > > +/* Derive authentication/encryption key */ > > +static int get_derived_key(u8 *derived_key, const char *derived_type_str, > > + bool may_sleep) [...snip] > > +static int trusted_key_init(void) > > +{ > > + struct trusted_key_payload *tkp; > > + struct key *key; > > + int err = 0; > > + > > + pr_debug("%s\n", __func__); > > + > > + /* find out swsusp-key */ > > + key = request_key(&key_type_trusted, skey.key_name, NULL); > > + if (IS_ERR(key)) { > > + pr_err("Request key error: %ld\n", PTR_ERR(key)); > > + err = PTR_ERR(key); > > + return err; > > + } > > + > > + down_write(&key->sem); > > + tkp = key->payload.data[0]; > > + if (invalid_key(tkp->key, tkp->key_len)) { > > + err = -EINVAL; > > + goto key_invalid; > > + } > > + skey.key_len = tkp->key_len; > > + memcpy(skey.key, tkp->key, tkp->key_len); > > + /* burn the original key contents */ > > + memzero_explicit(tkp->key, tkp->key_len); > > + > > +key_invalid: > > + up_write(&key->sem); > > + key_put(key); > > + > > + return err; > > +} > > + > > +static int user_key_init(void) > > This function and trusted_key_init look very similar - could they be collapsed > into one function? > The data structure is different between trusted key with user key. I will try to extract the duplicate part but may not collapse into one. > > +{ > > + struct user_key_payload *ukp; > > + struct key *key; > > + int err = 0; > > + > > + pr_debug("%s\n", __func__); > > + > > + /* find out swsusp-key */ > > + key = request_key(&key_type_user, skey.key_name, NULL); > > + if (IS_ERR(key)) { > > + pr_err("Request key error: %ld\n", PTR_ERR(key)); > > + err = PTR_ERR(key); > > + return err; > > + } > > + > > + down_write(&key->sem); > > + ukp = user_key_payload_locked(key); > > + if (!ukp) { > > + /* key was revoked before we acquired its semaphore */ > > + err = -EKEYREVOKED; > > + goto key_invalid; > > + } > > + if (invalid_key(ukp->data, ukp->datalen)) { > > + err = -EINVAL; > > + goto key_invalid; > > + } > > + skey.key_len = ukp->datalen; > > + memcpy(skey.key, ukp->data, ukp->datalen); > > Where would skey.key be destroyed again? > Yes, you saw it in later patch. Thanks a lot! Joey Lee
WARNING: multiple messages have this Message-ID (diff)
From: joeyli <jlee@suse.com> To: Stephan Mueller <smueller@chronox.de> Cc: "Lee, Chun-Yi" <joeyli.kernel@gmail.com>, "Rafael J . Wysocki" <rjw@rjwysocki.net>, Pavel Machek <pavel@ucw.cz>, linux-kernel@vger.kernel.org, linux-pm@vger.kernel.org, keyrings@vger.kernel.org, "Rafael J. Wysocki" <rafael.j.wysocki@intel.com>, Chen Yu <yu.c.chen@intel.com>, Oliver Neukum <oneukum@suse.com>, Ryan Chen <yu.chen.surf@gmail.com>, David Howells <dhowells@redhat.com>, Giovanni Gherdovich <ggherdovich@suse.cz>, Randy Dunlap <rdunlap@infradead.org>, Jann Horn <jannh@google.com>, Andy Lutomirski <luto@kernel.org> Subject: Re: [PATCH 1/5 v2] PM / hibernate: Create snapshot keys handler Date: Mon, 7 Jan 2019 23:33:27 +0800 [thread overview] Message-ID: <20190107153327.GB4210@linux-l9pv.suse> (raw) In-Reply-To: <4539995.kc8yiMsNgQ@tauon.chronox.de> Hi Stephan, First, thanks for your review! On Sun, Jan 06, 2019 at 09:01:27AM +0100, Stephan Mueller wrote: > Am Donnerstag, 3. Januar 2019, 15:32:23 CET schrieb Lee, Chun-Yi: > > Hi Chun, > > > This patch adds a snapshot keys handler for using the key retention > > service api to create keys for snapshot image encryption and > > authentication. > > > > This handler uses TPM trusted key as the snapshot master key, and the > > encryption key and authentication key are derived from the snapshot > > key. The user defined key can also be used as the snapshot master key > > , but user must be aware that the security of user key relies on user > > space. > > [...snip] > > +static int calc_hash(u8 *digest, const u8 *buf, unsigned int buflen, > > + bool may_sleep) > > +{ > > + struct shash_desc *desc; > > + int err; > > + > > + desc = kzalloc(sizeof(struct shash_desc) + > > + crypto_shash_descsize(hash_tfm), > > + may_sleep ? GFP_KERNEL : GFP_ATOMIC); > > Why not using SHASH_DESC_ON_STACK? > Because security concern and bad runtime performance. Please looking at c2cd0b08e1e patch for hibernation. And reference: https://lore.kernel.org/lkml/CA+55aFzCG-zNmZwX4A2FQpadafLfEzK6CC=qPXydAacU1RqZWA@mail.gmail.com/T/#u https://lwn.net/Articles/749064/ > > + if (!desc) > > + return -ENOMEM; > > + > > + desc->tfm = hash_tfm; > > + desc->flags = may_sleep ? CRYPTO_TFM_REQ_MAY_SLEEP : 0; > > + err = crypto_shash_digest(desc, buf, buflen, digest); > > + shash_desc_zero(desc); > > + kzfree(desc); > > + > > + return err; > > +} > > + > > +static int calc_key_hash(u8 *key, unsigned int key_len, const char *salt, > > + u8 *hash, bool may_sleep) > > +{ > > + unsigned int salted_buf_len; > > + u8 *salted_buf; > > + int ret; > > + > > + if (!key || !hash_tfm || !hash) > > + return -EINVAL; > > + > > + salted_buf_len = strlen(salt) + 1 + SNAPSHOT_KEY_SIZE; > > strlen on binary data? I guess that will not work. May I suggest to hand down > the length of salt to this function? > hm... The salt is actually a "salt string" that's gave from snapshot_get_auth_key() or snapshot_get_enc_key(). So I use strlen() here. I will change the name to salt_string to avoid confusion. > > + salted_buf = kzalloc(salted_buf_len, > > + may_sleep ? GFP_KERNEL : GFP_ATOMIC); > > + if (!salted_buf) > > + return -ENOMEM; > > + > > + strcpy(salted_buf, salt); > > + memcpy(salted_buf + strlen(salted_buf) + 1, key, key_len); > > + > > + ret = calc_hash(hash, salted_buf, salted_buf_len, may_sleep); > > + memzero_explicit(salted_buf, salted_buf_len); > > + kzfree(salted_buf); > > + > > + return ret; > > +} > > This function looks very much like a key derivation. May I strongly propose to Actually key derivation function is modified from the get_derived_key() from the encrypted.c file in encrypted key. > use an official KDF type like SP800-108 or HKDF? > > You find the counter-KDF according to SP800-108 in security/keys/dh.c (search > for functions *kdf*). > > Or we may start pulling in KDF support into the kernel crypto API via the > patches along the line of [1]. > > [1] http://www.chronox.de/kdf.html > Thanks for your suggestion. I didn't touch any key derivation standard before. I will study it. But I still want to use my original function currently. Because the same logic is also used in trusted key. I will happy to move to SP800-108 or HKDF when it's available in kernel. > > + > > +/* Derive authentication/encryption key */ > > +static int get_derived_key(u8 *derived_key, const char *derived_type_str, > > + bool may_sleep) [...snip] > > +static int trusted_key_init(void) > > +{ > > + struct trusted_key_payload *tkp; > > + struct key *key; > > + int err = 0; > > + > > + pr_debug("%s\n", __func__); > > + > > + /* find out swsusp-key */ > > + key = request_key(&key_type_trusted, skey.key_name, NULL); > > + if (IS_ERR(key)) { > > + pr_err("Request key error: %ld\n", PTR_ERR(key)); > > + err = PTR_ERR(key); > > + return err; > > + } > > + > > + down_write(&key->sem); > > + tkp = key->payload.data[0]; > > + if (invalid_key(tkp->key, tkp->key_len)) { > > + err = -EINVAL; > > + goto key_invalid; > > + } > > + skey.key_len = tkp->key_len; > > + memcpy(skey.key, tkp->key, tkp->key_len); > > + /* burn the original key contents */ > > + memzero_explicit(tkp->key, tkp->key_len); > > + > > +key_invalid: > > + up_write(&key->sem); > > + key_put(key); > > + > > + return err; > > +} > > + > > +static int user_key_init(void) > > This function and trusted_key_init look very similar - could they be collapsed > into one function? > The data structure is different between trusted key with user key. I will try to extract the duplicate part but may not collapse into one. > > +{ > > + struct user_key_payload *ukp; > > + struct key *key; > > + int err = 0; > > + > > + pr_debug("%s\n", __func__); > > + > > + /* find out swsusp-key */ > > + key = request_key(&key_type_user, skey.key_name, NULL); > > + if (IS_ERR(key)) { > > + pr_err("Request key error: %ld\n", PTR_ERR(key)); > > + err = PTR_ERR(key); > > + return err; > > + } > > + > > + down_write(&key->sem); > > + ukp = user_key_payload_locked(key); > > + if (!ukp) { > > + /* key was revoked before we acquired its semaphore */ > > + err = -EKEYREVOKED; > > + goto key_invalid; > > + } > > + if (invalid_key(ukp->data, ukp->datalen)) { > > + err = -EINVAL; > > + goto key_invalid; > > + } > > + skey.key_len = ukp->datalen; > > + memcpy(skey.key, ukp->data, ukp->datalen); > > Where would skey.key be destroyed again? > Yes, you saw it in later patch. Thanks a lot! Joey Lee
next prev parent reply other threads:[~2019-01-07 15:33 UTC|newest] Thread overview: 181+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-01-03 14:32 [PATCH 0/5 v2][RFC] Encryption and authentication for hibernate snapshot image Lee, Chun-Yi 2019-01-03 14:32 ` Lee, Chun-Yi 2019-01-03 14:32 ` [PATCH 1/5 v2] PM / hibernate: Create snapshot keys handler Lee, Chun-Yi 2019-01-03 14:32 ` Lee, Chun-Yi 2019-01-06 8:01 ` Stephan Mueller 2019-01-06 8:01 ` Stephan Mueller 2019-01-06 8:25 ` Stephan Mueller 2019-01-06 8:25 ` Stephan Mueller 2019-01-07 15:33 ` joeyli [this message] 2019-01-07 15:33 ` joeyli 2019-01-07 15:52 ` Stephan Mueller 2019-01-07 15:52 ` Stephan Mueller 2019-01-08 5:03 ` Herbert Xu 2019-01-08 5:03 ` Herbert Xu 2019-01-08 7:09 ` Stephan Mueller 2019-01-08 7:09 ` Stephan Mueller 2019-01-08 23:54 ` Andy Lutomirski 2019-01-08 23:54 ` Andy Lutomirski 2019-01-09 0:44 ` James Bottomley 2019-01-09 0:44 ` James Bottomley 2019-01-09 0:44 ` James Bottomley 2019-01-09 1:43 ` Andy Lutomirski 2019-01-09 1:43 ` Andy Lutomirski 2019-01-09 6:49 ` James Bottomley 2019-01-09 6:49 ` James Bottomley 2019-01-09 18:11 ` joeyli 2019-01-09 18:11 ` joeyli 2019-01-11 15:53 ` Jarkko Sakkinen 2019-01-11 15:53 ` Jarkko Sakkinen 2019-01-09 18:34 ` Andy Lutomirski 2019-01-09 18:34 ` Andy Lutomirski 2019-01-09 19:46 ` James Bottomley 2019-01-09 19:46 ` James Bottomley 2019-01-09 20:12 ` Andy Lutomirski 2019-01-09 20:12 ` Andy Lutomirski 2019-01-09 21:43 ` James Bottomley 2019-01-09 21:43 ` James Bottomley 2019-01-09 22:19 ` Pavel Machek 2019-01-09 22:19 ` Pavel Machek 2019-01-11 16:04 ` Jarkko Sakkinen 2019-01-11 16:04 ` Jarkko Sakkinen 2019-01-11 14:02 ` Jarkko Sakkinen 2019-01-11 14:02 ` Jarkko Sakkinen 2019-01-11 15:28 ` James Bottomley 2019-01-11 15:28 ` James Bottomley 2019-01-18 14:33 ` Jarkko Sakkinen 2019-01-18 14:33 ` Jarkko Sakkinen 2019-01-18 20:59 ` James Bottomley 2019-01-18 20:59 ` James Bottomley 2019-01-20 16:02 ` Jarkko Sakkinen 2019-01-20 16:02 ` Jarkko Sakkinen 2019-01-09 6:45 ` Stephan Mueller 2019-01-09 6:45 ` Stephan Mueller 2019-01-09 6:58 ` James Bottomley 2019-01-09 6:58 ` James Bottomley 2019-01-09 7:05 ` Stephan Mueller 2019-01-09 7:05 ` Stephan Mueller 2019-01-09 8:21 ` Eric Biggers 2019-01-09 8:21 ` Eric Biggers 2019-01-09 10:17 ` Stephan Mueller 2019-01-09 10:17 ` Stephan Mueller 2019-01-09 17:34 ` Eric Biggers 2019-01-09 17:34 ` Eric Biggers 2019-01-09 18:18 ` Stephan Mueller 2019-01-09 18:18 ` Stephan Mueller 2019-01-11 19:08 ` [PATCH 0/6] General Key Derivation Function Support Stephan Müller 2019-01-11 19:08 ` Stephan Müller 2019-01-11 19:09 ` [PATCH 1/6] crypto: add template handling for RNGs Stephan Müller 2019-01-11 19:09 ` Stephan Müller 2019-01-11 19:10 ` [PATCH 2/6] crypto: kdf - SP800-108 Key Derivation Function Stephan Müller 2019-01-11 19:10 ` Stephan Müller 2019-01-12 5:27 ` Eric Biggers 2019-01-12 5:27 ` Eric Biggers 2019-01-14 9:31 ` Stephan Müller 2019-01-14 9:31 ` Stephan Müller 2019-01-11 19:10 ` [PATCH 3/6] crypto: kdf - add known answer tests Stephan Müller 2019-01-11 19:10 ` Stephan Müller 2019-01-12 5:26 ` Eric Biggers 2019-01-12 5:26 ` Eric Biggers 2019-01-14 9:26 ` Stephan Müller 2019-01-14 9:26 ` Stephan Müller 2019-01-11 19:10 ` [PATCH 4/6] crypto: hkdf - RFC5869 Key Derivation Function Stephan Müller 2019-01-11 19:10 ` Stephan Müller 2019-01-12 5:12 ` Eric Biggers 2019-01-12 5:12 ` Eric Biggers 2019-01-12 9:55 ` Herbert Xu 2019-01-12 9:55 ` Herbert Xu 2019-01-13 7:56 ` Stephan Müller 2019-01-13 7:56 ` Stephan Müller 2019-01-13 16:52 ` James Bottomley 2019-01-13 16:52 ` James Bottomley 2019-01-14 9:30 ` Stephan Müller 2019-01-14 9:30 ` Stephan Müller 2019-01-14 17:53 ` Eric Biggers 2019-01-14 17:53 ` Eric Biggers 2019-01-14 18:44 ` Stephan Mueller 2019-01-14 18:44 ` Stephan Mueller 2019-01-11 19:10 ` [PATCH 5/6] crypto: hkdf - add known answer tests Stephan Müller 2019-01-11 19:10 ` Stephan Müller 2019-01-12 5:19 ` Eric Biggers 2019-01-12 5:19 ` Eric Biggers 2019-01-14 9:25 ` Stephan Müller 2019-01-14 9:25 ` Stephan Müller 2019-01-14 17:44 ` Eric Biggers 2019-01-14 17:44 ` Eric Biggers 2019-01-11 19:11 ` [PATCH 6/6] crypto: tcrypt - add KDF test invocation Stephan Müller 2019-01-11 19:11 ` Stephan Müller 2019-01-16 11:06 ` [PATCH v2 0/6] General Key Derivation Function Support Stephan Müller 2019-01-16 11:06 ` Stephan Müller 2019-01-16 11:07 ` [PATCH v2 1/6] crypto: add template handling for RNGs Stephan Müller 2019-01-16 11:07 ` Stephan Müller 2019-01-16 11:08 ` [PATCH v2 2/6] crypto: kdf - SP800-108 Key Derivation Function Stephan Müller 2019-01-16 11:08 ` Stephan Müller 2019-01-16 11:08 ` [PATCH v2 3/6] crypto: kdf - add known answer tests Stephan Müller 2019-01-16 11:08 ` Stephan Müller 2019-01-16 11:08 ` [PATCH v2 4/6] crypto: hkdf - HMAC-based Extract-and-Expand KDF Stephan Müller 2019-01-16 11:08 ` Stephan Müller 2019-01-16 11:09 ` [PATCH v2 5/6] crypto: hkdf - add known answer tests Stephan Müller 2019-01-16 11:09 ` Stephan Müller 2019-01-16 11:09 ` [PATCH v2 6/6] crypto: tcrypt - add KDF test invocation Stephan Müller 2019-01-16 11:09 ` Stephan Müller 2019-01-28 10:07 ` [PATCH v2 0/6] General Key Derivation Function Support Stephan Mueller 2019-01-28 10:07 ` Stephan Mueller 2019-01-30 10:08 ` Herbert Xu 2019-01-30 10:08 ` Herbert Xu 2019-01-30 14:39 ` Stephan Mueller 2019-01-30 14:39 ` Stephan Mueller 2019-02-08 7:45 ` Herbert Xu 2019-02-08 7:45 ` Herbert Xu 2019-02-08 8:00 ` Stephan Mueller 2019-02-08 8:00 ` Stephan Mueller 2019-02-08 8:05 ` Herbert Xu 2019-02-08 8:05 ` Herbert Xu 2019-02-08 8:17 ` Stephan Mueller 2019-02-08 8:17 ` Stephan Mueller 2019-02-19 5:44 ` Herbert Xu 2019-02-19 5:44 ` Herbert Xu 2019-01-09 15:34 ` [PATCH 1/5 v2] PM / hibernate: Create snapshot keys handler James Bottomley 2019-01-09 15:34 ` James Bottomley 2019-01-09 6:27 ` Stephan Mueller 2019-01-09 6:27 ` Stephan Mueller 2019-01-03 14:32 ` [PATCH 2/5] PM / hibernate: Generate and verify signature for snapshot image Lee, Chun-Yi 2019-01-03 14:32 ` Lee, Chun-Yi 2019-01-06 8:09 ` Stephan Mueller 2019-01-06 8:09 ` Stephan Mueller 2019-01-07 18:58 ` Dan Carpenter 2019-01-07 18:58 ` Dan Carpenter 2019-01-03 14:32 ` [PATCH 3/5] PM / hibernate: Encrypt " Lee, Chun-Yi 2019-01-03 14:32 ` Lee, Chun-Yi 2019-01-06 8:23 ` Stephan Mueller 2019-01-06 8:23 ` Stephan Mueller 2019-01-03 14:32 ` [PATCH 4/5 v2] PM / hibernate: Erase the snapshot master key in snapshot pages Lee, Chun-Yi 2019-01-03 14:32 ` Lee, Chun-Yi 2019-01-03 14:32 ` [PATCH 5/5 v2] PM / hibernate: An option to request that snapshot image must be authenticated Lee, Chun-Yi 2019-01-03 14:32 ` Lee, Chun-Yi 2019-01-06 18:10 ` [PATCH 0/5 v2][RFC] Encryption and authentication for hibernate snapshot image Pavel Machek 2019-01-06 18:10 ` Pavel Machek 2019-01-07 17:37 ` joeyli 2019-01-07 17:37 ` joeyli 2019-01-07 18:07 ` Pavel Machek 2019-01-07 18:07 ` Pavel Machek 2019-01-08 21:41 ` Andy Lutomirski 2019-01-08 21:41 ` Andy Lutomirski 2019-01-08 23:42 ` Pavel Machek 2019-01-08 23:42 ` Pavel Machek 2019-01-09 16:39 ` joeyli 2019-01-09 16:39 ` joeyli 2019-01-09 16:47 ` Stephan Mueller 2019-01-09 16:47 ` Stephan Mueller 2019-01-11 14:29 ` joeyli 2019-01-11 14:29 ` joeyli 2019-01-09 16:51 ` joeyli 2019-01-09 16:51 ` joeyli 2019-01-09 18:47 ` Andy Lutomirski 2019-01-09 18:47 ` Andy Lutomirski 2019-01-10 15:12 ` joeyli 2019-01-10 15:12 ` joeyli 2019-01-11 1:09 ` Andy Lutomirski 2019-01-11 1:09 ` Andy Lutomirski 2019-01-11 14:59 ` joeyli 2019-01-11 14:59 ` joeyli
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20190107153327.GB4210@linux-l9pv.suse \ --to=jlee@suse.com \ --cc=dhowells@redhat.com \ --cc=ggherdovich@suse.cz \ --cc=jannh@google.com \ --cc=joeyli.kernel@gmail.com \ --cc=keyrings@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-pm@vger.kernel.org \ --cc=luto@kernel.org \ --cc=oneukum@suse.com \ --cc=pavel@ucw.cz \ --cc=rafael.j.wysocki@intel.com \ --cc=rdunlap@infradead.org \ --cc=rjw@rjwysocki.net \ --cc=smueller@chronox.de \ --cc=yu.c.chen@intel.com \ --cc=yu.chen.surf@gmail.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.