On Sat, 09 Oct 2021 22:22:45 GMT, Branimir Maksimovic
<branimir.maksimovic@icloud.com> wrote:

>Boehm's collector scans heap/stack/bss, pointing anywhere within
>allocated area, no problem with that.

The problem isn't finding pointers that refer to the heap, the problem
is finding pointers that refer to particular allocated blocks IN the
heap.

And that's one of the places that BDW falls down. (see below)

> ... Boehm's collector works with C. With C++ there are problems
>because of caching scheme in defualt allocator.

BDW has lots of problems - the least of which is the space overhead: a
collected heap needs to be 30+% larger (minimum) than a heap that
isn't collected.

To use BDW effectively, you have to change your programming style, and
you have to actively tell the collector what objects should be
considered "roots", and what objects can be ignored for scanning
because they won't ever contain pointers.

Even with programmer assistance, BDW slows down VERY quickly as the
live data set grows.

Been there, done that.
George

Thomas Koenig wrote:
> Stefan Monnier <monnier@iro.umontreal.ca> schrieb:
>>>>>>> Some programs do need to be able to handle sets of data, in RAM, that are
>>>>>>> too large to fit into 32-bit addressing. There aren't huge numbers of
>>>>>>> them, but they definitely exist.
>> I find this discussion quite surprising. On the one hand, I'm still
>> using the i386 port of Debian on most/all of my machines, so clearly all
>> my applications fit within that 32bit address space, but I'd have expected it's
>> quite common for numerical simulations to need a fair bit more.
>>
>> After all, my Firefox process often gets in the GB range, my Emacs needs
>> at least as much RAM as the size of the files it edits (and log files >4GB
>> aren't that rare), and even smartphones come with 8GB these days.
>>
>> So is it really still rare(ish) to pass the 4GB limit?
>
> Most processes do not pass 4GB, but there are important ones that do.
>
> If you're on a x86, you also have fewer registers in 32-bit mode,
> unless you use the x32 ABI (is that still alive?)
>
> SPARC compilers will give you 32 bit code by default to save
> on code size. If you want to run a cryptographic hash, then
> of course 64 bit is better :-)

One problem for large 64-bit address spaces is that they would like to
take advantage of large (aka huge) page sizes to cut translation cost,
even more so with virtual machine table level translation.
Last time I look it was still clunky.
Automatically breaking huge pages into smaller ones is easy,
reassembling huge pages from smaller ones is not as it is similar to
disk defragmentation and not something you want to do all the time.
So pools of huge pages were set aside at boot time and each page
size recycles within its own pool.

I see references at Hotchips 2016 to AMD Zen supporting something called
"PTE Coalescing" that combines 4K pages into 32K ones.
But I find no reference in the AMD system programming manual dated 2021.

On 10/9/2021 6:48 PM, BGB wrote:
> On 10/9/2021 9:56 AM, Stephen Fuld wrote:
>> On 10/9/2021 12:50 AM, BGB wrote:

snip

>> See, you are conflating protection (UID/GID or ACL) with memory
>> placement (MMU/TLB).  They don't have to be conflated.
>>
>
> OK. Conflating them makes the most sense for the MMU though.

Once you start with the MMU, then "add" protection, you have already
made the decision to conflate them.

There are advantages and disadvantages to putting them together. I just
think one should consider the decision not just default to combining.

In a very general sense, combining them is "simpler", but separating
them gives you more flexibility. So for example, with the separation,
you are not limited to page sizes for the protection domains. I believe
the Mill has protection to the byte level (which has some other
advantages). It also means that large pages don't necessarily mean
large protection domains, so it gives you some flexibility there.

And note that the decision to combine them or not is orthogonal to the
Single/Multiple address space decision (which has its own set of
tradeoffs). I think all four combinations are possible.

--
- Stephen Fuld
(e-mail address disguised to prevent spam)

> And note that the decision to combine them or not is orthogonal to the
> Single/Multiple address space decision (which has its own set of
> tradeoffs). I think all four combinations are possible.

Technically that's true, but of course for an SASOS the mapping table is
global whereas the protection tables are per-process, so it naturally
lends itself to a hardware where the two are decoupled.

Stefan

