public inbox for glibc-cvs@sourceware.org help / color / mirror / Atom feed
From: Szabolcs Nagy <nsz@sourceware.org> To: glibc-cvs@sourceware.org Subject: [glibc/nsz/pacbti-v6] (14 commits) aarch64: add NEWS entry about branch protection support Date: Thu, 2 Jul 2020 08:38:08 +0000 (GMT) [thread overview] Message-ID: <20200702083808.191293860C3A@sourceware.org> (raw) The branch 'nsz/pacbti-v6' was updated to point to: 1be15b1c45... aarch64: add NEWS entry about branch protection support It previously pointed to: 94342f2e1c... aarch64: add NEWS entry about branch protection support Diff: !!! WARNING: THE FOLLOWING COMMITS ARE NO LONGER ACCESSIBLE (LOST): ------------------------------------------------------------------- 94342f2... aarch64: add NEWS entry about branch protection support 3354b73... aarch64: redefine RETURN_ADDRESS to strip PAC 6912a89... aarch64: fix pac-ret support in _mcount fe35e07... aarch64: Add pac-ret support to assembly files e5a6ef5... aarch64: configure check for pac-ret code generation d70b001... aarch64: ensure objects are BTI compatible 2d49a4f... aarch64: enable BTI at runtime 703df8e... rtld: Clean up PT_NOTE and add PT_GNU_PROPERTY handling 61533cc... aarch64: fix RTLD_START for BTI 90584dd... aarch64: fix swapcontext for BTI 80723d0... aarch64: Add BTI support to assembly files f76a919... aarch64: Rename place holder .S files to .c cf32244... aarch64: configure test for BTI support cf429c3... Rewrite abi-note.S in C. commit 94342f2e1cfb24b4830e7f5aed96882cd0981dee Author: Szabolcs Nagy <szabolcs.nagy@arm.com> Date: Thu Jun 11 18:19:40 2020 +0100 aarch64: add NEWS entry about branch protection support This is a new security feature that relies on architecture extensions and needs glibc to be built with a gcc configured with branch protection. commit 3354b735255589858af1eaa23867c4f1ac0c65fb Author: Szabolcs Nagy <szabolcs.nagy@arm.com> Date: Wed Apr 15 17:40:45 2020 +0100 aarch64: redefine RETURN_ADDRESS to strip PAC RETURN_ADDRESS is used at several places in glibc to mean a valid code address of the call site, but with pac-ret it may contain a pointer authentication code (PAC), so its definition is adjusted. This is gcc PR target/94891: __builtin_return_address should not expose signed pointers to user code where it can cause ABI issues. In glibc RETURN_ADDRESS is only changed if it is built with pac-ret. There is no detection for the specific gcc issue because it is hard to test and the additional xpac does not cause problems. commit 6912a894dcd66e24305e089d4c6de3c1b80e4cee Author: Szabolcs Nagy <szabolcs.nagy@arm.com> Date: Wed May 13 12:10:13 2020 +0100 aarch64: fix pac-ret support in _mcount Currently gcc -pg -mbranch-protection=pac-ret passes signed return address to _mcount, so _mcount now has to always strip pac from the frompc since that's from user code that may be built with pac-ret. This is gcc PR target/94791: signed pointers should not escape and get passed across extern call boundaries, since that's an ABI break, but because existing gcc has this issue we work it around in glibc until that is resolved. This is compatible with a fixed gcc and it is a nop on systems without PAuth support. The bug was introduced in gcc-7 with -msign-return-address=non-leaf|all support which in gcc-9 got renamed to -mbranch-protection=pac-ret|pac-ret+leaf|standard. strip_pac uses inline asm instead of __builtin_aarch64_xpaclri since that is not a documented api and not available in all supported gccs. commit fe35e074f38bfc3705374939138f936d64e88a22 Author: Szabolcs Nagy <szabolcs.nagy@arm.com> Date: Wed Apr 29 11:49:20 2020 +0100 aarch64: Add pac-ret support to assembly files Use return address signing in assembly files for functions that save LR when pac-ret is enabled in the compiler. The GNU property note for PAC-RET is not meaningful to the dynamic linker so it is not strictly required, but it may be used to track the security property of binaries. (The PAC-RET property is only set if BTI is set too because BTI implies working GNU property support.) Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org> commit e5a6ef585542c2b1ef7663a062630995a2a7231d Author: Szabolcs Nagy <szabolcs.nagy@arm.com> Date: Thu May 7 18:30:12 2020 +0100 aarch64: configure check for pac-ret code generation Return address signing requires unwinder support, which is present in libgcc since >=gcc-7, however due to bugs the support may be broken in <gcc-10 (and similarly there may be issues in custom unwinders), so pac-ret is not always safe to use. So in assembly code glibc should only use pac-ret if the compiler uses it too. Unfortunately there is no predefined feature macro for it set by the compiler so pac-ret is inferred from the code generation. Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org> commit d70b0013e7348d11bc819854861365c2ee59a35f Author: Szabolcs Nagy <szabolcs.nagy@arm.com> Date: Tue Jun 30 11:12:40 2020 +0100 aarch64: ensure objects are BTI compatible When glibc is built with branch protection (i.e. with a gcc configured with --enable-standard-branch-protection), all glibc binaries should be BTI compatible and marked as such. It is easy to link BTI incompatible objects by accident and this is silent currently which is usually not the expectation, so this is changed into a link error. (There is no linker flag for failing on BTI incompatible inputs so all warnings are turned into fatal errors outside the test system when building glibc with branch protection.) Unfortunately, outlined atomic functions are not BTI compatible in libgcc (PR libgcc/96001), so to build glibc with current gcc use 'CC=gcc -mno-outline-atomics', this should be fixed in libgcc soon and then glibc can be built and tested without such workarounds. commit 2d49a4ff18f58ada3ed426ffe92ad4ca4a6af272 Author: Sudakshina Das <sudi.das@arm.com> Date: Mon Jun 22 10:57:20 2020 +0100 aarch64: enable BTI at runtime Binaries can opt-in to using BTI via an ELF object file marking. The dynamic linker has to then mprotect the executable segments with PROT_BTI. In case of static linked executables or in case of the dynamic linker itself, PROT_BTI protection is done by the operating system. On AArch64 glibc uses PT_GNU_PROPERTY instead of PT_NOTE to check the properties of a binary because PT_NOTE can be unreliable with old linkers (old linkers just append the notes of input objects together and add them to the output without checking them for consistency which means multiple incompatible GNU property notes can be present in PT_NOTE). BTI property is handled in the loader even if glibc is not built with BTI support, so in theory user code can be BTI protected independently of glibc. In practice though user binaries are not marked with the BTI property if glibc has no support because the static linked libc objects (crt files, libc_nonshared.a) are unmarked. This patch relies on Linux userspace API that is not yet in a linux release but in v5.8-rc1 so scheduled to be in Linux 5.8. Co-authored-by: Szabolcs Nagy <szabolcs.nagy@arm.com> commit 703df8e40ece08466090e755cd391f0e1e56fb9e Author: Szabolcs Nagy <szabolcs.nagy@arm.com> Date: Mon Jun 22 10:56:38 2020 +0100 rtld: Clean up PT_NOTE and add PT_GNU_PROPERTY handling Add generic code to handle PT_GNU_PROPERTY notes. Invalid content is ignored, _dl_process_pt_gnu_property is always called after PT_LOAD segments are mapped and it has no failure modes. Currently only one NT_GNU_PROPERTY_TYPE_0 note is handled, which contains target specific properties: the _dl_process_gnu_property hook is called for each property. The old _dl_process_pt_note and _rtld_process_pt_note differ in how the program header is read. The old _dl_process_pt_note is called before PT_LOAD segments are mapped and _rtld_process_pt_note is called after PT_LOAD segments are mapped. The old _rtld_process_pt_note is removed and _dl_process_pt_note is always called after PT_LOAD segments are mapped and now it has no failure modes. The program headers are scanned backwards so that PT_NOTE can be skipped if PT_GNU_PROPERTY exists. Co-Authored-By: H.J. Lu <hjl.tools@gmail.com> commit 61533cce8675be5a47148caf64a64c6315a4206d Author: Szabolcs Nagy <szabolcs.nagy@arm.com> Date: Tue Mar 31 17:32:14 2020 +0100 aarch64: fix RTLD_START for BTI Tailcalls must use x16 or x17 for the indirect branch instruction to be compatible with code that uses BTI c at function entries. (Other forms of indirect branches can only land on BTI j.) Also added a BTI c at the ELF entry point of rtld, this is not strictly necessary since the kernel does not use indirect branch to get there, but it seems safest once building glibc itself with BTI is supported. Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org> commit 90584dd4ca8871295e45d7a1fa658252fe581241 Author: Szabolcs Nagy <szabolcs.nagy@arm.com> Date: Wed Apr 1 10:31:41 2020 +0100 aarch64: fix swapcontext for BTI setcontext returns to the specified context via an indirect jump, so there should be a BTI j. In case of getcontext (and all other returns_twice functions) the compiler adds BTI j at the call site, but swapcontext is a normal c call that is currently not handled specially by the compiler. So we change swapcontext such that the saved context returns to a local address that has BTI j and then swapcontext returns to the caller via a normal RET. For this we save the original return address in the slot for x1 of the context because x1 need not be preserved by swapcontext but it is restored when the context saved by swapcontext is resumed. The alternative fix (which is done on x86) would make swapcontext special in the compiler so BTI j is emitted at call sites, on x86 there is an indirect_return attribute for this, on AArch64 we would have to use returns_twice. It was decided against because such fix may need user code updates: the attribute has to be added when swapcontext is called via a function pointer and it breaks always_inline functions with swapcontext. Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org> commit 80723d093c60fee1f9e96c37e1102a011fa5c15c Author: Sudakshina Das <sudi.das@arm.com> Date: Tue Mar 17 15:44:18 2020 +0000 aarch64: Add BTI support to assembly files To enable building glibc with branch protection, assembly code needs BTI landing pads and ELF object file markings in the form of a GNU property note. The landing pads are unconditionally added to all functions that may be indirectly called. When the code segment is not mapped with PROT_BTI these instructions are nops. They are kept in the code when BTI is not supported so that the layout of performance critical code is unchanged across configurations. The GNU property notes are only added when there is support for BTI in the toolchain, because old binutils does not handle the notes right. (Does not know how to merge them nor to put them in PT_GNU_PROPERTY segment instead of PT_NOTE, and some versions of binutils emit warnings about the unknown GNU property. In such cases the produced libc binaries would not have valid ELF marking so BTI would not be enabled.) Note: functions using ENTRY or ENTRY_ALIGN now start with an additional BTI c, so alignment of the following code changes, but ENTRY_ALIGN_AND_PAD was fixed so there is no change to the existing code layout. Some string functions may need to be tuned for optimal performance after this commit. Co-authored-by: Szabolcs Nagy <szabolcs.nagy@arm.com> Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org> commit f76a919e8900dfa93eb5ad828d532c8b6ffa3767 Author: Szabolcs Nagy <szabolcs.nagy@arm.com> Date: Wed Apr 1 09:52:37 2020 +0100 aarch64: Rename place holder .S files to .c The compiler can add required elf markings based on CFLAGS but the assembler cannot, so using C code for empty files creates less of a maintenance problem. Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org> commit cf32244b586222b0ab68e3b49d7394c35d00dea5 Author: Szabolcs Nagy <szabolcs.nagy@arm.com> Date: Wed May 6 20:22:16 2020 +0100 aarch64: configure test for BTI support Check BTI support in the compiler and linker. The check also requires READELF that understands the BTI GNU property note. It is expected to succeed with gcc >=gcc-9 configured with --enable-standard-branch-protection and binutils >=binutils-2.33. Note: passing -mbranch-protection=bti in CFLAGS when building glibc may not be enough to get a glibc that supports BTI because crtbegin* and crtend* provided by the compiler needs to be BTI compatible too. commit cf429c3641693277c92b224655601adb2ce39ec4 Author: Szabolcs Nagy <szabolcs.nagy@arm.com> Date: Wed Apr 1 16:02:03 2020 +0100 Rewrite abi-note.S in C. Using C code allows the compiler to add target specific object file markings based on CFLAGS. The arm specific abi-note.S is removed and similar object file fix up will be avoided on AArch64 with standard branch-prtection. Summary of changes (added commits): ----------------------------------- 1be15b1... aarch64: add NEWS entry about branch protection support 09c1ff2... aarch64: redefine RETURN_ADDRESS to strip PAC a8014c4... aarch64: fix pac-ret support in _mcount a87bc4a... aarch64: Add pac-ret support to assembly files 4a42b6f... aarch64: configure check for pac-ret code generation 5273381... aarch64: ensure objects are BTI compatible 582f1a2... aarch64: enable BTI at runtime 09ea243... rtld: Clean up PT_NOTE and add PT_GNU_PROPERTY handling 4b3b0a9... aarch64: fix RTLD_START for BTI 83b93ef... aarch64: fix swapcontext for BTI f26c70e... aarch64: Add BTI support to assembly files 81a0ed9... aarch64: Rename place holder .S files to .c 3492d7d... aarch64: configure test for BTI support 0f47f6f... Rewrite abi-note.S in C. commit 1be15b1c45e8e90c8746e7103b3151080c49bb76 Author: Szabolcs Nagy <szabolcs.nagy@arm.com> Date: Thu Jun 11 18:19:40 2020 +0100 aarch64: add NEWS entry about branch protection support This is a new security feature that relies on architecture extensions and needs glibc to be built with a gcc configured with branch protection. commit 09c1ff256bbfb8d21474e74ae3bd449239aa32c7 Author: Szabolcs Nagy <szabolcs.nagy@arm.com> Date: Wed Apr 15 17:40:45 2020 +0100 aarch64: redefine RETURN_ADDRESS to strip PAC RETURN_ADDRESS is used at several places in glibc to mean a valid code address of the call site, but with pac-ret it may contain a pointer authentication code (PAC), so its definition is adjusted. This is gcc PR target/94891: __builtin_return_address should not expose signed pointers to user code where it can cause ABI issues. In glibc RETURN_ADDRESS is only changed if it is built with pac-ret. There is no detection for the specific gcc issue because it is hard to test and the additional xpac does not cause problems. commit a8014c48c1a2a0398e49b04a08962355c7dcbb11 Author: Szabolcs Nagy <szabolcs.nagy@arm.com> Date: Wed May 13 12:10:13 2020 +0100 aarch64: fix pac-ret support in _mcount Currently gcc -pg -mbranch-protection=pac-ret passes signed return address to _mcount, so _mcount now has to always strip pac from the frompc since that's from user code that may be built with pac-ret. This is gcc PR target/94791: signed pointers should not escape and get passed across extern call boundaries, since that's an ABI break, but because existing gcc has this issue we work it around in glibc until that is resolved. This is compatible with a fixed gcc and it is a nop on systems without PAuth support. The bug was introduced in gcc-7 with -msign-return-address=non-leaf|all support which in gcc-9 got renamed to -mbranch-protection=pac-ret|pac-ret+leaf|standard. strip_pac uses inline asm instead of __builtin_aarch64_xpaclri since that is not a documented api and not available in all supported gccs. commit a87bc4ad93ba09f35adb9284fc932627e3b6990d Author: Szabolcs Nagy <szabolcs.nagy@arm.com> Date: Wed Apr 29 11:49:20 2020 +0100 aarch64: Add pac-ret support to assembly files Use return address signing in assembly files for functions that save LR when pac-ret is enabled in the compiler. The GNU property note for PAC-RET is not meaningful to the dynamic linker so it is not strictly required, but it may be used to track the security property of binaries. (The PAC-RET property is only set if BTI is set too because BTI implies working GNU property support.) Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org> commit 4a42b6f00778f009349c08ead8603d6d76e9928b Author: Szabolcs Nagy <szabolcs.nagy@arm.com> Date: Thu May 7 18:30:12 2020 +0100 aarch64: configure check for pac-ret code generation Return address signing requires unwinder support, which is present in libgcc since >=gcc-7, however due to bugs the support may be broken in <gcc-10 (and similarly there may be issues in custom unwinders), so pac-ret is not always safe to use. So in assembly code glibc should only use pac-ret if the compiler uses it too. Unfortunately there is no predefined feature macro for it set by the compiler so pac-ret is inferred from the code generation. Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org> commit 52733817c888141129929df79dad7704ed44e335 Author: Szabolcs Nagy <szabolcs.nagy@arm.com> Date: Tue Jun 30 11:12:40 2020 +0100 aarch64: ensure objects are BTI compatible When glibc is built with branch protection (i.e. with a gcc configured with --enable-standard-branch-protection), all glibc binaries should be BTI compatible and marked as such. It is easy to link BTI incompatible objects by accident and this is silent currently which is usually not the expectation, so this is changed into a link error. (There is no linker flag for failing on BTI incompatible inputs so all warnings are turned into fatal errors outside the test system when building glibc with branch protection.) Unfortunately, outlined atomic functions are not BTI compatible in libgcc (PR libgcc/96001), so to build glibc with current gcc use 'CC=gcc -mno-outline-atomics', this should be fixed in libgcc soon and then glibc can be built and tested without such workarounds. commit 582f1a25ace0bffb2e8fbec9a85d3fcaf55b84e5 Author: Sudakshina Das <sudi.das@arm.com> Date: Mon Jun 22 10:57:20 2020 +0100 aarch64: enable BTI at runtime Binaries can opt-in to using BTI via an ELF object file marking. The dynamic linker has to then mprotect the executable segments with PROT_BTI. In case of static linked executables or in case of the dynamic linker itself, PROT_BTI protection is done by the operating system. On AArch64 glibc uses PT_GNU_PROPERTY instead of PT_NOTE to check the properties of a binary because PT_NOTE can be unreliable with old linkers (old linkers just append the notes of input objects together and add them to the output without checking them for consistency which means multiple incompatible GNU property notes can be present in PT_NOTE). BTI property is handled in the loader even if glibc is not built with BTI support, so in theory user code can be BTI protected independently of glibc. In practice though user binaries are not marked with the BTI property if glibc has no support because the static linked libc objects (crt files, libc_nonshared.a) are unmarked. This patch relies on Linux userspace API that is not yet in a linux release but in v5.8-rc1 so scheduled to be in Linux 5.8. Co-authored-by: Szabolcs Nagy <szabolcs.nagy@arm.com> commit 09ea243d4b4a9f1d644e6445fcdd27185c78e44d Author: Szabolcs Nagy <szabolcs.nagy@arm.com> Date: Mon Jun 22 10:56:38 2020 +0100 rtld: Clean up PT_NOTE and add PT_GNU_PROPERTY handling Add generic code to handle PT_GNU_PROPERTY notes. Invalid content is ignored, _dl_process_pt_gnu_property is always called after PT_LOAD segments are mapped and it has no failure modes. Currently only one NT_GNU_PROPERTY_TYPE_0 note is handled, which contains target specific properties: the _dl_process_gnu_property hook is called for each property. The old _dl_process_pt_note and _rtld_process_pt_note differ in how the program header is read. The old _dl_process_pt_note is called before PT_LOAD segments are mapped and _rtld_process_pt_note is called after PT_LOAD segments are mapped. The old _rtld_process_pt_note is removed and _dl_process_pt_note is always called after PT_LOAD segments are mapped and now it has no failure modes. The program headers are scanned backwards so that PT_NOTE can be skipped if PT_GNU_PROPERTY exists. Co-Authored-By: H.J. Lu <hjl.tools@gmail.com> commit 4b3b0a983285237dbe9cce7a45f722b66a507c1d Author: Szabolcs Nagy <szabolcs.nagy@arm.com> Date: Tue Mar 31 17:32:14 2020 +0100 aarch64: fix RTLD_START for BTI Tailcalls must use x16 or x17 for the indirect branch instruction to be compatible with code that uses BTI c at function entries. (Other forms of indirect branches can only land on BTI j.) Also added a BTI c at the ELF entry point of rtld, this is not strictly necessary since the kernel does not use indirect branch to get there, but it seems safest once building glibc itself with BTI is supported. Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org> commit 83b93efe96bd800d3866ac3c79a91f822999ea03 Author: Szabolcs Nagy <szabolcs.nagy@arm.com> Date: Wed Apr 1 10:31:41 2020 +0100 aarch64: fix swapcontext for BTI setcontext returns to the specified context via an indirect jump, so there should be a BTI j. In case of getcontext (and all other returns_twice functions) the compiler adds BTI j at the call site, but swapcontext is a normal c call that is currently not handled specially by the compiler. So we change swapcontext such that the saved context returns to a local address that has BTI j and then swapcontext returns to the caller via a normal RET. For this we save the original return address in the slot for x1 of the context because x1 need not be preserved by swapcontext but it is restored when the context saved by swapcontext is resumed. The alternative fix (which is done on x86) would make swapcontext special in the compiler so BTI j is emitted at call sites, on x86 there is an indirect_return attribute for this, on AArch64 we would have to use returns_twice. It was decided against because such fix may need user code updates: the attribute has to be added when swapcontext is called via a function pointer and it breaks always_inline functions with swapcontext. Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org> commit f26c70e602b52dd05f167c93f44e8efbceac7fb9 Author: Sudakshina Das <sudi.das@arm.com> Date: Tue Mar 17 15:44:18 2020 +0000 aarch64: Add BTI support to assembly files To enable building glibc with branch protection, assembly code needs BTI landing pads and ELF object file markings in the form of a GNU property note. The landing pads are unconditionally added to all functions that may be indirectly called. When the code segment is not mapped with PROT_BTI these instructions are nops. They are kept in the code when BTI is not supported so that the layout of performance critical code is unchanged across configurations. The GNU property notes are only added when there is support for BTI in the toolchain, because old binutils does not handle the notes right. (Does not know how to merge them nor to put them in PT_GNU_PROPERTY segment instead of PT_NOTE, and some versions of binutils emit warnings about the unknown GNU property. In such cases the produced libc binaries would not have valid ELF marking so BTI would not be enabled.) Note: functions using ENTRY or ENTRY_ALIGN now start with an additional BTI c, so alignment of the following code changes, but ENTRY_ALIGN_AND_PAD was fixed so there is no change to the existing code layout. Some string functions may need to be tuned for optimal performance after this commit. Co-authored-by: Szabolcs Nagy <szabolcs.nagy@arm.com> Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org> commit 81a0ed9464d3f7f9cb444ed1f76475f3004a01f8 Author: Szabolcs Nagy <szabolcs.nagy@arm.com> Date: Wed Apr 1 09:52:37 2020 +0100 aarch64: Rename place holder .S files to .c The compiler can add required elf markings based on CFLAGS but the assembler cannot, so using C code for empty files creates less of a maintenance problem. Reviewed-by: Adhemerval Zanella <adhemerval.zanella@linaro.org> commit 3492d7d40821a9375baae96d053d3791f30d83f8 Author: Szabolcs Nagy <szabolcs.nagy@arm.com> Date: Wed May 6 20:22:16 2020 +0100 aarch64: configure test for BTI support Check BTI support in the compiler and linker. The check also requires READELF that understands the BTI GNU property note. It is expected to succeed with gcc >=gcc-9 configured with --enable-standard-branch-protection and binutils >=binutils-2.33. Note: passing -mbranch-protection=bti in CFLAGS when building glibc may not be enough to get a glibc that supports BTI because crtbegin* and crtend* provided by the compiler needs to be BTI compatible too. commit 0f47f6f311594ec1ea44526e20e5f9986fa5a6ba Author: Szabolcs Nagy <szabolcs.nagy@arm.com> Date: Wed Apr 1 16:02:03 2020 +0100 Rewrite abi-note.S in C. Using C code allows the compiler to add target specific object file markings based on CFLAGS. The arm specific abi-note.S is removed and similar object file fix up will be avoided on AArch64 with standard branch protection.
reply other threads:[~2020-07-02 8:38 UTC|newest] Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=20200702083808.191293860C3A@sourceware.org \ --to=nsz@sourceware.org \ --cc=glibc-cvs@sourceware.org \ /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 a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).