Mailing List Archive

On 11.07.2023 18:40, Roberto Bagnara wrote:
> Mandatory Rule 19.1 (An object shall not be assigned or copied to an
> overlapping object) is directly targeted at two undefined behaviors,
> one of which is the subject of 6.5.16.1p3, namely:
>
> If the value being stored in an object is read from another object
> that overlaps in any way the storage of the first object, then the
> overlap shall be exact and the two objects shall have qualified or
> unqualified versions of a compatible type; otherwise, the behavior
> is undefined.
>
> You can see a number of definite violations in the X86_64 build
> at this link:
>
> https://saas.eclairit.com:3787/fs/var/local/eclair/XEN.ecdf/ECLAIR_normal/origin/staging/X86_64-Set1/149/PROJECT.ecd;/by_service/MC3R1.R19.1.html

Hmm, gives me "Unauthorized".

> As the rule is mandatory, it cannot be deviated.

Which is odd, and that's in turn because the C spec is overly strict
imo. Considering the one example we looked at yesterday, I have a hard
time seeing what UB there would be on little-endian hardware. Both
fields (rip and eip) don't overlap exactly, but their low halves (which
is all we care about here) do. With this I cannot come up with a way in
which the compiler could screw us up, even if it wanted to.

Jan

Il giorno mer 12 lug 2023 alle ore 14:50 Jan Beulich <jbeulich@suse.com> ha
scritto:

> On 11.07.2023 18:40, Roberto Bagnara wrote:
> > Mandatory Rule 19.1 (An object shall not be assigned or copied to an
> > overlapping object) is directly targeted at two undefined behaviors,
> > one of which is the subject of 6.5.16.1p3, namely:
> >
> > If the value being stored in an object is read from another object
> > that overlaps in any way the storage of the first object, then the
> > overlap shall be exact and the two objects shall have qualified or
> > unqualified versions of a compatible type; otherwise, the behavior
> > is undefined.
> >
> > You can see a number of definite violations in the X86_64 build
> > at this link:
> >
> >
> https://saas.eclairit.com:3787/fs/var/local/eclair/XEN.ecdf/ECLAIR_normal/origin/staging/X86_64-Set1/149/PROJECT.ecd;/by_service/MC3R1.R19.1.html
>
> Hmm, gives me "Unauthorized".
>

Please try again, now it should work.

Simone Ballarin, M.Sc.

Field Application Engineer, BUGSENG (https://bugseng.com
<http://bugseng.com>)

On 11.07.2023 18:40, Roberto Bagnara wrote:
> Mandatory Rule 19.1 (An object shall not be assigned or copied to an
> overlapping object) is directly targeted at two undefined behaviors,
> one of which is the subject of 6.5.16.1p3, namely:
>
> If the value being stored in an object is read from another object
> that overlaps in any way the storage of the first object, then the
> overlap shall be exact and the two objects shall have qualified or
> unqualified versions of a compatible type; otherwise, the behavior
> is undefined.
>
> You can see a number of definite violations in the X86_64 build
> at this link:
>
> https://saas.eclairit.com:3787/fs/var/local/eclair/XEN.ecdf/ECLAIR_normal/origin/staging/X86_64-Set1/149/PROJECT.ecd;/by_service/MC3R1.R19.1.html

Just to summarize: Except for one instance, all follow the same pattern
of extending in-place a (guest) register value. Sometimes in straight
line code (typically eip -> rip), otherwise in get_rep_prefix() (esi ->
rsi and edi -> rdi). I continue to think that the way we have it is the
best way for it to be written; as per an earlier reply I also can't see
how even a "malicious" compiler (still aiming at generating correct
code, just not necessarily doing things the "obvious" way) could break
those cases. (I understand none of this is going to help, yet I'd like
to clarify that sometimes overly strict rules are getting in the way,
like here forcing use to e.g. switch to using casts when we'd like to
avoid doing so.)

The one other instance is in compat multicall handling. There I guess
the compiler could indeed do things "the wrong way". Any solution there
that I can think of would involve an auxiliary on-stack array, to first
copy into and then out of. That's not very efficient, so I wonder what
your suggestion would be how to deal with such a case.

Jan

On 11.07.2023 18:40, Roberto Bagnara wrote:
> Mandatory Rule 19.1 (An object shall not be assigned or copied to an
> overlapping object) is directly targeted at two undefined behaviors,
> one of which is the subject of 6.5.16.1p3, namely:
>
> If the value being stored in an object is read from another object
> that overlaps in any way the storage of the first object, then the
> overlap shall be exact and the two objects shall have qualified or
> unqualified versions of a compatible type; otherwise, the behavior
> is undefined.
>
> You can see a number of definite violations in the X86_64 build
> at this link:
>
> https://saas.eclairit.com:3787/fs/var/local/eclair/XEN.ecdf/ECLAIR_normal/origin/staging/X86_64-Set1/149/PROJECT.ecd;/by_service/MC3R1.R19.1.html

After having agreed among the x86 maintainers to switch to using casts
there, I tried to access this list again, just to find that now I'm
getting back "Cannot open database". I know you said this would go
away after a couple of weeks, but it's less than one wee that has
passed. I'll try to go from memory when making the patch, but of
course I may miss instances ...

Jan

On 17/07/23 14:42, Jan Beulich wrote:
> On 11.07.2023 18:40, Roberto Bagnara wrote:
>> Mandatory Rule 19.1 (An object shall not be assigned or copied to an
>> overlapping object) is directly targeted at two undefined behaviors,
>> one of which is the subject of 6.5.16.1p3, namely:
>>
>> If the value being stored in an object is read from another object
>> that overlaps in any way the storage of the first object, then the
>> overlap shall be exact and the two objects shall have qualified or
>> unqualified versions of a compatible type; otherwise, the behavior
>> is undefined.
>>
>> You can see a number of definite violations in the X86_64 build
>> at this link:
>>
>> https://saas.eclairit.com:3787/fs/var/local/eclair/XEN.ecdf/ECLAIR_normal/origin/staging/X86_64-Set1/149/PROJECT.ecd;/by_service/MC3R1.R19.1.html
>
> After having agreed among the x86 maintainers to switch to using casts
> there, I tried to access this list again, just to find that now I'm
> getting back "Cannot open database". I know you said this would go
> away after a couple of weeks, but it's less than one wee that has
> passed. I'll try to go from memory when making the patch, but of
> course I may miss instances ...
>
> Jan
>

I can generate a new database with just this rule, and we will
definitely extend the period these artifacts will remain available.

--
Nicola Vetrini, BSc
Software Engineer, BUGSENG srl (https://bugseng.com)

On 11.07.2023 18:40, Roberto Bagnara wrote:
> Mandatory Rule 19.1 (An object shall not be assigned or copied to an
> overlapping object) is directly targeted at two undefined behaviors,
> one of which is the subject of 6.5.16.1p3, namely:
>
> If the value being stored in an object is read from another object
> that overlaps in any way the storage of the first object, then the
> overlap shall be exact and the two objects shall have qualified or
> unqualified versions of a compatible type; otherwise, the behavior
> is undefined.

I'd like to come back to this, for two reasons:

1) In the description of -fstrict-aliasing, gcc 13.2 doc says "Even with
-fstrict-aliasing, type-punning is allowed, provided the memory is accessed
through the union type." We even build with -fno-strict-aliasing, yet
misra/rules.rst has no mention at all of type punning being permitted.

2) With us using -fno-strict-aliasing, I wonder in how far e.g. commit
7225f13aef03 ("x86: avoid Misra Rule 19.1 violations") wasn't pointless, as
imo the "compatible types" part of the C spec clause then can be treated as
irrelevant.

