I had been running an old kernel (5.6.6) in order to be able to use ved as
my main editor. It works in both 32bit and 64bit poplog.
I wondered what would happen if I tried to run the old 32bit poplog in the
latest (5.8) kernel. So I have just rebooted into fedora32 with kernel
5.8.11-200.fc32.x86_64
and tried running both 32 bit and 64 bit poplog.
The result seems to confirm Waldek's hypothesis about what's going on:
Neither new nor old poplog will run: I just get a stream of error messages.
;;; MISHAP - ste: STACK EMPTY (missing argument? missing result?)
(the first error message goes off the screen too fast, so I don't know
how it starts).
So, for now, I shall have to go back to running the old kernel.
I wrote:
> > I am assuming that only a new compilation process is needed, not changes to
> > the sources -- otherwise the new kernel would make all sorts of programs
> > unusable and I am sure they must have tested a large number successfully
> > before releasing version 8.
Waldek replied, correctly it seems:
> Almost surely the opposite: one needs to modify sources. All
> evidence indicates that Poplog is trying to execute memory
> marked as nonexecutable by kernel. This may be Selinux style
> thing (for example part of Selinux may be always on, regardless
> of user settings). This also may be some silly bug in Poplog
> like forgetting 'mprotect' call somewhere or even mess with
> using pop versus non-pop variables in system sources.
> Another possibility is alignment bug, I hoped that all are
> fixed now, but if some remains it could produce rather
> weird errors.
>
> Concerning Selinux things: security folks want memory to
> be writable or executable but not both at the same time.
> Poplog produces machine code and may use freshly generated
> code to produce more code: clearly this is contrary to
> what security folks want. Basically, security folks
> treat memory that is written to and then immediately
> after that executed as sign of malware. Legitimate
> programs are supposed to use 'mprotect' call to inform
> kernel that this is legitimate. But current Selinux
> ignores some 'mprotect' calls. In principle one could
> change Poplog to work with current Selinux as follows:
>
> - first use 'mprotect' to make a piece of memory writable
> but non-executable
> - generate code
> - use 'mprotect' to make memory non-writable and executable
>
> In Poplog safe way would be to generate code in writable
> buffer, then mark final destination as writable but non-executable,
> copy and finally turn it back to executable but non-writable.
>
> That would be some work, in particular finding all places where
> this is neccessary (for example garbage collector would have to
> do the same thing). And due to extra system calls and copies
> Poplog would be slower (I do not know how much).
>
> Concerning other programs, there are not so many programs that
> generate code at runtime. There is GNU C extention allowing
> local functions, it used to generate code on the stack but
> apparently now is implemented in different way. What remains
> is dynamic linker, Java, various Lisp-s, ML-s etc. Most
> probably use use several 'mprotect' calls and copy to
> add new code.
>
> --
> Waldek Hebisch
I wonder if this is fixable, or whether the new kernel changes make poplog
unusable.
If a new test version of poplog becomes available I would be willing to try
it, but I don't think I can do anything to help identify the details of
the problem.
I presume Linus Torvalds, or whoever has made this change would
not be willing to provide a mechanism to enable self-modifying code, like
Poplog's to be run.
I wonder if there are any other systems that have been made unusable.
Aaron