On Monday, October 11, 2021 at 10:29:20 AM UTC-5, EricP wrote:
> Thomas Koenig wrote:
> > Stefan Monnier <mon...@iro.umontreal.ca> schrieb:
> >>>>>>> Some programs do need to be able to handle sets of data, in RAM, that are
> >>>>>>> too large to fit into 32-bit addressing. There aren't huge numbers of
> >>>>>>> them, but they definitely exist.
> >> I find this discussion quite surprising. On the one hand, I'm still
> >> using the i386 port of Debian on most/all of my machines, so clearly all
> >> my applications fit within that 32bit address space, but I'd have expected it's
> >> quite common for numerical simulations to need a fair bit more.
> >>
> >> After all, my Firefox process often gets in the GB range, my Emacs needs
> >> at least as much RAM as the size of the files it edits (and log files >4GB
> >> aren't that rare), and even smartphones come with 8GB these days.
> >>
> >> So is it really still rare(ish) to pass the 4GB limit?
> >
> > Most processes do not pass 4GB, but there are important ones that do.
> >
> > If you're on a x86, you also have fewer registers in 32-bit mode,
> > unless you use the x32 ABI (is that still alive?)
> >
> > SPARC compilers will give you 32 bit code by default to save
> > on code size. If you want to run a cryptographic hash, then
> > of course 64 bit is better :-)
>
> One problem for large 64-bit address spaces is that they would like to
> take advantage of large (aka huge) page sizes to cut translation cost,
> even more so with virtual machine table level translation.
> Last time I look it was still clunky.
<
My 66000 addressed this: there is a 3-bit Level indicator in each layer
of the translation tables. The 3-bit indicator in the Root pointer determines
the size of the virtual address space {23-bits, 33-bits, 43-bits, 53-bits, 63-bits}
Also, here in the Root pointer, the encoding of 000 indicates PA = VA.
For each successive layer in the hierarchy, the Lvl indicator is monotonically
decreasing and each step that is not -1 skips levels of the table hierarchy.
Thus, the starting point determines the maximum size of the VAS, and
one can skip layers in the middle. Applications like 'cat' can be mapped
with a single page of page table overhead.
<
Large pages use the non translating bits as a [0..limit], so a PTE pointing at a
2^23 byte page, can be given access to a much smaller actual page on a big
page boundary. This should make big pages "more usable".
<
So this is a <more or less> conventional hierarchy, with starting pint
and level skipping designed to make the hierarchy as small* as possible.
(*) low overhead.
<
> Automatically breaking huge pages into smaller ones is easy,
> reassembling huge pages from smaller ones is not as it is similar to
> disk defragmentation and not something you want to do all the time.
> So pools of huge pages were set aside at boot time and each page
> size recycles within its own pool.
>
> I see references at Hotchips 2016 to AMD Zen supporting something called
> "PTE Coalescing" that combines 4K pages into 32K ones.
> But I find no reference in the AMD system programming manual dated 2021.

On Sun, 10 Oct 2021 16:31:21 -0700, Stephen Fuld
<sfuld@alumni.cmu.edu.invalid> wrote:

>I don't think the question of whether 64 bits is adequate (it is), but
>for how long into the future will it be adequate, and secondarily, when
>it does become inadequate, how big a change, hardware and software, will
>be required to deal with it?

When the time comes that one computer can't run all your programs, buy
another one.

Address space won't be a problem until 64 bits is too small for a
/single/ program. "Big data" notwithstanding, I don't expect to see
programs of that size any time in this century.

