Austin Group Defect Tracker

Aardvark Mark IV

Main | My View | View Issues | Change Log | Docs
  

Viewing Issue Simple Details [ Jump to Notes ] [ Issue History ] [ Print ]
ID Category Severity Type Date Submitted Last Update
0001644 [1003.1(2016/18)/Issue7+TC2] System Interfaces Comment Enhancement Request 2023-03-22 09:52 2024-06-11 09:07
Reporter bastien View Status public  
Assigned To
Priority normal Resolution Accepted As Marked  
Status Closed  
Name Bastien Roucaries
Organization debian
User Reference
Section dlsym - get the address of a symbol from a symbol table handle
Page Number Application usage
Line Number all
Interp Status ---
Final Accepted Text Note: 0006272
Summary 0001644: void * to function pointer is described in annex J of C standard (informative).
Description Standard say
  Note that conversion from a void * pointer to a function pointer as in:

   fptr = (int (*)(int))dlsym(handle, "my_function");

  is not defined by the ISO C standard. This standard requires this conversion to work correctly on conforming implementations.
J.5.7 Function pointer casts
1 A pointer to an object or to void may be cast to a pointer to a function, allowing data to
be invoked as a function (6.5.4).
2 A pointer to a function may be cast to a pointer to an object or to void, allowing a
function to be inspected or modified (for example, by a debugger) (6.5.4).
It is not true, this behavior is described in J - Portability issues, §J.5.7 Function pointer cast (informative)
Desired Action Add a note that POSIX conforment compiler should implement §J.5.7 Function pointer casts
1 A pointer to an object or to void may be cast to a pointer to a function, allowing data to
be invoked as a function (6.5.4).
2 A pointer to a function may be cast to a pointer to an object or to void, allowing a
function to be inspected or modified (for example, by a debugger) (6.5.4).
Tags applied_after_i8d3, tc3-2008
Attached Files

- Relationships
related to 0000074Closedajosey 1003.1(2008)/Issue 7 Pointer Types Problem 

-  Notes
(0006220)
wlerch (reporter)
2023-03-22 13:24

 Requiring §J.5.7 is overkill. Requiring support for calling into data, or examining code as data, sounds like asking for all sorts of security issues.

All that is needed to have a working dlsym() is that a void* pointer returned by a dlsym() call that names a function, and no other void* pointer, can be safely converted to the correct function type and called. This can be achieved without opening up the entire address space for accessing data as code and code as data, as would be required by §J.5.7.
(0006222)
bastien (reporter)
2023-03-22 15:15

 @wlerch I perfectly understand your remark, nevertheless could we reformulate like this:

the returned pointer of dlsym() may be cast to a pointer to a function, allowing data to
be invoked as a function. Posix system should respect §J.5.7.1 of ISO C standard for the pointer returned by dlsym()

I want in fact to use the same wording between C standard and POSIX.
(0006223)
wlerch (reporter)
2023-03-22 15:43

 Why? The same wording would mean the same requirements, wouldn't it? Why would you want to impose unnecessary requirements that lead to potential security risks?

dlsym does not need to allow data to be invoked as a function. The pointer returned by it does not need to point to data. The only requirement that is necessary is that it can be converted to a pointer to function, resulting in a pointer that can be used to call the function.
(0006224)
bastien (reporter)
2023-03-22 16:10

 Ok understood your point

may be:
a void* pointer returned by a dlsym() call that names a function, can be safely converted to the correct function type and called.
(0006225)
wlerch (reporter)
2023-03-22 18:43

 I like the text suggested in 0000074


dlsym()'s return value, cast to a pointer to the type of the symbol, may be used to call (in case of a function) respectively access (in case of a [data] object) the symbol.


But it should say "converted", not "cast".

And it could just say that result of the conversion will point to the object or function, and let C define what such a pointer can then be used for.

I am not a big fan of the existing text saying that "if name names a function identifier, dlsym() shall return the address of the function converted from type pointer to function to type pointer to void". It's not the job of POSIX to specify how an implementation of dlsym() must produce the void* value to return, and it makes particularly little sense to insist that it must use a conversion that has undefined behaviour in standard C.

Saying later that a different conversion, from the void* pointer to a function pointer, is required to "work correctly" does not really fix that.
(0006229)
geoffclare (manager)
2023-03-23 09:39

 > I like the text suggested in 0000074
>
> dlsym()'s return value, cast to a pointer to the type of the symbol, may be
> used to call (in case of a function) respectively access (in case of a [data]
> object) the symbol.

This was added to the standard, with minor wording changes, at line 25417:
The return value from dlsym(), cast to a pointer to the type of the named symbol, can be used to call (in the case of a function) or access the contents of (in the case of a data object) the named symbol.

> But it should say "converted", not "cast".

I suspect the text says "cast" for the thing the application does because trying to do the conversion without a cast would cause C compilers to produce a diagnostic. (It can just say "converted" for the thing the implementation does because how it does that is internal implementation detail.)
(0006232)
wlerch (reporter)
2023-03-23 13:47
edited on: 2023-03-23 13:52

 Ah, right, in the Description, somehow I didn't look there, thanks. :)

