<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
Hi Bharat,<br>
<br>
Most CCL code is relocatable, but there are resources, including
tables and low-level code, that <i>must</i> be at fixed locations
in low memory. Matt Emerson is right on this point. There is little
to debate here. <br>
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.<br>
<br>
--Tim<br>
<br>
<div class="moz-cite-prefix">On 1/6/23 7:44 PM, Bharat Shetty wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CA+6VBw45YBDmsH1H4vGHfvp74SpcnRWY4DJCf+mSH=wcPjzg7w@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">If someone can run ccl with these settings disabled
<div>
<ul>
<li><span style="color:rgb(80,0,80)">Mandatory ASLR (force
randomisation for images - force relocation of images
not compiled with Bottom-up ASLR ) </span></li>
<li><span style="color:rgb(80,0,80)">Randomise memory
allocation (Bottom-up ASLR) </span></li>
<li><span style="color:rgb(80,0,80)">High Entropy ASLR</span></li>
</ul>
<div><font color="#500050">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. </font></div>
</div>
<div><font color="#500050"><br>
</font></div>
<div><font color="#500050">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.</font></div>
<div><font color="#500050"><br>
</font></div>
<div><font color="#500050">Regards,</font></div>
<div><font color="#500050">Bharat</font></div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Sat, Jan 7, 2023 at 3:51 AM
R. Matthew Emerson <<a href="mailto:rme@acm.org"
moz-do-not-send="true" class="moz-txt-link-freetext">rme@acm.org</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
<br>
> On Jan 6, 2023, at 2:01 PM, Bharat Shetty <<a
href="mailto:bshetty@gmail.com" target="_blank"
moz-do-not-send="true" class="moz-txt-link-freetext">bshetty@gmail.com</a>>
wrote:<br>
> <br>
> 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.<br>
<br>
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.<br>
<br>
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.<br>
<br>
<br>
> On Thu, Jan 5, 2023 at 2:03 PM Bharat Shetty <<a
href="mailto:bshetty@gmail.com" target="_blank"
moz-do-not-send="true" class="moz-txt-link-freetext">bshetty@gmail.com</a>>
wrote:<br>
> Unfortunately yes in low memory for now. But as I pointed
earlier there might be issues with heap locations as well
(windows handling FTH).<br>
> <br>
> Regards,<br>
> Bharat<br>
> <br>
> On Thu, Jan 5, 2023 at 5:27 AM R. Matthew Emerson <<a
href="mailto:rme@acm.org" target="_blank"
moz-do-not-send="true" class="moz-txt-link-freetext">rme@acm.org</a>>
wrote:<br>
> <br>
> <br>
> > On Jan 4, 2023, at 3:15 PM, Bharat Shetty <<a
href="mailto:bshetty@gmail.com" target="_blank"
moz-do-not-send="true" class="moz-txt-link-freetext">bshetty@gmail.com</a>>
wrote:<br>
> > <br>
> > 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. <br>
> > <br>
> > So I looked into the windows security controls.
Turns out windows defender lets us configure "exploit
protection setting" by configuring the following parameters<br>
> > • <br>
> > control flow guard CFG<br>
> > • Data Execution Prevention DEP<br>
> > • Mandatory ASLR (force randomisation for images
- force relocation of images not compiled with Bottom-up ASLR
) -- off by default for now<br>
> > • Randomise memory allocation (Bottom-up ASLR)
-- on by default<br>
> > • High Entropy ASLR - needs Bottom-up ASLR to be
ON<br>
> > • validate execution chains (SEHOP)<br>
> > • validate heap integrity - terminate process
when heap corruption os detected<br>
> > <br>
> > 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. <br>
> > <br>
> > 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 :) <br>
> <br>
> The x86 port of CCL uses absolute addresses to reference
code and other data in low memory. Is this what the problem
is?<br>
> <br>
> Changing that would be a big hassle.<br>
> <br>
<br>
</blockquote>
</div>
</blockquote>
<br>
</body>
</html>