From: Andy Lutomirski <luto@kernel.org> To: James Bottomley <James.Bottomley@hansenpartnership.com> Cc: Andy Lutomirski <luto@kernel.org>, Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>, Stephan Mueller <smueller@chronox.de>, Herbert Xu <herbert@gondor.apana.org.au>, "Lee, Chun-Yi" <joeyli.kernel@gmail.com>, "Rafael J . Wysocki" <rjw@rjwysocki.net>, Pavel Machek <pavel@ucw.cz>, LKML <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> Subject: Re: [PATCH 1/5 v2] PM / hibernate: Create snapshot keys handler Date: Wed, 09 Jan 2019 20:12:46 +0000 [thread overview] Message-ID: <CALCETrWKUTKp1tO00fPcbtm5vu2b4CHJQ6XcmkrWJY9P1h+mzA@mail.gmail.com> (raw) In-Reply-To: <1547063189.2879.47.camel@HansenPartnership.com> On Wed, Jan 9, 2019 at 11:46 AM James Bottomley <James.Bottomley@hansenpartnership.com> wrote: > > On Wed, 2019-01-09 at 10:34 -0800, Andy Lutomirski wrote: > > > > On Jan 8, 2019, at 10:49 PM, James Bottomley <James.Bottomley@han > > > > senpartnership.com> wrote: > > > > > > If so, then a signature that the kernel would have prevented user > > code from generating is de facto an attestation that the kernel > > generated it (or that the kernel was compromised, which is sort of > > equivalent). > > The TPM's idea of this is it polices by authorization. Now one of the > things we can do here is add what's called locality based > authorization. we have three non-uefi localities to play with and we > could enforce walling one off for the kernel only to use, so a kernel > key could come with a policy requiring use of the kernel locality for > use of the key. That would give you an effective guarantee that only > the kernel could use this key. Note the enforcement of locality would > require a key policy, which is easy for TPM 1.2, but requires the use > of a policy session for TPM 2.0 which means we'd have to improve our > policy session handling. Hmm. On an *extremely* brief reading of what "locality" means, this seems entirely sensible. > > > > I’m not sure I follow. Here are the two properties I’d like to see: > > > > 1. If you have an encrypted hibernation image, the only thing you > > should be able to do with it is to restore it. So only an actual > > Linux kernel in hibernation restore mode ought to be able to restore > > it. We get this if the image can only be read with appropriate PCRs > > and then only by the kernel. This way, you can’t just read out > > secrets from the image if you steal a laptop — you have to actually > > boot the thing. > > Right, this we can do and if you use a TPM sealed encryption key, you > can guarantee the image will only restore on the same physical system. > You don't need PCRs for this, just the TPM and the locality > enforcement. > > Note if someone has your laptop and the ability to boot their own > kernels, they could always corrupt the kernel into decrypting the image > or giving you the unsealed key, but there's no real way of preventing > that even with PCR sealing or lockdown, so the basis for the threat > model is very much my laptop in my possession running my kernel. I'm not entirely sure I agree. With a TPM-aware bootloader, it really ought to be possible to seal to PCRs such that a corrupted kernel can't restore the image. Obviously a *compromised* but otherwise valid kernel will be able to restore the image. But this is all barking up the wrong tree. If you want your laptop to resist physical theft such that whoever stole it can boot it but can't directly extract any data, you want to use dm-crypt (or, haha, OPAL, but I just read a paper about some people who evaluated a bunch of drives and had a very hard time finding one that actually implemented OPAL in a usefully secure manner). A LUKS replacement or wrapper that does something intelligent with the TPM would be great. This kind of thing IMO does not belong in hibernation. IOW, I think we do get about as much as we would want if we just seal with a locality that only allows kernel use and ignore PCRs entirely. This makes it so that you need the ability to run ring 0 code to decrypt the image, which means that we get all the nice lockdown properties. > > > 2. You shouldn’t be able to create an intentionally corrupt image > > that pwns you when you restore it unless you have already pwned the > > kernel. > > So here there's a problem: the policy stated above governs key *use* > not key creation, so anyone can create a key that has a locality > restriction. The way to guarantee that the key was created by > something that has access to the locality is to have a parent key with > a locality use policy (key creation requires parent key use > authorization). Which means every system would have to create a > persistent parent key for the kernel to use (the kernel could do this > and it could be made NV resident for persistence, so it's not > impossible, just complicated). Why does anything here need to be persistent? The kernel could create a locality-restricted key on the fly, use it to sign and/or seal the hibernation image, and write the wrapped key blob into the hibernation image. > I suppose that a good summary of my opinion is that there is no point > > to kernel support for encrypted hibernation images until lockdown is > > upstream. > > I really don't think lockdown helps. If we implement locality > isolation for the kernels use of keys, a properly functioning kernel > isn't going to be tricked into releasing one of its keys to userspace. > A buggy kernel might be exploited to cause it to give one up but that > would happen irrespective of lockdown and, of course, all bets are off > if the attacker can boot their own kernel. > I'm not saying that lockdown helps. I'm saying that encrypting the hibernation image in the kernel may be pointless until the kernel supports lockdown. If we don't support lockdown, then user code can encrypt the hibernation image all by itself. The code will be easier to understand, more flexible, and won't require a kernel upgrade :) Honestly, no one should be using resume= anyway. Any distro with hibernation support worth its salt should support having the hibernation image on a dm-crypt volume, in which case it *must* support userspace-driven resume. Of course, my laptop that's been upgraded through many Fedora revisions doesn't survive a hibernate/resume cycle, but that's not the kernel's fault. --Andy P.S. One thing I do want to try is encrypted *swap*. The keying for that is trivial -- the kernel can just make a key, store it in ordinary kernel memory, and use it to encrypt and decrypt swap pages as needed. Getting replay protection or authentication may be tricky due to the need for metadata, but plain old AES-XTS or HPolyChaChaNotSpeckAnymore would be entirely straightforward and would get 90% of the benefit. Sure, swap could live on dm-crypt too, but that's an administration mess, and offering a strong and cheap alternative to mlock() for crypto programs to protect their secrets would be fantastic and encrypted swap plus some API to verify that anonymous memory is, in fact, backed by encrypted swap would do the job.
WARNING: multiple messages have this Message-ID (diff)
From: Andy Lutomirski <luto@kernel.org> To: James Bottomley <James.Bottomley@hansenpartnership.com> Cc: Andy Lutomirski <luto@kernel.org>, Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>, Stephan Mueller <smueller@chronox.de>, Herbert Xu <herbert@gondor.apana.org.au>, "Lee, Chun-Yi" <joeyli.kernel@gmail.com>, "Rafael J . Wysocki" <rjw@rjwysocki.net>, Pavel Machek <pavel@ucw.cz>, LKML <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> Subject: Re: [PATCH 1/5 v2] PM / hibernate: Create snapshot keys handler Date: Wed, 9 Jan 2019 12:12:46 -0800 [thread overview] Message-ID: <CALCETrWKUTKp1tO00fPcbtm5vu2b4CHJQ6XcmkrWJY9P1h+mzA@mail.gmail.com> (raw) In-Reply-To: <1547063189.2879.47.camel@HansenPartnership.com> On Wed, Jan 9, 2019 at 11:46 AM James Bottomley <James.Bottomley@hansenpartnership.com> wrote: > > On Wed, 2019-01-09 at 10:34 -0800, Andy Lutomirski wrote: > > > > On Jan 8, 2019, at 10:49 PM, James Bottomley <James.Bottomley@han > > > > senpartnership.com> wrote: > > > > > > If so, then a signature that the kernel would have prevented user > > code from generating is de facto an attestation that the kernel > > generated it (or that the kernel was compromised, which is sort of > > equivalent). > > The TPM's idea of this is it polices by authorization. Now one of the > things we can do here is add what's called locality based > authorization. we have three non-uefi localities to play with and we > could enforce walling one off for the kernel only to use, so a kernel > key could come with a policy requiring use of the kernel locality for > use of the key. That would give you an effective guarantee that only > the kernel could use this key. Note the enforcement of locality would > require a key policy, which is easy for TPM 1.2, but requires the use > of a policy session for TPM 2.0 which means we'd have to improve our > policy session handling. Hmm. On an *extremely* brief reading of what "locality" means, this seems entirely sensible. > > > > I’m not sure I follow. Here are the two properties I’d like to see: > > > > 1. If you have an encrypted hibernation image, the only thing you > > should be able to do with it is to restore it. So only an actual > > Linux kernel in hibernation restore mode ought to be able to restore > > it. We get this if the image can only be read with appropriate PCRs > > and then only by the kernel. This way, you can’t just read out > > secrets from the image if you steal a laptop — you have to actually > > boot the thing. > > Right, this we can do and if you use a TPM sealed encryption key, you > can guarantee the image will only restore on the same physical system. > You don't need PCRs for this, just the TPM and the locality > enforcement. > > Note if someone has your laptop and the ability to boot their own > kernels, they could always corrupt the kernel into decrypting the image > or giving you the unsealed key, but there's no real way of preventing > that even with PCR sealing or lockdown, so the basis for the threat > model is very much my laptop in my possession running my kernel. I'm not entirely sure I agree. With a TPM-aware bootloader, it really ought to be possible to seal to PCRs such that a corrupted kernel can't restore the image. Obviously a *compromised* but otherwise valid kernel will be able to restore the image. But this is all barking up the wrong tree. If you want your laptop to resist physical theft such that whoever stole it can boot it but can't directly extract any data, you want to use dm-crypt (or, haha, OPAL, but I just read a paper about some people who evaluated a bunch of drives and had a very hard time finding one that actually implemented OPAL in a usefully secure manner). A LUKS replacement or wrapper that does something intelligent with the TPM would be great. This kind of thing IMO does not belong in hibernation. IOW, I think we do get about as much as we would want if we just seal with a locality that only allows kernel use and ignore PCRs entirely. This makes it so that you need the ability to run ring 0 code to decrypt the image, which means that we get all the nice lockdown properties. > > > 2. You shouldn’t be able to create an intentionally corrupt image > > that pwns you when you restore it unless you have already pwned the > > kernel. > > So here there's a problem: the policy stated above governs key *use* > not key creation, so anyone can create a key that has a locality > restriction. The way to guarantee that the key was created by > something that has access to the locality is to have a parent key with > a locality use policy (key creation requires parent key use > authorization). Which means every system would have to create a > persistent parent key for the kernel to use (the kernel could do this > and it could be made NV resident for persistence, so it's not > impossible, just complicated). Why does anything here need to be persistent? The kernel could create a locality-restricted key on the fly, use it to sign and/or seal the hibernation image, and write the wrapped key blob into the hibernation image. > I suppose that a good summary of my opinion is that there is no point > > to kernel support for encrypted hibernation images until lockdown is > > upstream. > > I really don't think lockdown helps. If we implement locality > isolation for the kernels use of keys, a properly functioning kernel > isn't going to be tricked into releasing one of its keys to userspace. > A buggy kernel might be exploited to cause it to give one up but that > would happen irrespective of lockdown and, of course, all bets are off > if the attacker can boot their own kernel. > I'm not saying that lockdown helps. I'm saying that encrypting the hibernation image in the kernel may be pointless until the kernel supports lockdown. If we don't support lockdown, then user code can encrypt the hibernation image all by itself. The code will be easier to understand, more flexible, and won't require a kernel upgrade :) Honestly, no one should be using resume= anyway. Any distro with hibernation support worth its salt should support having the hibernation image on a dm-crypt volume, in which case it *must* support userspace-driven resume. Of course, my laptop that's been upgraded through many Fedora revisions doesn't survive a hibernate/resume cycle, but that's not the kernel's fault. --Andy P.S. One thing I do want to try is encrypted *swap*. The keying for that is trivial -- the kernel can just make a key, store it in ordinary kernel memory, and use it to encrypt and decrypt swap pages as needed. Getting replay protection or authentication may be tricky due to the need for metadata, but plain old AES-XTS or HPolyChaChaNotSpeckAnymore would be entirely straightforward and would get 90% of the benefit. Sure, swap could live on dm-crypt too, but that's an administration mess, and offering a strong and cheap alternative to mlock() for crypto programs to protect their secrets would be fantastic and encrypted swap plus some API to verify that anonymous memory is, in fact, backed by encrypted swap would do the job.
next prev parent reply other threads:[~2019-01-09 20:12 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 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 [this message] 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=CALCETrWKUTKp1tO00fPcbtm5vu2b4CHJQ6XcmkrWJY9P1h+mzA@mail.gmail.com \ --to=luto@kernel.org \ --cc=James.Bottomley@hansenpartnership.com \ --cc=dhowells@redhat.com \ --cc=ggherdovich@suse.cz \ --cc=herbert@gondor.apana.org.au \ --cc=jannh@google.com \ --cc=jarkko.sakkinen@linux.intel.com \ --cc=joeyli.kernel@gmail.com \ --cc=keyrings@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-pm@vger.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.