[Openmcl-devel] freshly built wx86cl64.exe crashes on start

[Tim McNerney]

Hi Bharat,

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.

--Tim

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.
>
> Regards,
> Bharat
>
> 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
>     that.
>
>
>     > On Thu, Jan 5, 2023 at 2:03 PM Bharat Shetty <bshetty at gmail.com>
>     wrote:
>     > 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>
>     wrote:
>     >
>     >
>     > > On Jan 4, 2023, at 3:15 PM, Bharat Shetty <bshetty at gmail.com>
>     wrote:
>     > >
>     > > 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
>     default
>     > >     • 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...
URL: <https://lists.clozure.com/pipermail/openmcl-devel/attachments/20230107/748834d5/attachment.htm>