>Remember, not allowing a large enough address space is considered by
>many to be the biggest mistake in computer architecture. :-(

Yeah, but that problem wasn't multitasking - it was that there were
/single/ programs that needed more address space than was available.

On 10/11/2021 8:14 AM, George Neuner wrote:
> On Sat, 9 Oct 2021 14:28:22 -0700 (PDT), MitchAlsup
> <MitchAlsup@aol.com> wrote:
>
>> Question: in a 64-bit virtual address space, is there ever a reason that
>> the "heap" cannot live in a contiguous subsection of that space so
>> base and bounds could tell if the pointer should be considered for
>> GC (or not)?
>
> I can't think of one offhand. 64 bits gives plenty of space for lots
> of programs to have huge contiguous heaps.
>
> GCs for uncooperative languages (like C) do check potential pointers -
> i.e. properly aligned values - against the heap limits as a first
> step. But what the GC really needs to know is if a pointer refers to
> an actual allocated block. Determining /that/ is a lot harder because
> the value must be range checked against every allocation, not just
> against the heap limits.
>

Yeah, a process for this might be like:
Check that low 2 or 3 bits are 0, typical for heap objects;
Check that the high-bits are sane (somewhere in the user region);
Lookup the top-level heap segment;
Lookup the object within the segment;
Mark object if needed, walk object for more pointers to check.
These can be added to a queue or similar.

> There are various data structures that facilitate interval / range
> searching, but maintaining them is extra overhead in the allocator and
> collector, and potentially is heap space unavailable to the program.
> It's a lot more effective to require that the compiler retain original
> pointers and always work on copies of them.
>

Main structure that works reasonably well here is sorted arrays.
With a sorted array, one can use binary search, so roughly O(log2 n) per
level.

So, say, the top-level heap segments are represented in a sorted array;
Within each segment, any medium-sized objects are represented as another
sorted array;
For small objects, I had typically fallen back to using a range of
"cells" managed by bitmaps (size varies, for C, 16B works well).

This might lead to objects being divided based on size ranges, say:
1MB+, Allocated directly via memory pages (large-object allocator);
4K .. 1MB: Medium object allocator;
Under 4K or so: Cell allocator.

The space for the cell allocator might be based on allocating fixed size
chunks from either the medium or large allocator.

One might spend around 3% or 6% constant overhead on the bitmap, say:
2 bits for cell allocation state;
Say: 00=Free, 01=Obj Data, 10=Object Header, 11=Object (No Header)
2 bits for mark/sweep state;
4 bits for other flags (optional).

The choice of header vs no-header would be based on whether one needs to
store object metadata (such as object type-tagging or similar). For bare
heap allocations, or those using a self-contained type-tagging scheme,
it may make sense to use a no-header object (in some cases, blocks in
the "cell heap" could be themselves divided by type-tag, side-stepping
the need for per-object headers).

Sometimes, it might make sense to have another "tiny allocator" for
objects under 16B or so, typically created by creating a bigger
allocation and dividing it into 8B or 16B pieces (managed via a free-list).

Though, usually it makes more sense to leave this to the program, which
can do this typically with a lower overhead (typically, these would be
things like boxed numbers or cons cells or similar).

While more traditional allocator designs are based around linked lists,
these have a few drawbacks:
High space overhead with 64b pointers;
Writing out-of-bounds compromises overall integrity of the heap;
Lookup requires O(n);
...

So, one ideally wouldn't do a GC with linked lists, as this means a
rough complexity of around O(n^2) for the mark phase, rather than around
O((log2 n)^2), ...

Also, it may makes sense to try to allocate things in terms of a
"microfloat" scheme (say: E5.F3), since this has less issues with
fragmentation than trying to do exact-sized allocations.

One might also use this microfloat format as a key-index for things like
free-lists and similar, and as a more compact way to express the object
size in allocator structures, ...

....

But, yeah, I may have implemented this sort of thing before.

On Sunday, October 10, 2021 at 5:48:01 AM UTC-5, David Brown wrote:

> The idea of C being a "high-level assembler" is right there in section
> 1, "Introduction".
>

There is something about high level assembler in the introduction - it is a QUOTE from the C Rationale. If you honestly
interpreted it as a claim that C was supposed to be a complete replacement for all assembly languages, then maybe you need
new glasses.
> Yes, I exaggerated somewhat, and clearly I was parodying and note

Exactly. You didn't respond to the argument made, you just caricatured it, refuted the
caricature and then congratulated yourself on being so smart.

> quoting. However, that /is/ the impression I got from the paper. I'm
> sorry, but you appear to have some serious misunderstandings about the C
> language, its tools, how it was originally intended to be used, how it
> developed as a language, how its tools developed, and how its use
> developed. The very title, "How ISO C became unusable for operating
> systems development" shows that - C was /never/ intended or designed to
> let you write operating systems purely in standard portable C.

Brilliant! And where did I write that C was designed to let one write operating systems
purely in standard portable C ? Nowhere. That's something you made up by adding
"purely in standard portable C" to what I wrote, changing the meaning completely. Of course some assembler
has always been necessary. Nobody said otherwise - except for you.

>The
> intention - which was achieved, and is still the case today - was that
> you could write /most/ of the OS in at least reasonably portable C,
> relying somewhat on implementation-dependent behaviour in parts.

And the point of the article, was exactly that you cannot do that any more because
implementation dependent C has been largely displaced by "undefined behavior" C. This is why Linux relies on a growing
number of gcc specific flags that turn off different compiler behaviors permitted by, encouraged by, the ISO standard.
Can you compare pointers? In K&R C you can, if the hardware allows. In ISO-C you cannot unless they are both within the
same object or (possible, one past). So the malloc/free implementation in K&R2, if you read the paper, you would know, might or
might not work depending on optimization level and compiler version even when the hardware (like 99% of modern processors)
allows you to make the comparison. Can you cast a pointer to a different type? Sure. Can you dereference it?
Maybe, maybe not, depending on the optimizer level and how the compiler is interpreting type rules today.

> And if you look at OS's today, that's what you see. Whether you look at
> massive OS's like BSD or Linux, or small ones like FreeRTOS, you'll see
> the great majority is written in plain standards-defined C. Some parts

And if you had read the article you would know that what you just wrote is wrong.

> are unavoidably written in assembly (either inline or stand-alone), some
> parts are dependent on implementation details for the targets supported,
> and sometimes the writers take advantage of compiler extensions or
> features in order to write code that is more efficient, clearer, or
> otherwise better than standard C alone.
>
> Some details have changed since C's inception, but the principles have not.

Charitably, you are just 25 years behind on what gcc/clang do. Catch up.

In article <jwvczoctu50.fsf-monnier+comp.arch@gnu.org>,
monnier@iro.umontreal.ca (Stefan Monnier) wrote:

> even smartphones come with 8GB these days.

That's mostly so that the ever-increasing amounts of vendor-specific GUI
customisation in Android leave you with enough RAM to run big games.

It's also useful to people who provide industrial-strength mathematical
modelling software for Android. Some find it easier to just run all their
testing than to define appropriate subsets and write the appropriate
caveats in the support agreement. There aren't very many of us, but we
like the 16GB phones that are around these days.

John

Victor Yodaiken <victor.yodaiken@gmail.com> schrieb:
> Can you cast a pointer to a different type? Sure.

>Can you dereference it?

No.

> Maybe, maybe not, depending on the optimizer level and how the
> compiler is interpreting type rules today.

The standard is quite clear about that.

But, by all means, do to try to make C slower. It would help my
favorite language, Fortran, become faster by comparison :-)