Regarding "cast", no, a conversion without a cast would not necessarily produce a diagnostic -- a diagnostic is not required if the target type is a pointer to an object type. If the text said "converted", it would be up to the reader to figure out from the rules of C when a cast is necessary to prevent a diagnostic; but since it says "cast", it might make a pedantic reader wonder if it means to say that an explicit cast is indeed required, even in cases where an assignment without a cast would be just as good as far as standard rules of C are concerned.

I suspect the real reason it says "cast" is because a lot of people refer to any conversion as a "cast" and a cast as an "explicit cast". I think it's common enough to be tolerable in less formal contexts, but in a formal document such as this it would be better to use terms defined in the C standard consistently with how they're defined there.
(0006233)
geoffclare (manager)
2023-03-23 14:02

 > a diagnostic is not required if the target type is a pointer to an object type

Of course you're right. In my mind I was replying in the context of the named symbol being a function, but I neglected to state that condition.

> I suspect the real reason it says "cast" is because a lot of people refer to any conversion as a "cast" and a cast as an "explicit cast".

If that were the reason, I would expect the related text in RETURN VALUE to say "cast" as well.
(0006234)
wlerch (reporter)
2023-03-23 14:45

 > In my mind I was replying in the context of the named symbol being a function, but I neglected to state that condition.

But my point is that the text in the standard does not state that condition either. Yes, trying to do the conversion without a cast would sometimes cause C compilers to produce a diagnostic, but other times it would not, so that does not sound like a good reason to have a wording that can be interpreted as implying that a cast is always required.

> > I suspect the real reason it says "cast" is because a lot of people refer to any conversion as a "cast" and a cast as an "explicit cast".
> If that were the reason, I would expect the related text in RETURN VALUE to say "cast" as well.

The text that says "cast" was added after the text in RETURN VALUE was already there, wasn't it? It wouldn't make a lot of sense to adjust the existing text that was already using the more accurate "conversion" to use the less accurate "cast" instead, just because new text using "cast" was being added. I think would have been better to adjust the new text to use the more accurate "conversion" and be more consistent with the existing text, but if it was done by someone who thought of "cast" as a synonym for "conversion", I can understand why they would not have bothered.

Anyway, investigating the reasons and motives behind the existing text is probably not quite as important as figuring out whether the existing text is sufficient or deserves some changes, is it?...
(0006235)
geoffclare (manager)
2023-03-23 16:42

 > The text that says "cast" was added after the text in RETURN VALUE was already there, wasn't it?

No, all of the wording about casting and conversion is from bug 0000074.

> Anyway, investigating the reasons and motives behind the existing text is
> probably not quite as important as figuring out whether the existing text is
> sufficient or deserves some changes

Indeed.
(0006272)
geoffclare (manager)
2023-04-27 15:31

 On page 746 line 25418 section dlsym(), change:
cast to a pointer to the type of the named symbol
to:
converted from type pointer to void to a pointer to the type of the named symbol

- Issue History
Date Modified Username Field Change
2023-03-22 09:52 bastien New Issue
2023-03-22 09:52 bastien Name => Bastien Roucaries
2023-03-22 09:52 bastien Organization => debian
2023-03-22 09:52 bastien Section => dlsym - get the address of a symbol from a symbol table handle
2023-03-22 09:52 bastien Page Number => Application usage
2023-03-22 09:52 bastien Line Number => all
2023-03-22 13:24 wlerch Note Added: 0006220
2023-03-22 15:15 bastien Note Added: 0006222
2023-03-22 15:43 wlerch Note Added: 0006223
2023-03-22 16:10 bastien Note Added: 0006224
2023-03-22 18:43 wlerch Note Added: 0006225
2023-03-23 09:39 geoffclare Note Added: 0006229
2023-03-23 13:47 wlerch Note Added: 0006232
2023-03-23 13:52 wlerch Note Edited: 0006232
2023-03-23 14:02 geoffclare Note Added: 0006233
2023-03-23 14:45 wlerch Note Added: 0006234
2023-03-23 16:42 geoffclare Note Added: 0006235
2023-03-23 16:42 geoffclare Relationship added related to 0000074
2023-04-27 15:31 geoffclare Note Added: 0006272
2023-04-27 15:32 geoffclare Interp Status => ---
2023-04-27 15:32 geoffclare Final Accepted Text => Note: 0006272
2023-04-27 15:32 geoffclare Status New => Resolved
2023-04-27 15:32 geoffclare Resolution Open => Accepted As Marked
2023-04-27 15:32 geoffclare Tag Attached: tc3-2008
2023-06-13 10:48 geoffclare Status Resolved => Applied
2023-06-13 10:48 geoffclare Tag Attached: applied_after_i8d3
2024-06-11 09:07 agadmin Status Applied => Closed

Mantis 1.1.6[^]
Copyright © 2000 - 2008 Mantis Group
Powered by Mantis Bugtracker