To me both simply mean we're relying on another compiler extension that's
not exactly spelled out as such.

Opinions?

Jan

On 2024-03-28 11:25, Jan Beulich wrote:
> On 11.07.2023 18:40, Roberto Bagnara wrote:
>> Mandatory Rule 19.1 (An object shall not be assigned or copied to an
>> overlapping object) is directly targeted at two undefined behaviors,
>> one of which is the subject of 6.5.16.1p3, namely:
>>
>> If the value being stored in an object is read from another object
>> that overlaps in any way the storage of the first object, then the
>> overlap shall be exact and the two objects shall have qualified or
>> unqualified versions of a compatible type; otherwise, the behavior
>> is undefined.
>
> I'd like to come back to this, for two reasons:
>
> 1) In the description of -fstrict-aliasing, gcc 13.2 doc says "Even
> with
> -fstrict-aliasing, type-punning is allowed, provided the memory is
> accessed
> through the union type." We even build with -fno-strict-aliasing, yet
> misra/rules.rst has no mention at all of type punning being permitted.
>
> 2) With us using -fno-strict-aliasing, I wonder in how far e.g. commit
> 7225f13aef03 ("x86: avoid Misra Rule 19.1 violations") wasn't
> pointless, as
> imo the "compatible types" part of the C spec clause then can be
> treated as
> irrelevant.
>
> To me both simply mean we're relying on another compiler extension
> that's
> not exactly spelled out as such.
>
> Opinions?
>
> Jan

Regardless of whether the compiler will do the right thing or not,
Mandatory guidelines can't be deviated.

--
Nicola Vetrini, BSc
Software Engineer, BUGSENG srl (https://bugseng.com)

On 04.04.2024 14:59, Nicola Vetrini wrote:
> On 2024-03-28 11:25, Jan Beulich wrote:
>> On 11.07.2023 18:40, Roberto Bagnara wrote:
>>> Mandatory Rule 19.1 (An object shall not be assigned or copied to an
>>> overlapping object) is directly targeted at two undefined behaviors,
>>> one of which is the subject of 6.5.16.1p3, namely:
>>>
>>> If the value being stored in an object is read from another object
>>> that overlaps in any way the storage of the first object, then the
>>> overlap shall be exact and the two objects shall have qualified or
>>> unqualified versions of a compatible type; otherwise, the behavior
>>> is undefined.
>>
>> I'd like to come back to this, for two reasons:
>>
>> 1) In the description of -fstrict-aliasing, gcc 13.2 doc says "Even
>> with
>> -fstrict-aliasing, type-punning is allowed, provided the memory is
>> accessed
>> through the union type." We even build with -fno-strict-aliasing, yet
>> misra/rules.rst has no mention at all of type punning being permitted.
>>
>> 2) With us using -fno-strict-aliasing, I wonder in how far e.g. commit
>> 7225f13aef03 ("x86: avoid Misra Rule 19.1 violations") wasn't
>> pointless, as
>> imo the "compatible types" part of the C spec clause then can be
>> treated as
>> irrelevant.
>>
>> To me both simply mean we're relying on another compiler extension
>> that's
>> not exactly spelled out as such.
>>
>> Opinions?
>
> Regardless of whether the compiler will do the right thing or not,
> Mandatory guidelines can't be deviated.

Are you suggesting then that we need to build with -fstrict-aliasing,
sorting out all the issues that there may be? And avoid type-punning
as well?

Jan