On 10/11/2021 9:18 AM, Stefan Monnier wrote:
>> And note that the decision to combine them or not is orthogonal to the
>> Single/Multiple address space decision (which has its own set of
>> tradeoffs). I think all four combinations are possible.
>
> Technically that's true, but of course for an SASOS the mapping table is
> global whereas the protection tables are per-process, so it naturally
> lends itself to a hardware where the two are decoupled.

Yes. I agree that decoupled is easier in a SAS.

--
- Stephen Fuld
(e-mail address disguised to prevent spam)

MitchAlsup <MitchAlsup@aol.com> schrieb:
> On Sunday, October 10, 2021 at 3:19:02 PM UTC-5, John Dallman wrote:
>> In article <sjvesb$a36$1...@dont-email.me>, cr8...@gmail.com (BGB) wrote:
>>
>> > The design of the PBO ABI puts the responsibility of the GBR reload
>> > onto the called function, which in turn is only needed in certain
>> > cases: ...
>> > Function pointers which are also non-leaf and/or access global
>> > variables.
>> How does the compiler know, when compiling a function, if it will be
>> called via a pointer?
><
> More importantly, why should it even know ?

If the function accesses variables from an outer block or function,
that might be relevant (depending on the calling convention for that).

Vanilla C does not have that feature, so it is not relevant there.

On 10/11/2021 3:44 PM, Thomas Koenig wrote:
> MitchAlsup <MitchAlsup@aol.com> schrieb:
>> On Sunday, October 10, 2021 at 3:19:02 PM UTC-5, John Dallman wrote:
>>> In article <sjvesb$a36$1...@dont-email.me>, cr8...@gmail.com (BGB) wrote:
>>>
>>>> The design of the PBO ABI puts the responsibility of the GBR reload
>>>> onto the called function, which in turn is only needed in certain
>>>> cases: ...
>>>> Function pointers which are also non-leaf and/or access global
>>>> variables.
>>> How does the compiler know, when compiling a function, if it will be
>>> called via a pointer?
>> <
>> More importantly, why should it even know ?
>
> If the function accesses variables from an outer block or function,
> that might be relevant (depending on the calling convention for that).
>
> Vanilla C does not have that feature, so it is not relevant there.
>

