[Oberon] Oberon for a C++ user.
Srinivas Nayak
sinu.nayak2001 at gmail.com
Thu Sep 29 08:27:23 CEST 2016
Dear Wojtek,
> This discussion may have some relevance to the previous thread why is module unloading unsafe under Oberon. Perhaps reference counting, as they use in python, could offer some relief. Perhaps one can somehow extend their concept of reference counting to Oberon procedure variables to make them into counted references. Module unloading would be disallowed as long as the there are references pointing to it. It is just an idea which perhaps was already examined in the Oberon community.
I see, in Oberon systems, we are not able to unload a module when it is used by others.
System.ShowModules or similar command shows some kind of reference count attached to modules.
Do you mean, this is not sufficient for security problem that you mentioned?
With thanks and best regards,
Yours sincerely,
Srinivas Nayak
Home: http://www.mathmeth.com/sn/
Blog: http://srinivas-nayak.blogspot.in/
On 09/29/2016 03:06 AM, Skulski, Wojciech wrote:
> Lars:
>> By procedure variables do you mean a variable that can be assigned with a
>> procedure type? just want to clarify what exactly they are.. i.e. in
>> freepascal one can make a type, that is a procedure(someparameters), and
>> then declare a variable of that type.
>
> Yes. Basically, the procedure variable is a pointer to the entry point of some code. What makes the pointers into variables is the static type checking performed by the compiler. Once this test is passed during compilation, the code is generated that makes the assignment. Then at run time the code is executed. Now you have a pointer to some procedure which is in a module somewhere in the computer memory. This is OK, unless you unload that module. The pointer becomes dangling. If you call the procedure via that pointer, you will start execution of some memory sequence which may not be valid anymore.
>
> In BlackBox they partly remedied the problem by not unloading the modules. Upon unloading, the unloaded module becomes a "zombie" locked in memory and can no longer be called with usual BlackBox means. But it stays in memory, in case you have some procedure variables somewhere. If you use them, you will then execute the zombi code. The BlackBox designers thought it is better to execute the zombi code rather than let the processor execute some completely random string of bytes.
>
> The security risk is that you can assign the procedure to the variable, and then unload the code. As you see from this discussion, this problem has not been solved yet.
>
> Wojtek
> --
> Oberon at lists.inf.ethz.ch mailing list for ETH Oberon and related systems
> https://lists.inf.ethz.ch/mailman/listinfo/oberon
>
More information about the Oberon
mailing list