<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><div dir="ltr">But you bring up a good point, Bharat.<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div>In this day and age, it is especially desirable to keep up with the latest security standards to maintain “good standing” in the programming community, or better!</div><div>Compared to languages that sacrifice security for performance, thanks to high standards for data integrity, Lisp is more secure (e.g. it always checks array bounds and passes around type-tagged data, which is constantly verified before use). Just the fact that Lisp is garbage collected is a testament to its trustworthiness. </div><div>If CCL is to survive as more than a legacy platform, <u>perhaps we should</u> give some additional thought to security moving forward. </div><div>The CCL compiler delegates a significant fraction of user code computation to the fixed-location sub-primitives. Calls to these routines need to be maximally fast because they affect the performance of all Lisp code. The “subprims” table and popular constants like T and NIL need (I would argue) to live on page zero. Page zero is typically read-only, which makes them less vulnerable to attack, but there is also another layer of primitives written in Lisp, and I seem to remember, these need to be in fixed locations too. </div><div>At this point my knowledge of the CCL memory structure enters an area unexplored by me. Further analysis might be warranted, but in deference Gary Buyers’ extraordinary CS skills, he likely did an exceptional job at thinking through the CCL memory architecture. I would hesitate to second-guess him without further analysis. Nevertheless a lively, <i>informed</i> discussion on the subject would be fun.</div><div><br><div dir="ltr">--Tim</div><div dir="ltr"><br><blockquote type="cite">On Jan 6, 2023, at 19:44, Bharat Shetty <bshetty@gmail.com> wrote:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr"><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">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">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">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">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">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>
</div></blockquote></div></div></div></div></div></div></body></html>