There was a proposal to add lambdas (with C++ style syntax) to C23,
though with slightly restricted semantics.

Though, granted, lambdas are sort of their own thing, as are GCC style
nested functions, ...

In this case, it needs to know the difference for whether or not it
needs to do a GBR reload. The alternative would be always doing a GBR
reload, but this would be rather detrimental to its "low overhead"
advantage relative to ELF FDPIC (since it would add ~ 2 memory loads,
and a register save/restore pair, to pretty much every function call).

On Monday, October 11, 2021 at 3:15:55 PM UTC-5, Thomas Koenig wrote:
> > Can you cast a pointer to a different type? Sure.
>
> >Can you dereference it?
> No.
> > Maybe, maybe not, depending on the optimizer level and how the
> > compiler is interpreting type rules today.
> The standard is quite clear about that.
>

Always an amusing claim.

On 2021-10-11, George Neuner <gneuner2@comcast.net> wrote:
> On Sat, 09 Oct 2021 22:22:45 GMT, Branimir Maksimovic
><branimir.maksimovic@icloud.com> wrote:
>
>>Boehm's collector scans heap/stack/bss, pointing anywhere within
>>allocated area, no problem with that.
>
> The problem isn't finding pointers that refer to the heap, the problem
> is finding pointers that refer to particular allocated blocks IN the
> heap.
\Well, I thouht this was easy task as it is simple pointer
arithemtic, but now I think you are right, heap can be
fragmented and that's a problem.

>
> And that's one of the places that BDW falls down. (see below)
>
>
>> ... Boehm's collector works with C. With C++ there are problems
>>because of caching scheme in defualt allocator.
>
> BDW has lots of problems - the least of which is the space overhead: a
> collected heap needs to be 30+% larger (minimum) than a heap that
> isn't collected.
>
> To use BDW effectively, you have to change your programming style, and
> you have to actively tell the collector what objects should be
> considered "roots", and what objects can be ignored for scanning
> because they won't ever contain pointers.
>
> Even with programmer assistance, BDW slows down VERY quickly as the
> live data set grows.
>

Well, surelly less than when you move allocated area then have to
update ll references in profram or to apply membar on every memory
access through pointers :p
GC is costly no question in that :P
>
> Been there, done that.
> George

--

7-77-777
Evil Sinner!
with software, you repeat same experiment, expecting different results...

On Saturday, October 9, 2021 at 1:16:10 PM UTC-6, John Levine wrote:
> According to Ivan Godard <iv...@millcomputing.com>:
> >>> Granted, this does have the (fairly obvious) property that most
> >>> traditional schemes for memory protection, ..., kinda go out the
> >>> window when one has multiple logical processes within the same address
> >>> space (as do the traditional distinctions between threads and processes).
> >>
> >> Not necessarily. Just because multiple logical processes exist within
> >> the same address space, doesn't mean that each process has legal access
> >> to all the addresses within that space.
> >
> >An address space tells you what you can name; a protection domain tells
> >you whether naming it does you any good.

> Quite right. Over fifty years ago S/360 put everything in one address space
> and had a memory protection scheme so that programs couldn't stomp on (or in
> some cases even look at) pages that weren't theirs.

Oh, yes. It can be argued that not letting processes even name what you
don't want them to see or change is, at least, a good idea because it's an
extra line of defence. But just because it _is_ an extra line of defence
doesn't make it impossible to breach, weaknesses have been found in
systems with virtualization-based security.

So the real question is: is the extra level of complexity worth it?

Historically, of course, virtualization was first brought in to allow the
convenience of having a computer serve, at the same time, users who
wanted to use that computer under different operating systems.
Extra security was just a bonus.

John Savard

On Saturday, October 9, 2021 at 2:11:23 PM UTC-6, Ivan Godard wrote:

> The B5000 stream procedures did if you generated the code yourself; I
> think so, anyway, it was before my time there. The B6500 secured the
> compilers so it wasn't possible; the instruction to set the 3-bit tag
> was only available from ESPOL, the OS flavor of Algol. Later on (after
> my day) I think they realized that securing the compilers was
> impractical and so the instruction was made privileged.

I'm not sure that "realized" was quite the right word.

After all, B6500 shops restricted people from bringing in their
own magnetic tapes, and stuff like that. So it wasn't necessarily
so much that they realized their security model was *flawed*
all along, but that circumstances had changed, and it was no
longer applicable to how people wanted to use computers
these days, with them being smaller and cheaper and all that.

