| 1 |
2017-05-02 19:23 GMT+02:00 "Tóth Attila" <atoth@××××××××××.hu>: |
| 2 |
> 2017.Május 2.(K) 18:59 időpontban Daniel Cegiełka ezt írta: |
| 3 |
>>> pax.?mark actually, since the eclass helper is called pax-mark. :) |
| 4 |
>>> I'd hold off on removing those for at least a few months, though. |
| 5 |
>>> |
| 6 |
>> |
| 7 |
>> If PAX_MPROTECT returns (KSPP?), then ebuilds will need to be |
| 8 |
>> 'paxmarked' again. Years of work and PaX support ends in the trash. |
| 9 |
> |
| 10 |
> I must aggree here. If there will be an alternative implementation marking |
| 11 |
> may regain its meaning. The same binaries need to be marked in some way or |
| 12 |
> another. I wouldn't simply dump it unless it would disturb some |
| 13 |
> functionality. |
| 14 |
|
| 15 |
Even if PAX_MPROTECT somehow comes back to the kernel, there is no |
| 16 |
guarantee that it will be compatible with current PaX ELF header |
| 17 |
(elf_phdata->p_flags & PF_MPROTECT) or PAX_XATTR_FLAGS |
| 18 |
(PAX_MPROTECT==0x04000000). Next, the PaX functionality are added to |
| 19 |
the kernel gradually: one functionality per patch (eg. PAX_USERCOPY -> |
| 20 |
HARDEN_USERCOPY). This means that any future solution will not be |
| 21 |
compatible with current PaX support. Again: years of work and PaX |
| 22 |
support ends in the trash. |
Archives