Recent

Author Topic: [Solved]Buffer overflows  (Read 4051 times)

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 12255
  • FPC developer.
Re: Buffer overflows
« Reply #60 on: September 28, 2024, 01:53:23 pm »
Warning: rambling thoughts ahead:

Now if you could just fence off that unsafeness such that user code could benefit from the "magic" in the GC, RC or other low-level management units without themselves doing something unsafe, you'd be getting somewhere.

Actually when I had discussions with Benjamin K about M10 this came up. Somehow confining low level tricks to certain modules, and back then I was sold on it. The idea of the unsafe/safe module separation is to confine the unsafe gore to the unsafe modules, maintained in a different way from the safe more business like code.

However later when I met an old college friend that I used to discuss language design with, and he questioned if safe code that calls unsafe code with high granularity all the time is really that safe. 

Can you actually enforce enough of a separation, and stronger, does it really matter? In cases where safety is really important (like e.g. if you run as a plugin in a shared services webserver), Java and C# often don't allow calling unsafe code either. The VM itself is of course unsafe, but that is vendor supported.

So one could argue a safe/unsafe separation within one codebase is a bit pointless from the practical use viewpoint.

As it was quite irrelevant for me(my work programs can be described as machine firmwares rather than applications), I never did much with that thought.
« Last Edit: September 28, 2024, 03:13:21 pm by marcov »

MarkMLl

  • Hero Member
  • *****
  • Posts: 8413
Re: Buffer overflows
« Reply #61 on: September 29, 2024, 09:57:11 am »
Can you actually enforce enough of a separation, and stronger, does it really matter? In cases where safety is really important (like e.g. if you run as a plugin in a shared services webserver), Java and C# often don't allow calling unsafe code either. The VM itself is of course unsafe, but that is vendor supported.

Obviously my suggestion was influenced by having that distinction in Modula-3 (I /think/ it was 3, post-Wirth but apparently viewed favourably by him). I would suggest that in principle at least you could identify the language features which allowed "proven" code to be abused, i.e. including not just pointer arithmetic but "absolute" and so on.

There was at one point a "Spayed Pascal" (almost invariable mis-spelled and capitalised as SPADE for reasons that elude me), but I believe that it was intended as a language subset rather than as enforcing a tainting mechanism.

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Logitech, TopSpeed & FTL Modula-2 on bare metal (Z80, '286 protected mode).
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

 

TinyPortal © 2005-2018