John Savard

On Saturday, October 9, 2021 at 7:02:42 PM UTC-6, victor....@gmail.com wrote:

> Of course the paper doesn't make an argument anything like that nor does it make the assembler claims
> you start with. It is hard to believe anyone could read the
> paper and get such a weird take from it.

Maybe such a one had been exposed to the posts
of Anton Ertl, for example, and had just assumed,
after reading part of the paper and throwing it
down in disgust, that it represented a similar
viewpoint?

Actually, that's not entirely fair to Anton Ertl, who
is more reasonable than some representatives of
that viewpoint.

It's a viewpoint to which I'm not altogether
unsympathetic, since I see no need to spoil C
by turning it into C++ when we already have
C++.

John Savard

On Sunday, October 10, 2021 at 1:08:54 PM UTC-6, David W Schroth wrote:

> A nitpick - the Burroughs side of Unisys sandboxs the entire thing,
> the Univac side doesn't.

True, but the context was that they were only talking about the Burroughs
architecture.

The Univac machines were perfectly conventional, of course.

> Based upon the number of reported cases of someone
> getting around the protection on OS2200, it seems to work.

Perhaps, but it's going to be argued that we're just seeing
"security by obscurity" in action.

John Savard

On Sunday, October 10, 2021 at 2:59:23 PM UTC-6, MitchAlsup wrote:
> On Sunday, October 10, 2021 at 3:19:02 PM UTC-5, John Dallman wrote:

> > How does the compiler know, when compiling a function, if it will be
> > called via a pointer?

> More importantly, why should it even know ?

That depends on what you mean by "called via a pointer". If calling
a function causes the computer to fetch, as the first instruction of
that function, the pointer to that function instead, the compiler has
not been properly told which calling sequence to use.

Of course the *function* shouldn't have to know that the calling
program has wrapped a little protective shell around it, but that's
a different issue.

So the answer to your question is basically that "compilers need to
be in a position to generate code that actually works", but I'm sure
you knew that, and it was just an accident that your wording was
infelicitous.

John Savard

Victor Yodaiken <victor.yodaiken@gmail.com> schrieb:
> On Monday, October 11, 2021 at 3:15:55 PM UTC-5, Thomas Koenig wrote:
>> > Can you cast a pointer to a different type? Sure.
>>
>> >Can you dereference it?
>> No.
>> > Maybe, maybe not, depending on the optimizer level and how the
>> > compiler is interpreting type rules today.
>> The standard is quite clear about that.
>>

> Always an amusing claim.

Do you have trouble understanding the standard?

On Monday, October 11, 2021 at 11:34:48 PM UTC-6, Quadibloc wrote:
> On Sunday, October 10, 2021 at 2:59:23 PM UTC-6, MitchAlsup wrote:
> > On Sunday, October 10, 2021 at 3:19:02 PM UTC-5, John Dallman wrote:

> > > How does the compiler know, when compiling a function, if it will be
> > > called via a pointer?

> > More importantly, why should it even know ?

> That depends on what you mean by "called via a pointer".

Of course, the way in which _you_ meant it, you were perfectly
correct; constructions like

x := (* fun)(y) ;

....I think that's how you would say it in C...

where fun is a pointer to code... aren't going to change a thing
about how the function, a pointer to which was placed in the
variable fun, will be called.

So of course that function, compiled separately, can be
completely conventional.

John Savard

On 10/11/2021 10:17 PM, Quadibloc wrote:
> On Saturday, October 9, 2021 at 1:16:10 PM UTC-6, John Levine wrote:
>> According to Ivan Godard <iv...@millcomputing.com>:
>>>>> Granted, this does have the (fairly obvious) property that most
>>>>> traditional schemes for memory protection, ..., kinda go out the
>>>>> window when one has multiple logical processes within the same address
>>>>> space (as do the traditional distinctions between threads and processes).
>>>>
>>>> Not necessarily. Just because multiple logical processes exist within
>>>> the same address space, doesn't mean that each process has legal access
>>>> to all the addresses within that space.
>>>
>>> An address space tells you what you can name; a protection domain tells
>>> you whether naming it does you any good.
>
>> Quite right. Over fifty years ago S/360 put everything in one address space
>> and had a memory protection scheme so that programs couldn't stomp on (or in
>> some cases even look at) pages that weren't theirs.
>
> Oh, yes. It can be argued that not letting processes even name what you
> don't want them to see or change is, at least, a good idea because it's an
> extra line of defence. But just because it _is_ an extra line of defence
> doesn't make it impossible to breach, weaknesses have been found in
> systems with virtualization-based security.
>
> So the real question is: is the extra level of complexity worth it?
>
> Historically, of course, virtualization was first brought in to allow the
> convenience of having a computer serve, at the same time, users who
> wanted to use that computer under different operating systems.
> Extra security was just a bonus.

