Re: 'Portable' Measurement of Pointer Alignment in C?

"Peter Nilsson" <airia@xxxxxxxxxxx> wrote in message news:1174951619.380790.175610@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
"Brian Gladman" <b...@xxxxxxxxxxx> wrote:
A lot of low level cryptographic code and some hardware
cryptographic accelerators either fail completely or perform
very poorly if their input, output and/or key storage areas in
memory are not aligned on specific memory boundaries. Moreover,
in many situations the cryptographic code does not itself have
control over the memory alignment of its parameters

Why should it?

It shouldn't necessarily. Nor did I claim, or even imply, that it should.

so the best it can do is to detect if these aligmments are
correct and act accordingly.

Why should it bother?

Because this helps to avoid application failures or preserve an application's performance in a number of practical situations.

This hence rasises the question of the most appropriate way of
determining the memory alignment of the memory referenced by a
pointer in C.

No, it raises the question of how the calling code can supply
aligned data. The answer to that is through malloc.

In some practical situiations it is not possible for the calling code to use malloc. In other cases, even though buffer base addresses have been aligned, it may not be easy (or even possible) to ensure the alignment of the addresses passed to the cryptographic code since encryption may be needed on only the upper part of an allocated buffer and timing constraints may prevent realignment by copying. It may hence be preferable to accept slower encryption in such cases provided that aligned cases proceed at full speed.

The most appropriate coding level at which alignment issues should be handled is dependent on the specific nature of the application in question. Nevertheless it is certainly true that where alignment is needed (or highly desirable), this should be specified as a part of the API for the cryptographic code in question. I take this as read.

But even in such situations I have many real examples of applications that have failed in unpredictable ways because this requirement has not been met even though it has been clearly stated. In such cases, the detection of misaligned addresses can provide for controlled failures in place of the unpredictable and uncontrolled failures that could otherwise result.

This is known as 'defensive programming' and is an important aspect of the design for secure information systems. Asking others to only use aligned pointers in calls and then not checking that they have done this is _certain_ to result in unpredictable applications failures if the cryptographic code in question is widely deployed. You may be comfortable in being able to claim that this is someone else's fault but I am not.

Here I am less interested in the 'political' correctness of C
code but rather in which methods are most likely to work in
practice on the highest proportion of widely deployed processors
and C compilers.

In other words you don't give a rat's about portable programming. ;)
Your loss really.

You should list what _you_ call 'widely deployed processors'
and ask in the appropriate forums. Note that embedded chips are
more widely deployed than desktop cpus.

Which is exactly why I am happy with the way I phrased the question (the answer is easy for desktop cpus).

<snip> ... on what proportion of systems will: ...
<snip> ... on systems that allow for the declaration of
aligned variables, ...
<snip> ... To what extent is this likely to depend on...
<snip> ... on what proportion of 'current' systems is...

I would much appreciate knowing of any experiences that people
here have on the practical portability

No you're not. You've clearly stated you'd prefer a non-portable
solution.

Your claim about my lack of sincerity in asking this question reflects more on you than it does on me.

You're looking for a fix. But it's not a fix to the actual problem,
it's a fix to a poor solution.

You are wrong. You evidently lack the practical experience needed to fully understand the issue that I have raised.

Brian Gladman

.

Relevant Pages

  • Portable Measurement of Pointer Alignment in C?
    ... A lot of low level cryptographic code and some hardware cryptographic accelerators either fail completely or perform very poorly if their input, output and key storage areas in memory are not aligned on specific memory boundaries. ... in many situations the cryptographic code does not itself have any control over the memory alignment of its parameters so the best it can do is to detect if these aligmments are correct and act accordingly. ... This hence rasises the question of the most appropriate way of determining the aligment of a pointer. ...
    (comp.lang.c.moderated)
  • Re: What factors influence required memory alignment?
    ... preventing such alignment on DOUBLE PRECISION operands. ... point values are packed into a single register and/or memory location. ... The ability to trap misaligned accesses was added to various x86 ... Its slightly easier to catch bugs when an odd address read immediately ...
    (comp.arch)
  • Re: [PATCH] Mantaining turnstile aligned to 128 bytes in i386 CPUs
    ... raw memory bandwidth is governed by RAS cycles. ... This means that the more data you can load into the cpu on the 'read' ... Alignment is critical. ...
    (freebsd-arch)
  • Re: [PATCH] Mantaining turnstile aligned to 128 bytes in i386 CPUs
    ... raw memory bandwidth is governed by RAS cycles. ... This means that the more data you can load into the cpu on the 'read' ... Alignment is critical. ...
    (freebsd-current)
  • Re: traumatized by pointer casting
    ... >> When you cast the array by name to a pointer to struct, ... structure, and after the last member, just not before the first ... the entire structure a multiple of the alignment size. ... That is why the memory allocation functions malloc(), calloc, ...
    (comp.lang.c)