<div dir="ltr"><div><div>Arnold Reinhold <<a href="mailto:agr@me.com">agr@me.com</a>> wrote:<br><div id=":pk" class="">
<br>> I started this thread asking what other features Swift should have for 
security. The <br>> two I came up with are a circular shift operator and class
 destructor semantics that<br>> do not equate x=0 with a no-op.  People tell 
me that the latter is platform dependent,<br>> though I am not clear why.<br><br></div><div id=":pk" class="">(It's been said that the fastest way to get an informed answer on the Internet is to<br></div><div id=":pk" class="">

post an uninformed opinion. So maybe someone who actually knows what the problem<br></div><div id=":pk" class="">is will respond if I post this...)<br></div><div id=":pk" class="">
<br>
</div>I think the problem is that there are a lot of OS level operations that can prevent proper<br>sanitization, and which are hard to fix at a language level. OSs have historically been<br>designed to be time-efficient, in ways that conflict with security. <br>

<br></div><div>1. OSs supply memory management services. For efficiency, they generally don't clear<br></div><div>memory when it's returned to the pool, or when reallocated.<br></div><div>2. OSs swap program space to disk and back. Same problem as above.<br>

</div><div>3. Machine level stack operations move the SP up and down, without clearing memory<br>that's been popped off.<br><br></div><div>4. Optimizers will eliminate code which sets a value which is never read.<br>
</div>
<div><br>Generally, programs don't get the option to tell the OS to do otherwise. This would<br>be a nice addition to an OS, but isn't part of the language. It is clearly platform (OS & HW)<br>dependent.<br><br>

</div><div>1 & 2 could be fixed at the OS level, at some cost of memory (for sensitivity flags) and<br></div><div>time (for clearing). 3. would need to be fixed at the microcode or HW level, in instructions<br>that modify the stack. This would get tricky if you want to specify what's sensitive,<br>

and what's not. Tagged memory would make it a lot easier.<br></div><div><br></div><div>Further from the metal, things might be easier for dealing with (4) above. I could <br>imagine a 'sensitive' key word on declarations and mallocs (or your languages' <br>

equivalent) which would tag that entity as one which which must be cleared <br>when it goes out of scope - I think this would be easier than having to explicitly <br>clear it in a destructor.<br><br></div><div>A 'do not optimize' keyword would be difficult to implement, since code so labeled<br>

may call code which doesn't have the keyword, and which should be subject to <br>optimization in most cases. When do you propagate the property down the call<br>tree, and when not?<br><br></div></div><div>Peter Trei<br>

</div><div><div><br><br></div></div></div>