I think you may be confusing SAS versus MAS, and process protection
mechanisms with VM/multiple OSs and similar virtualization techniques.
They are totally different.

--
- Stephen Fuld
(e-mail address disguised to prevent spam)

On 10/12/2021 12:34 AM, Quadibloc wrote:
> On Sunday, October 10, 2021 at 2:59:23 PM UTC-6, MitchAlsup wrote:
>> On Sunday, October 10, 2021 at 3:19:02 PM UTC-5, John Dallman wrote:
>
>>> How does the compiler know, when compiling a function, if it will be
>>> called via a pointer?
>
>> More importantly, why should it even know ?
>
> That depends on what you mean by "called via a pointer". If calling
> a function causes the computer to fetch, as the first instruction of
> that function, the pointer to that function instead, the compiler has
> not been properly told which calling sequence to use.
>
> Of course the *function* shouldn't have to know that the calling
> program has wrapped a little protective shell around it, but that's
> a different issue.
>
> So the answer to your question is basically that "compilers need to
> be in a position to generate code that actually works", but I'm sure
> you knew that, and it was just an accident that your wording was
> infelicitous.
>

In the PBO ABI, a function pointer is typically one of:
A pointer to the first instruction of the function to be called;
A pointer to some sort of wrapper for the function to be called.

For normal function pointers, it is usually the former.

For lambdas and DLL imports, usually the latter.

For lambdas, the pointer is to the start of an "executable object" which
loads its own address into a register (as per "thiscall") and then
branches to the target function. The 'thiscall' case is nearly identical
to the normal C ABI, except that 'this' is loaded into a register. In
this case, lambdas don't have class instance, but do have captured bindings.

For DLL imports, it is typically an indirect branch.
The typical process is to load the target address from the IAT (Import
Address Table) and then branch to it. I have debated defining a special
case where the branch instruction can be itself encoded in the IAT.

....

Note that in ELF FDPIC, the function pointer is typically a pointer to a
location in memory which holds both the address of the target function's
body, and also a pointer to the GOT to use for calling said function.

On 2021-10-12, Quadibloc <jsavard@ecn.ab.ca> wrote:
> On Saturday, October 9, 2021 at 1:16:10 PM UTC-6, John Levine wrote:
>> According to Ivan Godard <iv...@millcomputing.com>:
>> >>> Granted, this does have the (fairly obvious) property that most
>> >>> traditional schemes for memory protection, ..., kinda go out the
>> >>> window when one has multiple logical processes within the same address
>> >>> space (as do the traditional distinctions between threads and processes).
>> >>
>> >> Not necessarily. Just because multiple logical processes exist within
>> >> the same address space, doesn't mean that each process has legal access
>> >> to all the addresses within that space.
>> >
>> >An address space tells you what you can name; a protection domain tells
>> >you whether naming it does you any good.
>
>> Quite right. Over fifty years ago S/360 put everything in one address space
>> and had a memory protection scheme so that programs couldn't stomp on (or in
>> some cases even look at) pages that weren't theirs.
>
> Oh, yes. It can be argued that not letting processes even name what you
> don't want them to see or change is, at least, a good idea because it's an
> extra line of defence. But just because it _is_ an extra line of defence
> doesn't make it impossible to breach, weaknesses have been found in
> systems with virtualization-based security.
>
> So the real question is: is the extra level of complexity worth it?
>

IMO, no. Security is only meaningfull when nothing is secret, eg I openly
say I work for spooks and RS military. No one will notice that :P

> Historically, of course, virtualization was first brought in to allow the
> convenience of having a computer serve, at the same time, users who
> wanted to use that computer under different operating systems.
> Extra security was just a bonus.
>

Segmentation is better model that is faster memory access to certain
address space and no unecessary overhoad of address translation...

> John Savard

Greets, Branimir.

--

7-77-777
Evil Sinner!
with software, you repeat same experiment, expecting different results...