On Wed, Sep 16, 2020 at 12:39:58AM +0100, Aaron Sloman wrote:
> The thought has occurred to me that perhaps the changes in kernel 5.8 make
> it necessary to go through the standard process of porting poplog to a new
> machine or operating system, namely:
>
> Step 1:
> On a running poplog use a special mode of pop11 to *partly* compile all the
> (core) pop11 sources, modified for a new target machine, to assembler
> files. Presumably the old assembler files will work unchanged on kernel
> 5.8.*
>
> (If not the new kernel would break too many programs?)
>
> Step 2:
> Move the assembler files to the new machine (or in this case the new
> version of linux).
>
> Step 3
> On the new machine or new OS, assemble and link the files to produce a new
> corepop.
>
> Step 4 ++
> Then use that corepop to rebuild everything else, using the current poplog
> installation process.
>
> Waldek, I wonder whether you already have scripts set up to produce a tar
> file with the results of steps 1 and 2?
>
> You could then send me all the assembler files with instructions to build a
> new corepop.
I build in slightly different way: using .o files. In fact,
what is needed are 'pop/obj/src.olb', 'pop/extern/lib/libpop.a'
and various 'pop/pop/poplink_*' files. However, this is unlikely
to help. Chance is similar as buying a ticket and expecting
top prize in national littery.
>
> Alternatively I could run the scripts on a working version of poplog
> (kernel 5.7), then switch to kernel 5.8 and try to finish the compilation
> process (i.e. produce a new corepop).
>
> 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.
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
