Changeset e502de1
- Timestamp:
- 09/11/2022 03:35:06 AM (20 months ago)
- Branches:
- 11.3, 11.3-rc1, 12.0, 12.0-rc1, 12.1, 12.1-rc1, bdubbs/gcc13, multilib, renodr/libudev-from-systemd, trunk, xry111/arm64, xry111/arm64-12.0, xry111/clfs-ng, xry111/loongarch, xry111/loongarch-12.0, xry111/loongarch-12.1, xry111/mips64el, xry111/pip3, xry111/rust-wip-20221008, xry111/update-glibc
- Children:
- a710d35
- Parents:
- 8d3b254
- Files:
-
- 2 edited
Legend:
- Unmodified
- Added
- Removed
-
chapter05/gcc-pass1.xml
r8d3b254 re502de1 140 140 <listitem> 141 141 <para>Those switches allow GCC to compile programs with 142 143 the <xref linkend="pie-ssp-info"/> in chapter 8). They are not 144 strictly needed at this stage, since the compiler will only produce 145 temporary executables. But it is cleaner to have the temporary 146 142 some hardening security features (more information on those in 143 the <xref linkend="pie-ssp-info"/> in chapter 8) by default. The 144 are not strictly needed at this stage, since the compiler will 145 only produce temporary executables. But it is cleaner to have the 146 temporary packages be as close as possible to the final ones. 147 147 </para> 148 148 </listitem> -
chapter08/gcc.xml
r8d3b254 re502de1 109 109 <note id="pie-ssp-info" xreflabel="note on PIE and SSP"> 110 110 <para> 111 PIE (position independent executable) is a technique to produce 112 binary programs that can be loaded anywhere in memory. Together 113 with a feature named ASLR (Address Space Layout Randomization), 114 this allows programs to never have the same memory layout, 115 thus defeating attacks based on reproducible memory patterns. 111 PIE (position-independent executable) is a technique to produce 112 binary programs that can be loaded anywhere in memory. Without PIE, 113 the security feature named ASLR (Address Space Layout Randomization) 114 can be applied for the shared libraries, but not the exectutable 115 itself. Enabling PIE allows ASLR for the executables in addition to 116 the shared libraries, and mitigates some attacks based on fixed 117 addresses of sensitive code or data in the executables. 116 118 </para> 117 119 <para> … … 119 121 that the parameter stack is not corrupted. Stack corruption can 120 122 for example alter the return address of a subroutine, 121 which would allow transferring control to an attacker program instead 122 of the original one. 123 which would allow transferring control to some dangerous code 124 (existing in the program or shared libraries, or injected by the 125 attacker somehow) instead of the original one. 123 126 </para> 124 127 </note>
Note:
See TracChangeset
for help on using the changeset viewer.