Closed feynmanliang closed 2 months ago
I believe this is coming from XLA, there may not be much we can do here.
I took a quick look and this is indeed coming from the underlying XLA library, and it is something we cannot address, as we provide bindings to it. execstack
and similar will be necessary then, thank you.
The linked article suggests adding -Wl,-z,noexecstack
to LDFLAGS, to disable execstack regardless of linked libraries flags. Perhaps it would help if we added it to EXLA Makefile?
I was assuming if this was enabled, it was by a particular reason? It doesn't seem to be enabled in other NIFs by default.
Yeah, that's what I'm not sure about, but
As the name suggests, this error is raised if a program tries to make its stack (or parts thereof) executable with an mprotect call. This should never, ever be necessary. Stack memory is not executable on most OSes these days and this won't change. Executable stack memory is one of the biggest security problems. An execstack error might in fact be most likely raised by malicious code.
Doesn't look like we should be enabling this flag. If it's just a matter of enabling it in libexla.so, then it should be as simple as setting the flags before mix compile
@feynmanliang which exla version do you use, and what's your architecture? I checked the binary from xla_extension-0.8.0-x86_64-linux-gnu-cpu.tar.gz
(release) with execstack -q
and it does not seem to require executable stack.
Hey sorry for dropping off here, I've open sourced the project where this is occurring: https://github.com/fmops/decisionbox
https://github.com/fmops/decisionbox/blame/main/README.md#L85-L88 is specifically for this issue
Seems like we are running into https://danwalsh.livejournal.com/38736.html
Tentative solution: