Tail Call Optimization Troubles Ahead?
This sounds potentially troubling for Lisp languages and tail call optimization / continuations:- David McClain
Refined Audiometrics Laboratory, LLC
I'm a little concerned about it, in that it might make it much harder to inter-operate between more dynamic languages (such as Lisp) and more static ones (such as C). It's all very well turning it off in Lisp world, but how are we supposed to build a shared library that can be called from C? These days I work (in C) in low-level tools development for HPC Linux clusters. This technology will stop us from doing some things when it's turned on (such as correctly wrapping a dlopen() call in an LD_PRELOAD library, details on request), so there's widespread interest tempered with a certain level of scepticism that people will ever turn it on. Nick B On 15 Jun 2020, at 14:31, Michał "phoe" Herda wrote: >> CET introduces changes in the CPU that create a new stack called the >> control stack. This stack can’t be modified by attackers and >> doesn’t >> store any data. It stores the return addresses of the Lego bricks >> that >> are already in the stack. Because of this, even if an attacker has >> corrupted a return address in the data stack, the control stack >> retains the correct return address. The processor can detect this and >> halt execution. > I assume that compilers will need to use that feature explicitly in > order to benefit from that, meaning that they will need to opt in for > using the new immutable control stack for their returns. > > This is because I think that the last thing Intel wants is breaking > backwards compatibility with already existing and working software > that > uses mutable stacks (which is, like, 99% of contemporary x86 > software?), > since breaking backwards compatibility like that would be an endless > source of bug reports for them. x86_64 is famous for being backwards > compatible with 16-bit DOS, after all. > > So, to use Betteridge's law of headlines: no, I don't think it'll be > much of an issue. > > ~phoe > > On 15.06.2020 15:21, dbm@refined-audiometrics.com wrote: >> This sounds potentially troubling for Lisp languages and tail call >> optimization / continuations: >> >> https://arstechnica.com/information-technology/2020/06/intel-will-soon-bake-anti-malware-defenses-directly-into-its-cpus/ >> >> - David McClain >> Refined Audiometrics Laboratory, LLC > > _______________________________________________ > Lisp Hug - the mailing list for LispWorks users > lisp-hug@lispworks.com > http://www.lispworks.com/support/lisp-hug.html _______________________________________________ Lisp Hug - the mailing list for LispWorks users lisp-hug@lispworks.com http://www.lispworks.com/support/lisp-hug.html
Correct, it will be difficult in a place where we need to add FFI into the mix; I would imagine that such kind of mitigation would need to be taken into account either when linking against code that is compiled with such stacks, unless the OS finds out a way to enable such mitigations for whole individual processes. (That said, and going slightly off-topic, I imagine that some paranoia-oriented operating systems, such as OpenBSD, will be the first to compile and run everything they can with such a technology enabled.) UNIX and Lisp are two completely distinct worlds, and I imagine that such a mitigation technique would be most useful for the former, memory-unsafe world. But then again, I'll share an optimistic point of view; in case this technology is deployed, I imagine that Lisp won't be the only dynamic language that will need to figure out a way of linking dynamic code against static code with a separate, immutable control stack. If Python and Ruby find a way, so will Lisp. ~phoe On 15.06.2020 16:13, Nick Barnes wrote: > I'm a little concerned about it, in that it might make it much harder > to inter-operate between more dynamic languages (such as Lisp) and > more static ones (such as C). It's all very well turning it off in > Lisp world, but how are we supposed to build a shared library that can > be called from C? > > These days I work (in C) in low-level tools development for HPC Linux > clusters. This technology will stop us from doing some things when > it's turned on (such as correctly wrapping a dlopen() call in an > LD_PRELOAD library, details on request), so there's widespread > interest tempered with a certain level of scepticism that people will > ever turn it on. > > Nick B > > On 15 Jun 2020, at 14:31, Michał "phoe" Herda wrote: > >>> CET introduces changes in the CPU that create a new stack called the >>> control stack. This stack can’t be modified by attackers and doesn’t >>> store any data. It stores the return addresses of the Lego bricks that >>> are already in the stack. Because of this, even if an attacker has >>> corrupted a return address in the data stack, the control stack >>> retains the correct return address. The processor can detect this and >>> halt execution. >> I assume that compilers will need to use that feature explicitly in >> order to benefit from that, meaning that they will need to opt in for >> using the new immutable control stack for their returns. >> >> This is because I think that the last thing Intel wants is breaking >> backwards compatibility with already existing and working software that >> uses mutable stacks (which is, like, 99% of contemporary x86 software?), >> since breaking backwards compatibility like that would be an endless >> source of bug reports for them. x86_64 is famous for being backwards >> compatible with 16-bit DOS, after all. >> >> So, to use Betteridge's law of headlines: no, I don't think it'll be >> much of an issue. >> >> ~phoe >> >> On 15.06.2020 15:21, dbm@refined-audiometrics.com wrote: >>> This sounds potentially troubling for Lisp languages and tail call >>> optimization / continuations: >>> >>> https://arstechnica.com/information-technology/2020/06/intel-will-soon-bake-anti-malware-defenses-directly-into-its-cpus/ >>> >>> >>> - David McClain >>> Refined Audiometrics Laboratory, LLC >> >> _______________________________________________ >> Lisp Hug - the mailing list for LispWorks users >> lisp-hug@lispworks.com >> http://www.lispworks.com/support/lisp-hug.html _______________________________________________ Lisp Hug - the mailing list for LispWorks users lisp-hug@lispworks.com http://www.lispworks.com/support/lisp-hug.html