
Vulnerabilities Induced by Migrating to 64-Bit Platforms [pdf] - ingve
https://www.tu-braunschweig.de/Medien-DB/sec/pubs/2016-ccs.pdf
======
vardump
I thought these issues are obvious by now.

Some typical points to consider:

1) Never store a length as an _int_ , _unsigned_ , _long_ , etc. Use _size_t_
(or _ssize_t_ ) instead.

2) Never store a pointer as an _int_ , _unsigned_ , _long_ , etc. Use
_uintptr_t_ (or _intptr_t_ ). _ptrdiff_t_ is the type to use for pointer
differencing.

3) When comparing or casting to a signed type, watch out for sign extension.
For example ( _short_ ) -1 (0xffff) becomes 2^32-1 (0xffffffff) when casted to
_uint32_t_. Remember _char_ is usually a signed type.

4) Some legacy library functions return _int_ , which is a signed 32-bit value
in Windows and Linux (remember point 3). Watch out for these cases. For
example don't use ftell and check s[n]printf return value.

~~~
jibsen
It's worth noting that ssize_t is a POSIX type, and is only guaranteed to have
the range [-1, SSIZE_MAX] (basically a size type with one error value) [1]. If
you need negative sizes, then ptrdiff_t is perhaps better.

[1]:
[http://pubs.opengroup.org/onlinepubs/009696699/basedefs/sys/...](http://pubs.opengroup.org/onlinepubs/009696699/basedefs/sys/types.h.html)

~~~
vardump
Thanks for the correction!

> only guaranteed to have the range [-1, SSIZE_MAX]

Oh, that's a weird type. I wonder if any compiler implementation encodes it
with -1 bias, so that all bits 0 means "-1".

It could cause a disaster if/when ssize_t is encoded as anything else but
standard twos complement signed number...

~~~
colejohnson66
I'd assume it's just an unsigned number with 0xFF... representing -1. So
counting would go (assuming 8 bits)

    
    
        0xFC SSIZE_MAX - 2
        0xFD SSIZE_MAX - 1
        0xFE SIZE_MAX
        0xFF -1
    

That makes more sense to me than a bias that the compiler would have to know
about.

------
userbinator
32-bit is relatively nice because ints, longs, and pointers are all the same
size; that was also one of the main motivators in the 16-to-32 transition era,
since the relative size of an int and a pointer did not change. The same thing
didn't happen with the x86 transition to 64-bit, because it would effectively
double the memory usage of every program even if it never needed such widths.

The "bitness" of a platform has always seemed to be a bit of a vague term to
me; sometimes it refers to data width, sometimes it refers to address width,
and sometimes a combination of both and neither. If we refer to data width,
then the 8087 was already "80-bit" (FP) or "64-bit" (integers) and the latest
CPUs with AVX512 are "512-bit". If we refer to address width, then the
8086/8088 are "20-bit" machines, the 80286 "24-bit", and P6 "36-bit".

I think a lot of this confusion and the vulnerabilities thus introduced are
precisely because the relative sizes of the different types have changed, and
exactly how they changed is not consistent across platforms nor clearly known
to most programmers.

~~~
gok
Well we could have just done ILP64, where all three are the same size, and
that would have avoided a lot of 32 bit truncation bugs. The memory size
argument never really made sense to me; there just aren't that many ints in
the average program. I wonder how much of the push towards LP64 (ints are 32
bits, pointers and longs are 64) was to match Java.

I think this is one place where Swift (among other modern languages) has it
right. Int is pointer sized and the other integer types are explicitly sized
in their name ("Int64" not "long").

~~~
danarmak
Why are 64bit pointers needed to match Java? Why not 32bit pointers and a
64bit long? Java APIs very rarely expose pointers anyway (e.g. in NIO).

~~~
hga
While it doesn't look like it's true anymore
([http://www.oracle.com/technetwork/java/hotspotfaq-138619.htm...](http://www.oracle.com/technetwork/java/hotspotfaq-138619.html#64bit_description)),
I sure seem to remember the Hotspot JVM having an option for 32 bit pointers
for ... code, I think it was. Since few apps would need more than 4 GiB of
code. And as you note, as the FAQ notes, this doesn't change much for most
programming.

~~~
MrBuddyCasino
I think you mean this:
[http://docs.oracle.com/javase/7/docs/technotes/guides/vm/per...](http://docs.oracle.com/javase/7/docs/technotes/guides/vm/performance-
enhancements-7.html#compressedOop)

~~~
hga
Yeah, that sounds like it, and it's at the right time.

------
0xcde4c3db
I've read that catching stuff like this is a major reason that OpenBSD
maintains (e.g.) SPARC64 support. Due to differences in MMU architectures,
addressing modes, alignment requirements, etc., this kind of problem will
often end up throwing an exception rather than silently doing almost-the-
right-thing-usually.

~~~
aomix
Yep, here's a brief overview of that from 2007
[https://youtu.be/NJ9Jml0GBPk?t=1937](https://youtu.be/NJ9Jml0GBPk?t=1937) .
SPARC64 is a favorite of this developer because it's some Alice in Wonderland
stuff where up is down and left is right compared to other architectures. So
it exposes a number of bugs that others don't.

Bugs exposed by moving to different architectures are fascinating. They always
originate from assumptions that just happen to work on the architecture they
were designed on. But when you go to a different arch they go from being sort
of harmlessly incorrect to crash and burn type of incorrect. Or, infinitely
worse, a sort of works but not in the way you expect it situation.

------
marcoperaza
Actual title: _Twice the Bits, Twice the Trouble_

Better title: _Double the Bits, Double the Trouble_

Might seem stupid, but something like that can play a big role in
memorability. I don't think we'd all remember "Smashing the Stack for Fun and
Profit" by name if it didn't have such a delicious title.

~~~
ludamad
Why do you think that's a better title?

~~~
marcoperaza
"Double [the] trouble" is a somewhat common idiomatic phrase. It rhymes
"double" with "trouble", and the word "double" has a pleasant ring to it in
its own right.

~~~
Razengan
Yes, it has a nice woody quality, "twice" is too _tinny._

