[Openmcl-devel] freshly built wx86cl64.exe crashes on start
mc at media.mit.edu
Fri Jan 6 22:13:28 PST 2023
Most CCL code is relocatable, but there are resources, including tables
and low-level code, that /must/ be at fixed locations in low memory.
Matt Emerson is right on this point. There is little to debate here.
I believe the ASLR feature can be disabled on a per-executable basis.
This way most of the apps can stay secure from malware while at the same
time supporting allowing legacy code to run on newer Microsoft operating
systems, unmodified. I don't know if ASLR can be disabled using an
environment variable or file properties or whether you have to call a
routine at startup. This is well worth researching.
On 1/6/23 7:44 PM, Bharat Shetty wrote:
> If someone can run ccl with these settings disabled
> * Mandatory ASLR (force randomisation for images - force relocation
> of images not compiled with Bottom-up ASLR )
> * Randomise memory allocation (Bottom-up ASLR)
> * High Entropy ASLR
> You should be able to run ccl for some more time on windows 10.
> Unfortunately I cannot meddle with these currently in my setup. But
> then it is just a matter of time before these behaviours may change.
> More and more the anti virus and anti malware software are insisting
> you enable these.
> There are multiple things involved here but the main thing is we can
> longer assume fixed locations for various sections. The code will have
> to be made relocatable. Besides this we have to investigate and ensure
> there are no issues related to (improper usage of) executable stack,
> making heap executable using malloc/brk/sbrk. ccl does not seem to do
> this. However I do not understand the ccl code fully to be sure
> there are no more issues.
> On Sat, Jan 7, 2023 at 3:51 AM R. Matthew Emerson <rme at acm.org> wrote:
> > On Jan 6, 2023, at 2:01 PM, Bharat Shetty <bshetty at gmail.com> wrote:
> > Is there some place we can get more details on the start up
> code/low address stuff in lisp-kernel, LAP, level-0 etc.? The info
> in the current and old ccl manual at trac is bit high level.
> I think it would be best to figure out how to tell Windows to stop
> applying its disruptive protection settings rather than expend a
> lot of effort researching and possibly making a big CCL change
> that will, at best, result in the status quo but slightly worse.
> I think it’s reasonable for a process to want to have control over
> its address space. I would be surprised if Windows stops allowing
> > On Thu, Jan 5, 2023 at 2:03 PM Bharat Shetty <bshetty at gmail.com>
> > Unfortunately yes in low memory for now. But as I pointed
> earlier there might be issues with heap locations as well (windows
> handling FTH).
> > Regards,
> > Bharat
> > On Thu, Jan 5, 2023 at 5:27 AM R. Matthew Emerson <rme at acm.org>
> > > On Jan 4, 2023, at 3:15 PM, Bharat Shetty <bshetty at gmail.com>
> > >
> > > Since two days wx86cl64.exe has been behaving erratically
> (both the version i downloaded and built using gccv4.7.1) it has
> been crashing randomly at startup and emacs is unable to start it
> with slime. I suspect this might be to do with some security
> patches installed.
> > >
> > > So I looked into the windows security controls. Turns out
> windows defender lets us configure "exploit protection setting" by
> configuring the following parameters
> > > •
> > > control flow guard CFG
> > > • Data Execution Prevention DEP
> > > • Mandatory ASLR (force randomisation for images - force
> relocation of images not compiled with Bottom-up ASLR ) -- off by
> default for now
> > > • Randomise memory allocation (Bottom-up ASLR) -- on by
> > > • High Entropy ASLR - needs Bottom-up ASLR to be ON
> > > • validate execution chains (SEHOP)
> > > • validate heap integrity - terminate process when heap
> corruption os detected
> > >
> > > I observed we can get wxcl8664 to run with 'Mandatory ASLR'
> and 'High Entropy ASLR' turned off and with all other options
> enabled. So even if gcc were to enable us to build non PIE
> position independant executable, it is just a matter of time
> before no-pie apps and ccl stops running on windows.
> > >
> > > The only way we can keep ccl running is making the code
> relocatable (PIE) at the earliest. The bright spot is it still
> runs on linux :)
> > The x86 port of CCL uses absolute addresses to reference code
> and other data in low memory. Is this what the problem is?
> > Changing that would be a big hassle.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Openmcl-devel