[C-safe-secure-studygroup] MISRA and packed structures
Roberto Bagnara
bagnara at cs.unipr.it
Wed Nov 28 20:06:27 GMT 2018
On 11/28/18 8:10 PM, Martin Sebor wrote:
> On 11/28/18 9:03 AM, Roberto Bagnara wrote:
>>
>> I am caught by the doubt my message was not received.
>> I wrote:
>>
>> As everything concerning the memory representation of structures
>> is implementation-defined, Directive 1.1 (Any implementation-defined
>> behaviour on which the output of the program depends shall be documented
>> and understood) applies.
>
> I would be more than surprised if any real software conformed to
> this requirement in a meaningful way.
Hi Martin.
I guess you mean "real software *project*", because this directive
involves both the code and the process (in that it required to document
and understand things).
> Take, for instance, 5.2.4.1
> Translation limits. How many projects have you seen that count
> the number of blocks, parentheses, or identifiers in their code
> to make sure they either don't exceed those limits or document
> their requirements beyond what the standard guarantees?
All projects that claim MISRA C compliance have to comply to Directive
1.1 or formally deviate it. Any good MISRA C tool will do the
counting and report when limits are exceeded; any such tool will also
allow users to specify the limits that are guaranteed by the compiler.
So with a good tool there is no manual counting work to be done.
> How many developers have you ever come across that understand what
> it means to exceed these limits, or even that some of those limits
> exist? (Heck, even some members of WG14 don't fully appreciate what
> it means.)
Developers who are meant to develop reliable code in C must be trained
to understand these things (e.g., undefined behavior), for otherwise
they cannot do the job properly. Lack of understanding can be slightly
mitigated by the use of tools that enforce sane coding rules preventing
the bad things from happening, but we all know that, without training,
this won't work (developers who do not understand will do bad things
to the code in order to silence the tool).
My understanding is that what you wrote is equivalent to: "Many developers
out there do not understand C well enough and do not use tools that
warn them when they do dangerous things." To which I would answer:
"Code that is written by such developers in that way will most likely
be neither safe nor secure."
>> In this respect, packed and non-packed
>> structures are no different from one another: any packing/non-packing
>> is just one of the way in which the compiler can define the behavior:
>>
>> 6.7.2.1#14 Each non-bit-field member of a structure or union object
>> is aligned in an implementation-defined manner appropriate
>> to its type.
>>
>> Here I am quoting C11 because I know that you care about that version
>> of the language, whereas for MISRA C:2012 I would have to quote the
>> equivalent sentences in C90 and C99.
>>
>> In addition, to Directive 1.1, if the selection of a packed representation
>> is done with special syntax (as opposed to be controlled from the command
>> line), then advisory Rule 1.2 (Language extensions should not be used)
>> might apply.
>> Kind regards,
>>
>> Roberto
>>
>>
>> On 11/28/18 4:33 PM, Robert Seacord wrote:
>>> MISRA really requires strictly conforming programs? I didn't think anyone tried to write strictly conforming programs because they are unreasonable.
>>>
>>> I've said this before, but I think confusing security and safety with portability.
>>>
>>> rCs
>>>
>>> On Wed, Nov 28, 2018 at 10:12 AM Clive Pygott <clivepygott at gmail.com <mailto:clivepygott at gmail.com>> wrote:
>>>
>>> I'd agree that __packed is like a pragma, but pragmas are explicitly implementation defined. Whether you want to call that a language extension or not, it clearly takes you outside the domain of strictly compliant programs
>>>
>>> Clive
>>>
>>> On Wed, Nov 28, 2018 at 1:02 PM Wilson, Charles <Charles.Wilson at draeger.com <mailto:Charles.Wilson at draeger.com>> wrote:
>>>
>>> I’m not sure I’d agree that this is an extension.____
>>>
>>> __ __
>>>
>>> I believe that it falls under the same category as pragmas, that is, guidance to the compiler.____
>>>
>>> __ __
>>>
>>> MSVC https://docs.microsoft.com/en-us/cpp/preprocessor/pack?view=vs-2017____
>>>
>>> gcc https://gcc.gnu.org/onlinedocs/gcc-3.3/gcc/Variable-Attributes.html#Variable%20Attributes____
>>>
>>> keil http://www.keil.com/support/man/docs/armclang_ref/armclang_ref_chr1384946440202.htm____
>>>
>>> __ __
>>>
>>> The clang sources provide an interesting view:____
>>>
>>> https://github.com/llvm-mirror/clang/blob/master/test/Sema/struct-packed-align.c____
>>>
>>> __ __
>>>
>>> __packed is used in the keil ARM compiler____
>>>
>>> http://www.keil.com/support/man/docs/armcc/armcc_chr1359124968737.htm____
>>>
>>> __ __
>>>
>>> as well as the gcc ARM compiler____
>>>
>>> http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0491e/CJAFJHJD.html____
>>>
>>> __ __
>>>
>>> An interesting side note is that all underscore prefixed things belong to the compiler.____
>>>
>>> __ __
>>>
>>> *From:* C-safe-secure-studygroup [mailto:c-safe-secure-studygroup-bounces at lists.trustable.io <mailto:c-safe-secure-studygroup-bounces at lists.trustable.io>] *On Behalf Of *Clive Pygott
>>> *Sent:* Wednesday, November 28, 2018 4:58 AM
>>> *To:* C Safety and Security Study Group Discussion <c-safe-secure-studygroup at lists.trustable.io <mailto:c-safe-secure-studygroup at lists.trustable.io>>
>>> *Subject:* Re: [C-safe-secure-studygroup] MISRA and packed structures____
>>>
>>> __ __
>>>
>>> Hi Robert____
>>>
>>> __ __
>>>
>>> What compiler are you using, as __packed isn't defined in either C11 or C17. If its a compiler extension then you've already broken rule 1.2 "language extensions should not be used". Its only advisory, so easy to deviate - but its a warning that you are now taking responsibility for the behaviour of the program.____
>>>
>>> __ __
>>>
>>> As far as memcpy is concerned, MISRA C:2012 has a number of examples that use memcpy, so its not totally banned. The examples all show array copying (where the implied pointer arithmetic is explicitly allowed), but my belief would be that copying a tMyStruct to another tMyStruct would be allowed using memcpy. What wouldn't be allowed would be copying to/from something of a different type, say an array of char.____
>>>
>>> __ __
>>>
>>> Clive____
>>>
>>> __ __
>>>
>>> __ __
>>>
>>> __ __
>>>
>>> __ __
>>>
>>> On Tue, Nov 27, 2018 at 3:34 PM Robert Seacord <rcseacord at gmail.com <mailto:rcseacord at gmail.com>> wrote:____
>>>
>>> Clive,____
>>>
>>> __ __
>>>
>>> In the following example:____
>>>
>>> __ __
>>>
>>> typedef __packed struct____
>>>
>>> {____
>>>
>>> uint16 a;____
>>>
>>> uint8 b[ANNOYING_INCONVENIENT_LENGTH];____
>>>
>>> uint16 c;____
>>>
>>> } tMyStruct;____
>>>
>>> ____
>>>
>>> tMyStruct buf;____
>>>
>>> ____
>>>
>>> Are you saying that 18.1 and 18.2 prohibit memcpy to &buf, ?____
>>>
>>> __ __
>>>
>>> Thanks,____
>>>
>>> rCs____
>>>
>>> __ __
>>>
>>> On Tue, Nov 27, 2018 at 8:16 AM Clive Pygott <clivepygott at gmail.com <mailto:clivepygott at gmail.com>> wrote:____
>>>
>>> What do you mean by a packed structure? The term doesn't appear in the C17 standard or MISRA C:2012____
>>>
>>> __ __
>>>
>>> If you mean using a structure with no or known padding as the target of a block move or I/O, then that has to be done by a deviation as it breaks the rules on pointer arithmetic (18.1/18.2) that only allow pointer arithmetic within an array____
>>>
>>> __ __
>>>
>>> Clive____
>>>
>>> __ __
>>>
>>> On Tue, Nov 27, 2018 at 12:05 PM Robert Seacord <rcseacord at gmail.com <mailto:rcseacord at gmail.com>> wrote:____
>>>
>>> Is there any MISRA rules which disallow the use of packed structures?____
>>>
>>> __ __
>>>
>>> rCs____
>>>
>>> _______________________________________________
>>> C-safe-secure-studygroup mailing list
>>> C-safe-secure-studygroup at lists.trustable.io <mailto:C-safe-secure-studygroup at lists.trustable.io>
>>> https://lists.trustable.io/cgi-bin/mailman/listinfo/c-safe-secure-studygroup____
>>>
>>> _______________________________________________
>>> C-safe-secure-studygroup mailing list
>>> C-safe-secure-studygroup at lists.trustable.io <mailto:C-safe-secure-studygroup at lists.trustable.io>
>>> https://lists.trustable.io/cgi-bin/mailman/listinfo/c-safe-secure-studygroup____
>>>
>>> _______________________________________________
>>> C-safe-secure-studygroup mailing list
>>> C-safe-secure-studygroup at lists.trustable.io <mailto:C-safe-secure-studygroup at lists.trustable.io>
>>> https://lists.trustable.io/cgi-bin/mailman/listinfo/c-safe-secure-studygroup____
>>>
>>> ---
>>> This communication contains confidential information. If you are not the intended recipient please return this email to the sender and delete it from your records.
>>>
>>> Diese Nachricht enthaelt vertrauliche Informationen. Sollten Sie nicht der beabsichtigte Empfaenger dieser E-mail sein, senden Sie bitte diese an den Absender zurueck und loeschen Sie die E-mail aus Ihrem System.
>>> _______________________________________________
>>> C-safe-secure-studygroup mailing list
>>> C-safe-secure-studygroup at lists.trustable.io <mailto:C-safe-secure-studygroup at lists.trustable.io>
>>> https://lists.trustable.io/cgi-bin/mailman/listinfo/c-safe-secure-studygroup
>>>
>>> _______________________________________________
>>> C-safe-secure-studygroup mailing list
>>> C-safe-secure-studygroup at lists.trustable.io <mailto:C-safe-secure-studygroup at lists.trustable.io>
>>> https://lists.trustable.io/cgi-bin/mailman/listinfo/c-safe-secure-studygroup
>>>
>>>
>>> _______________________________________________
>>> C-safe-secure-studygroup mailing list
>>> C-safe-secure-studygroup at lists.trustable.io
>>> https://lists.trustable.io/cgi-bin/mailman/listinfo/c-safe-secure-studygroup
>>>
>>
>>
>>
>> _______________________________________________
>> C-safe-secure-studygroup mailing list
>> C-safe-secure-studygroup at lists.trustable.io
>> https://lists.trustable.io/cgi-bin/mailman/listinfo/c-safe-secure-studygroup
>>
>
--
Prof. Roberto Bagnara
Applied Formal Methods Laboratory - University of Parma, Italy
mailto:bagnara at cs.unipr.it
BUGSENG srl - http://bugseng.com
mailto:roberto.bagnara at bugseng.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2093 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://lists.trustable.io/pipermail/c-safe-secure-studygroup/attachments/20181128/9f26d824/attachment-0001.bin>
More information about the C-safe-secure-studygroup
mailing list