Question on current status of performance & security tuning

[Alain De Vos]

Performance:
I disabled gold in the compiler & lto.
When i enable lto &gold, will this significantly improve speed of loading of libraries?, can i expect issues ? Or do i just leave gold & lto disabled ?

Security:
I have set in sysctl.conf:

#aslr
kern.elf64.aslr.enable=1
kern.elf32.aslr.enable=1
#aslrpie
kern.elf64.aslr.pie_enable=1
kern.elf32.aslr.pie_enable=1
#non-executable-stack
kern.elf64.nxstack=1
kern.elf32.nxstack=1
#Stackgap
kern.elf64.aslr.stack_gap=0 #Needed for firefox
kern.elf32.aslr.stack_gap=100
#WX
kern.elf64.allow_wx=0
kern.elf32.allow_wx=0

Can i expect issues ?

 

[a6h]

kern.elf64.allow_wx=0
kern.elf32.allow_wx=0

Because I'm not sure about those two, I'll ask a follow-up question -- the documentation is rather vague:

Enabling W^X for a process implies that whenever a process uses mmap(2) and mprotect(2), to write and execute on a page, it should get killed. On the other hand, as so far, there's no wxallowed option in the FreeBSD mount(8). The question is whether or not the FreeBSD enforce the W^X accross all mounted filesystems strictly? If so, how do you exempt a filesystem from a mandatory W^X, in order to let an incompatible process pass through, i.e. a process that needs both write and execute access on a page? Because there's no *wxallowed* option, I guess it is not the case, it is not an issue. But I'm not sure. I hope somebody knows how it works and help me on this. Thanks.

 

[Alain De Vos]

I had to enable "kern.elf64.allow_wx=1" otherwise the ocaml compiler spits out errors.
It would be interesting to have a list of packages which require it and which don't.

 

[a6h]

It would be interesting to have a list of packages which require it and which don't.

W^X is around since who knows, two decades? It prevents mapping of writeable and executable -- in some(?) area of the memory, at the same time. It is not clear to me which part of FreeBSD mapping is W^X enabled, but if enabling W^X causes a program to crash, or system goes to panic -- depend on how the kernel handles the situation, it means the program is violating W^X somewhere, e.g. stack, heap, rodata, bss, or even in ELF header. It's a problem and should reported back to the upstream to fix that. It is not up to the port maintainer to fix it.

 

[Alain De Vos]

I've had some issues even in compiling gcc.

 

[a6h]

I think It's the linker problem. You can use the -z execstack option -- which belongs to the ld(1), to link that single program. But it makes the main stack executable, which defeats the whole purpose.