| 1 |
Dnia 2014-01-09, o godz. 17:06:52 |
| 2 |
"Anthony G. Basile" <blueness@g.o> napisał(a): |
| 3 |
|
| 4 |
> On 01/09/2014 04:57 PM, Pacho Ramos wrote: |
| 5 |
> > What are the advantages of disabling SSP to deserve that "special" |
| 6 |
> > handling via USE flag or easily disabling it appending the flag? |
| 7 |
> |
| 8 |
> There are some cases where ssp could break things. I know of once case |
| 9 |
> right now, but its somewhat exotic. Also, sometimes we *want* to break |
| 10 |
> things for testing. I'm thinking here of instance where we want to test |
| 11 |
> a pax hardened kernel to see if it catches abuses of memory which would |
| 12 |
> otherwise be caught by executables emitted from a hardened toolchain. |
| 13 |
> Take a look at the app-admin/paxtest suite. |
| 14 |
|
| 15 |
Just to be clear, are we talking about potential system-wide breakage |
| 16 |
or single, specific packages being broken by SSP? In other words, are |
| 17 |
there cases when people will really want to disable SSP completely? |
| 18 |
|
| 19 |
Unless I'm misunderstanding something, your examples sound like you |
| 20 |
just want -fno-stack-protector per-package. I don't really think you |
| 21 |
actually want to rebuild whole gcc just to do some testing on a single |
| 22 |
package... |
| 23 |
|
| 24 |
-- |
| 25 |
Best regards, |
| 26 |
Michał Górny |
Archives