nhyatt/putty-source
1
0
Fork 0
mirror of https://git.tartarus.org/simon/putty.git synced 2025-01-09 17:38:00 +00:00
Code Issues Projects Releases Wiki Activity
320bf8479f
putty-source/sshsha.c

577 lines
15 KiB
C
Raw Normal View History

Initial checkin: beta 0.43 [originally from svn r11]
1999-01-08 13:02:13 +00:00
/*
Consistently use a single notation to refer to SSH protocol versions, as discussed. Use Barrett and Silverman's convention of "SSH-1" for SSH protocol version 1 and "SSH-2" for protocol 2 ("SSH1"/"SSH2" refer to ssh.com implementations in this scheme). <http://www.snailbook.com/terms.html> [originally from svn r5480]
2005-03-10 16:36:05 +00:00
* SHA1 hash algorithm. Used in SSH-2 as a MAC, and the transform is
SSH 2 support, phase 1, debugging. Currently does Diffie-Hellman and gets the same results as the server, which is a pretty good start. [originally from svn r569]
2000-09-05 14:28:17 +00:00
* also used as a `stirring' function for the PuTTY random number
* pool. Implemented directly from the specification by Simon
* Tatham.
Initial checkin: beta 0.43 [originally from svn r11]
1999-01-08 13:02:13 +00:00
*/
#include "ssh.h"
Add SHA1 implementation with new instructions SHA1-NI code is conditionally enabled if CPU supports SHA extensions. The procedure is based on Jeffrey Walton's SHA1 implementation: https://github.com/noloader/SHA-Intrinsics
2018-02-18 21:07:06 +00:00
#include <assert.h>
Access all hashes and MACs through the standard API. All the hash-specific state structures, and the functions that directly accessed them, are now local to the source files implementing the hashes themselves. Everywhere we previously used those types or functions, we're now using the standard ssh_hash or ssh2_mac API. The 'simple' functions (hmacmd5_simple, SHA_Simple etc) are now a pair of wrappers in sshauxcrypt.c, each of which takes an algorithm structure and can do the same conceptual thing regardless of what it is.
2019-01-20 16:15:14 +00:00
typedef struct SHA_State {
uint32_t h[5];
unsigned char block[64];
int blkused;
uint64_t len;
void (*sha1)(struct SHA_State * s, const unsigned char *p, int len);
BinarySink_IMPLEMENTATION;
} SHA_State;
SSH 2 support, phase 1, debugging. Currently does Diffie-Hellman and gets the same results as the server, which is a pretty good start. [originally from svn r569]
2000-09-05 14:28:17 +00:00
/* ----------------------------------------------------------------------
* Core SHA algorithm: processes 16-word blocks into a message digest.
*/
Adopt C99 <stdint.h> integer types. The annoying int64.h is completely retired, since C99 guarantees a 64-bit integer type that you can actually treat like an ordinary integer. Also, I've replaced the local typedefs uint32 and word32 (scattered through different parts of the crypto code) with the standard uint32_t.
2018-10-26 22:08:58 +00:00
#define rol(x,y) ( ((x) << (y)) | (((uint32_t)x) >> (32-y)) )
SSH 2 support, phase 1, debugging. Currently does Diffie-Hellman and gets the same results as the server, which is a pretty good start. [originally from svn r569]
2000-09-05 14:28:17 +00:00
Add pointers to SHA1 and SHA256 implementation functions These pointers will be required in next commits where subroutines with new instructions are introduced. Depending on CPUID dynamic check, pointers will refer to old SW-only implementations or to new instructions subroutines
2018-02-11 10:40:24 +00:00
static void sha1_sw(SHA_State * s, const unsigned char *q, int len);
Add SHA1 implementation with new instructions SHA1-NI code is conditionally enabled if CPU supports SHA extensions. The procedure is based on Jeffrey Walton's SHA1 implementation: https://github.com/noloader/SHA-Intrinsics
2018-02-18 21:07:06 +00:00
static void sha1_ni(SHA_State * s, const unsigned char *q, int len);
Add pointers to SHA1 and SHA256 implementation functions These pointers will be required in next commits where subroutines with new instructions are introduced. Depending on CPUID dynamic check, pointers will refer to old SW-only implementations or to new instructions subroutines
2018-02-11 10:40:24 +00:00
Adopt C99 <stdint.h> integer types. The annoying int64.h is completely retired, since C99 guarantees a 64-bit integer type that you can actually treat like an ordinary integer. Also, I've replaced the local typedefs uint32 and word32 (scattered through different parts of the crypto code) with the standard uint32_t.
2018-10-26 22:08:58 +00:00
static void SHA_Core_Init(uint32_t h[5])
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 14:35:20 +00:00
{
SSH 2 support, phase 1, debugging. Currently does Diffie-Hellman and gets the same results as the server, which is a pretty good start. [originally from svn r569]
2000-09-05 14:28:17 +00:00
h[0] = 0x67452301;
h[1] = 0xefcdab89;
h[2] = 0x98badcfe;
h[3] = 0x10325476;
h[4] = 0xc3d2e1f0;
}
Replace SHA implementation with homegrown one [originally from svn r334]
1999-12-03 11:32:50 +00:00
Adopt C99 <stdint.h> integer types. The annoying int64.h is completely retired, since C99 guarantees a 64-bit integer type that you can actually treat like an ordinary integer. Also, I've replaced the local typedefs uint32 and word32 (scattered through different parts of the crypto code) with the standard uint32_t.
2018-10-26 22:08:58 +00:00
void SHATransform(uint32_t * digest, uint32_t * block)
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 14:35:20 +00:00
{
Adopt C99 <stdint.h> integer types. The annoying int64.h is completely retired, since C99 guarantees a 64-bit integer type that you can actually treat like an ordinary integer. Also, I've replaced the local typedefs uint32 and word32 (scattered through different parts of the crypto code) with the standard uint32_t.
2018-10-26 22:08:58 +00:00
uint32_t w[80];
uint32_t a, b, c, d, e;
Replace SHA implementation with homegrown one [originally from svn r334]
1999-12-03 11:32:50 +00:00
int t;
Add some conditionally-compilable diagnostics to the RNG. I got briefly worried that it might not be doing what I thought it was doing, but examining these diagnostics shows that it is after all, and now I've written them it would be a shame not to keep them for future use. [originally from svn r9938]
2013-07-19 17:44:58 +00:00
#ifdef RANDOM_DIAGNOSTICS
{
extern int random_diagnostics;
if (random_diagnostics) {
int i;
printf("SHATransform:");
for (i = 0; i < 5; i++)
printf(" %08x", digest[i]);
printf(" +");
for (i = 0; i < 16; i++)
printf(" %08x", block[i]);
}
}
#endif
Replace SHA implementation with homegrown one [originally from svn r334]
1999-12-03 11:32:50 +00:00
for (t = 0; t < 16; t++)
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 14:35:20 +00:00
w[t] = block[t];
Replace SHA implementation with homegrown one [originally from svn r334]
1999-12-03 11:32:50 +00:00
for (t = 16; t < 80; t++) {
Adopt C99 <stdint.h> integer types. The annoying int64.h is completely retired, since C99 guarantees a 64-bit integer type that you can actually treat like an ordinary integer. Also, I've replaced the local typedefs uint32 and word32 (scattered through different parts of the crypto code) with the standard uint32_t.
2018-10-26 22:08:58 +00:00
uint32_t tmp = w[t - 3] ^ w[t - 8] ^ w[t - 14] ^ w[t - 16];
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 14:35:20 +00:00
w[t] = rol(tmp, 1);
Replace SHA implementation with homegrown one [originally from svn r334]
1999-12-03 11:32:50 +00:00
}
a = digest[0];
b = digest[1];
c = digest[2];
d = digest[3];
e = digest[4];
for (t = 0; t < 20; t++) {
Adopt C99 <stdint.h> integer types. The annoying int64.h is completely retired, since C99 guarantees a 64-bit integer type that you can actually treat like an ordinary integer. Also, I've replaced the local typedefs uint32 and word32 (scattered through different parts of the crypto code) with the standard uint32_t.
2018-10-26 22:08:58 +00:00
uint32_t tmp =
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 14:35:20 +00:00
rol(a, 5) + ((b & c) | (d & ~b)) + e + w[t] + 0x5a827999;
e = d;
d = c;
c = rol(b, 30);
b = a;
a = tmp;
Replace SHA implementation with homegrown one [originally from svn r334]
1999-12-03 11:32:50 +00:00
}
for (t = 20; t < 40; t++) {
Adopt C99 <stdint.h> integer types. The annoying int64.h is completely retired, since C99 guarantees a 64-bit integer type that you can actually treat like an ordinary integer. Also, I've replaced the local typedefs uint32 and word32 (scattered through different parts of the crypto code) with the standard uint32_t.
2018-10-26 22:08:58 +00:00
uint32_t tmp = rol(a, 5) + (b ^ c ^ d) + e + w[t] + 0x6ed9eba1;
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 14:35:20 +00:00
e = d;
d = c;
c = rol(b, 30);
b = a;
a = tmp;
Replace SHA implementation with homegrown one [originally from svn r334]
1999-12-03 11:32:50 +00:00
}
for (t = 40; t < 60; t++) {
Adopt C99 <stdint.h> integer types. The annoying int64.h is completely retired, since C99 guarantees a 64-bit integer type that you can actually treat like an ordinary integer. Also, I've replaced the local typedefs uint32 and word32 (scattered through different parts of the crypto code) with the standard uint32_t.
2018-10-26 22:08:58 +00:00
uint32_t tmp = rol(a,
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 14:35:20 +00:00
5) + ((b & c) | (b & d) | (c & d)) + e + w[t] +
0x8f1bbcdc;
e = d;
d = c;
c = rol(b, 30);
b = a;
a = tmp;
Replace SHA implementation with homegrown one [originally from svn r334]
1999-12-03 11:32:50 +00:00
}
for (t = 60; t < 80; t++) {
Adopt C99 <stdint.h> integer types. The annoying int64.h is completely retired, since C99 guarantees a 64-bit integer type that you can actually treat like an ordinary integer. Also, I've replaced the local typedefs uint32 and word32 (scattered through different parts of the crypto code) with the standard uint32_t.
2018-10-26 22:08:58 +00:00
uint32_t tmp = rol(a, 5) + (b ^ c ^ d) + e + w[t] + 0xca62c1d6;
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 14:35:20 +00:00
e = d;
d = c;
c = rol(b, 30);
b = a;
a = tmp;
Replace SHA implementation with homegrown one [originally from svn r334]
1999-12-03 11:32:50 +00:00
}
digest[0] += a;
digest[1] += b;
digest[2] += c;
digest[3] += d;
digest[4] += e;
Add some conditionally-compilable diagnostics to the RNG. I got briefly worried that it might not be doing what I thought it was doing, but examining these diagnostics shows that it is after all, and now I've written them it would be a shame not to keep them for future use. [originally from svn r9938]
2013-07-19 17:44:58 +00:00
#ifdef RANDOM_DIAGNOSTICS
{
extern int random_diagnostics;
if (random_diagnostics) {
int i;
printf(" =");
for (i = 0; i < 5; i++)
printf(" %08x", digest[i]);
printf("\n");
}
}
#endif
Initial checkin: beta 0.43 [originally from svn r11]
1999-01-08 13:02:13 +00:00
}
SSH 2 support, phase 1, debugging. Currently does Diffie-Hellman and gets the same results as the server, which is a pretty good start. [originally from svn r569]
2000-09-05 14:28:17 +00:00
/* ----------------------------------------------------------------------
* Outer SHA algorithm: take an arbitrary length byte string,
* convert it into 16-word blocks with the prescribed padding at
* the end, and pass those blocks to the core SHA algorithm.
*/
Replace all uses of SHA*_Bytes / MD5Update. In fact, those functions don't even exist any more. The only way to get data into a primitive hash state is via the new put_* system. Of course, that means put_data() is a viable replacement for every previous call to one of the per-hash update functions - but just mechanically doing that would have missed the opportunity to simplify a lot of the call sites.
2018-05-24 09:03:36 +00:00
static void SHA_BinarySink_write(BinarySink *bs, const void *p, size_t len);
New centralised binary-data marshalling system. I've finally got tired of all the code throughout PuTTY that repeats the same logic about how to format the SSH binary primitives like uint32, string, mpint. We've got reasonably organised code in ssh.c that appends things like that to 'struct Packet'; something similar in sftp.c which repeats a lot of the work; utility functions in various places to format an mpint to feed to one or another hash function; and no end of totally ad-hoc stuff in functions like public key blob formatters which actually have to _count up_ the size of data painstakingly, then malloc exactly that much and mess about with PUT_32BIT. It's time to bring all of that into one place, and stop repeating myself in error-prone ways everywhere. The new marshal.h defines a system in which I centralise all the actual marshalling functions, and then layer a touch of C macro trickery on top to allow me to (look as if I) pass a wide range of different types to those functions, as long as the target type has been set up in the right way to have a write() function. This commit adds the new header and source file, and sets up some general centralised types (strbuf and the various hash-function contexts like SHA_State), but doesn't use the new calls for anything yet. (I've also renamed some internal functions in import.c which were using the same names that I've just defined macros over. That won't last long - those functions are going to go away soon, so the changed names are strictly temporary.)
2018-05-24 08:17:13 +00:00
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 14:35:20 +00:00
void SHA_Init(SHA_State * s)
{
SSH 2 support, phase 1, debugging. Currently does Diffie-Hellman and gets the same results as the server, which is a pretty good start. [originally from svn r569]
2000-09-05 14:28:17 +00:00
SHA_Core_Init(s->h);
s->blkused = 0;
Adopt C99 <stdint.h> integer types. The annoying int64.h is completely retired, since C99 guarantees a 64-bit integer type that you can actually treat like an ordinary integer. Also, I've replaced the local typedefs uint32 and word32 (scattered through different parts of the crypto code) with the standard uint32_t.
2018-10-26 22:08:58 +00:00
s->len = 0;
Add SHA1 implementation with new instructions SHA1-NI code is conditionally enabled if CPU supports SHA extensions. The procedure is based on Jeffrey Walton's SHA1 implementation: https://github.com/noloader/SHA-Intrinsics
2018-02-18 21:07:06 +00:00
if (supports_sha_ni())
s->sha1 = &sha1_ni;
else
s->sha1 = &sha1_sw;
New centralised binary-data marshalling system. I've finally got tired of all the code throughout PuTTY that repeats the same logic about how to format the SSH binary primitives like uint32, string, mpint. We've got reasonably organised code in ssh.c that appends things like that to 'struct Packet'; something similar in sftp.c which repeats a lot of the work; utility functions in various places to format an mpint to feed to one or another hash function; and no end of totally ad-hoc stuff in functions like public key blob formatters which actually have to _count up_ the size of data painstakingly, then malloc exactly that much and mess about with PUT_32BIT. It's time to bring all of that into one place, and stop repeating myself in error-prone ways everywhere. The new marshal.h defines a system in which I centralise all the actual marshalling functions, and then layer a touch of C macro trickery on top to allow me to (look as if I) pass a wide range of different types to those functions, as long as the target type has been set up in the right way to have a write() function. This commit adds the new header and source file, and sets up some general centralised types (strbuf and the various hash-function contexts like SHA_State), but doesn't use the new calls for anything yet. (I've also renamed some internal functions in import.c which were using the same names that I've just defined macros over. That won't last long - those functions are going to go away soon, so the changed names are strictly temporary.)
2018-05-24 08:17:13 +00:00
BinarySink_INIT(s, SHA_BinarySink_write);
SSH 2 support, phase 1, debugging. Currently does Diffie-Hellman and gets the same results as the server, which is a pretty good start. [originally from svn r569]
2000-09-05 14:28:17 +00:00
}
Replace all uses of SHA*_Bytes / MD5Update. In fact, those functions don't even exist any more. The only way to get data into a primitive hash state is via the new put_* system. Of course, that means put_data() is a viable replacement for every previous call to one of the per-hash update functions - but just mechanically doing that would have missed the opportunity to simplify a lot of the call sites.
2018-05-24 09:03:36 +00:00
static void SHA_BinarySink_write(BinarySink *bs, const void *p, size_t len)
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 14:35:20 +00:00
{
Replace all uses of SHA*_Bytes / MD5Update. In fact, those functions don't even exist any more. The only way to get data into a primitive hash state is via the new put_* system. Of course, that means put_data() is a viable replacement for every previous call to one of the per-hash update functions - but just mechanically doing that would have missed the opportunity to simplify a lot of the call sites.
2018-05-24 09:03:36 +00:00
struct SHA_State *s = BinarySink_DOWNCAST(bs, struct SHA_State);
Add an assortment of missing consts I've just noticed. [originally from svn r9972]
2013-07-27 18:35:48 +00:00
const unsigned char *q = (const unsigned char *) p;
SSH 2 support, phase 1, debugging. Currently does Diffie-Hellman and gets the same results as the server, which is a pretty good start. [originally from svn r569]
2000-09-05 14:28:17 +00:00
/*
* Update the length field.
*/
Adopt C99 <stdint.h> integer types. The annoying int64.h is completely retired, since C99 guarantees a 64-bit integer type that you can actually treat like an ordinary integer. Also, I've replaced the local typedefs uint32 and word32 (scattered through different parts of the crypto code) with the standard uint32_t.
2018-10-26 22:08:58 +00:00
s->len += len;
Add pointers to SHA1 and SHA256 implementation functions These pointers will be required in next commits where subroutines with new instructions are introduced. Depending on CPUID dynamic check, pointers will refer to old SW-only implementations or to new instructions subroutines
2018-02-11 10:40:24 +00:00
(*(s->sha1))(s, q, len);
}
static void sha1_sw(SHA_State * s, const unsigned char *q, int len)
{
Adopt C99 <stdint.h> integer types. The annoying int64.h is completely retired, since C99 guarantees a 64-bit integer type that you can actually treat like an ordinary integer. Also, I've replaced the local typedefs uint32 and word32 (scattered through different parts of the crypto code) with the standard uint32_t.
2018-10-26 22:08:58 +00:00
uint32_t wordblock[16];
Add pointers to SHA1 and SHA256 implementation functions These pointers will be required in next commits where subroutines with new instructions are introduced. Depending on CPUID dynamic check, pointers will refer to old SW-only implementations or to new instructions subroutines
2018-02-11 10:40:24 +00:00
int i;
SSH 2 support, phase 1, debugging. Currently does Diffie-Hellman and gets the same results as the server, which is a pretty good start. [originally from svn r569]
2000-09-05 14:28:17 +00:00
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 14:35:20 +00:00
if (s->blkused && s->blkused + len < 64) {
/*
* Trivial case: just add to the block.
*/
memcpy(s->block + s->blkused, q, len);
s->blkused += len;
SSH 2 support, phase 1, debugging. Currently does Diffie-Hellman and gets the same results as the server, which is a pretty good start. [originally from svn r569]
2000-09-05 14:28:17 +00:00
} else {
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 14:35:20 +00:00
/*
* We must complete and process at least one block.
*/
while (s->blkused + len >= 64) {
memcpy(s->block + s->blkused, q, 64 - s->blkused);
q += 64 - s->blkused;
len -= 64 - s->blkused;
/* Now process the block. Gather bytes big-endian into words */
for (i = 0; i < 16; i++) {
wordblock[i] =
Adopt C99 <stdint.h> integer types. The annoying int64.h is completely retired, since C99 guarantees a 64-bit integer type that you can actually treat like an ordinary integer. Also, I've replaced the local typedefs uint32 and word32 (scattered through different parts of the crypto code) with the standard uint32_t.
2018-10-26 22:08:58 +00:00
(((uint32_t) s->block[i * 4 + 0]) << 24) |
(((uint32_t) s->block[i * 4 + 1]) << 16) |
(((uint32_t) s->block[i * 4 + 2]) << 8) |
(((uint32_t) s->block[i * 4 + 3]) << 0);
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 14:35:20 +00:00
}
SHATransform(s->h, wordblock);
s->blkused = 0;
}
memcpy(s->block, q, len);
s->blkused = len;
SSH 2 support, phase 1, debugging. Currently does Diffie-Hellman and gets the same results as the server, which is a pretty good start. [originally from svn r569]
2000-09-05 14:28:17 +00:00
}
}
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 14:35:20 +00:00
void SHA_Final(SHA_State * s, unsigned char *output)
{
SSH 2 support, phase 1, debugging. Currently does Diffie-Hellman and gets the same results as the server, which is a pretty good start. [originally from svn r569]
2000-09-05 14:28:17 +00:00
int i;
int pad;
unsigned char c[64];
Adopt C99 <stdint.h> integer types. The annoying int64.h is completely retired, since C99 guarantees a 64-bit integer type that you can actually treat like an ordinary integer. Also, I've replaced the local typedefs uint32 and word32 (scattered through different parts of the crypto code) with the standard uint32_t.
2018-10-26 22:08:58 +00:00
uint64_t len;
SSH 2 support, phase 1, debugging. Currently does Diffie-Hellman and gets the same results as the server, which is a pretty good start. [originally from svn r569]
2000-09-05 14:28:17 +00:00
if (s->blkused >= 56)
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 14:35:20 +00:00
pad = 56 + 64 - s->blkused;
SSH 2 support, phase 1, debugging. Currently does Diffie-Hellman and gets the same results as the server, which is a pretty good start. [originally from svn r569]
2000-09-05 14:28:17 +00:00
else
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 14:35:20 +00:00
pad = 56 - s->blkused;
SSH 2 support, phase 1, debugging. Currently does Diffie-Hellman and gets the same results as the server, which is a pretty good start. [originally from svn r569]
2000-09-05 14:28:17 +00:00
Adopt C99 <stdint.h> integer types. The annoying int64.h is completely retired, since C99 guarantees a 64-bit integer type that you can actually treat like an ordinary integer. Also, I've replaced the local typedefs uint32 and word32 (scattered through different parts of the crypto code) with the standard uint32_t.
2018-10-26 22:08:58 +00:00
len = (s->len << 3);
SSH 2 support, phase 1, debugging. Currently does Diffie-Hellman and gets the same results as the server, which is a pretty good start. [originally from svn r569]
2000-09-05 14:28:17 +00:00
memset(c, 0, pad);
c[0] = 0x80;
Replace all uses of SHA*_Bytes / MD5Update. In fact, those functions don't even exist any more. The only way to get data into a primitive hash state is via the new put_* system. Of course, that means put_data() is a viable replacement for every previous call to one of the per-hash update functions - but just mechanically doing that would have missed the opportunity to simplify a lot of the call sites.
2018-05-24 09:03:36 +00:00
put_data(s, &c, pad);
SSH 2 support, phase 1, debugging. Currently does Diffie-Hellman and gets the same results as the server, which is a pretty good start. [originally from svn r569]
2000-09-05 14:28:17 +00:00
Adopt C99 <stdint.h> integer types. The annoying int64.h is completely retired, since C99 guarantees a 64-bit integer type that you can actually treat like an ordinary integer. Also, I've replaced the local typedefs uint32 and word32 (scattered through different parts of the crypto code) with the standard uint32_t.
2018-10-26 22:08:58 +00:00
put_uint64(s, len);
SSH 2 support, phase 1, debugging. Currently does Diffie-Hellman and gets the same results as the server, which is a pretty good start. [originally from svn r569]
2000-09-05 14:28:17 +00:00
for (i = 0; i < 5; i++) {
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 14:35:20 +00:00
output[i * 4] = (s->h[i] >> 24) & 0xFF;
output[i * 4 + 1] = (s->h[i] >> 16) & 0xFF;
output[i * 4 + 2] = (s->h[i] >> 8) & 0xFF;
output[i * 4 + 3] = (s->h[i]) & 0xFF;
SSH 2 support, phase 1, debugging. Currently does Diffie-Hellman and gets the same results as the server, which is a pretty good start. [originally from svn r569]
2000-09-05 14:28:17 +00:00
}
}
Add an assortment of missing consts I've just noticed. [originally from svn r9972]
2013-07-27 18:35:48 +00:00
void SHA_Simple(const void *p, int len, unsigned char *output)
Run entire source base through GNU indent to tidy up the varying coding styles of the various contributors! Woohoo! [originally from svn r1098]
2001-05-06 14:35:20 +00:00
{
SSH 2 support, phase 1, debugging. Currently does Diffie-Hellman and gets the same results as the server, which is a pretty good start. [originally from svn r569]
2000-09-05 14:28:17 +00:00
SHA_State s;
SHA_Init(&s);
Replace all uses of SHA*_Bytes / MD5Update. In fact, those functions don't even exist any more. The only way to get data into a primitive hash state is via the new put_* system. Of course, that means put_data() is a viable replacement for every previous call to one of the per-hash update functions - but just mechanically doing that would have missed the opportunity to simplify a lot of the call sites.
2018-05-24 09:03:36 +00:00
put_data(&s, p, len);
SSH 2 support, phase 1, debugging. Currently does Diffie-Hellman and gets the same results as the server, which is a pretty good start. [originally from svn r569]
2000-09-05 14:28:17 +00:00
SHA_Final(&s, output);
Add smemclrs of all hash states we destroy.
2015-04-26 22:55:33 +00:00
smemclr(&s, sizeof(s));
SSH 2 support, phase 1, debugging. Currently does Diffie-Hellman and gets the same results as the server, which is a pretty good start. [originally from svn r569]
2000-09-05 14:28:17 +00:00
}
Add infrastructure for supporting multiple hashes in key exchange. Nothing very surprising here. [originally from svn r6251]
2005-08-31 20:43:06 +00:00
/*
* Thin abstraction for things where hashes are pluggable.
*/
Turn SSH hashes into a classoid. The new version of ssh_hash has the same nice property as ssh2_mac, that I can make the generic interface object type function directly as a BinarySink so that clients don't have to call h->sink() and worry about the separate sink object they get back from that.
2018-09-13 15:41:46 +00:00
struct sha1_hash {
SHA_State state;
ssh_hash hash;
};
Add infrastructure for supporting multiple hashes in key exchange. Nothing very surprising here. [originally from svn r6251]
2005-08-31 20:43:06 +00:00
Remove a lot of pointless 'struct' keywords. This is the commit that f3295e0fb _should_ have been. Yesterday I just added some typedefs so that I didn't have to wear out my fingers typing 'struct' in new code, but what I ought to have done is to move all the typedefs into defs.h with the rest, and then go through cleaning up the legacy 'struct's all through the existing code. But I was mostly trying to concentrate on getting the test suite finished, so I just did the minimum. Now it's time to come back and do it better.
2019-01-04 06:51:44 +00:00
static ssh_hash *sha1_new(const ssh_hashalg *alg)
Turn SSH hashes into a classoid. The new version of ssh_hash has the same nice property as ssh2_mac, that I can make the generic interface object type function directly as a BinarySink so that clients don't have to call h->sink() and worry about the separate sink object they get back from that.
2018-09-13 15:41:46 +00:00
{
struct sha1_hash *h = snew(struct sha1_hash);
SHA_Init(&h->state);
h->hash.vt = alg;
BinarySink_DELEGATE_INIT(&h->hash, &h->state);
return &h->hash;
Add infrastructure for supporting multiple hashes in key exchange. Nothing very surprising here. [originally from svn r6251]
2005-08-31 20:43:06 +00:00
}
Turn SSH hashes into a classoid. The new version of ssh_hash has the same nice property as ssh2_mac, that I can make the generic interface object type function directly as a BinarySink so that clients don't have to call h->sink() and worry about the separate sink object they get back from that.
2018-09-13 15:41:46 +00:00
static ssh_hash *sha1_copy(ssh_hash *hashold)
Add copy and free methods to 'struct ssh_hash'. This permits a hash state to be cloned in the middle of being used, so that multiple strings with the same prefix can be hashed without having to repeat all the computation over the prefix. Having done that, we'll also sometimes need to free a hash state that we aren't generating actual hash output from, so we need a free method as well.
2015-08-21 22:13:59 +00:00
{
Turn SSH hashes into a classoid. The new version of ssh_hash has the same nice property as ssh2_mac, that I can make the generic interface object type function directly as a BinarySink so that clients don't have to call h->sink() and worry about the separate sink object they get back from that.
2018-09-13 15:41:46 +00:00
struct sha1_hash *hold, *hnew;
ssh_hash *hashnew = sha1_new(hashold->vt);
Add copy and free methods to 'struct ssh_hash'. This permits a hash state to be cloned in the middle of being used, so that multiple strings with the same prefix can be hashed without having to repeat all the computation over the prefix. Having done that, we'll also sometimes need to free a hash state that we aren't generating actual hash output from, so we need a free method as well.
2015-08-21 22:13:59 +00:00
Rename FROMFIELD to 'container_of'. Ian Jackson points out that the Linux kernel has a macro of this name with the same purpose, and suggests that it's a good idea to use the same name as they do, so that at least some people reading one code base might recognise it from the other. I never really thought very hard about what order FROMFIELD's parameters should go in, and therefore I'm pleasantly surprised to find that my order agrees with the kernel's, so I don't have to permute every call site as part of making this change :-)
2018-10-05 22:49:08 +00:00
hold = container_of(hashold, struct sha1_hash, hash);
hnew = container_of(hashnew, struct sha1_hash, hash);
Add copy and free methods to 'struct ssh_hash'. This permits a hash state to be cloned in the middle of being used, so that multiple strings with the same prefix can be hashed without having to repeat all the computation over the prefix. Having done that, we'll also sometimes need to free a hash state that we aren't generating actual hash output from, so we need a free method as well.
2015-08-21 22:13:59 +00:00
Turn SSH hashes into a classoid. The new version of ssh_hash has the same nice property as ssh2_mac, that I can make the generic interface object type function directly as a BinarySink so that clients don't have to call h->sink() and worry about the separate sink object they get back from that.
2018-09-13 15:41:46 +00:00
hnew->state = hold->state;
BinarySink_COPIED(&hnew->state);
Add copy and free methods to 'struct ssh_hash'. This permits a hash state to be cloned in the middle of being used, so that multiple strings with the same prefix can be hashed without having to repeat all the computation over the prefix. Having done that, we'll also sometimes need to free a hash state that we aren't generating actual hash output from, so we need a free method as well.
2015-08-21 22:13:59 +00:00
Turn SSH hashes into a classoid. The new version of ssh_hash has the same nice property as ssh2_mac, that I can make the generic interface object type function directly as a BinarySink so that clients don't have to call h->sink() and worry about the separate sink object they get back from that.
2018-09-13 15:41:46 +00:00
return hashnew;
Add copy and free methods to 'struct ssh_hash'. This permits a hash state to be cloned in the middle of being used, so that multiple strings with the same prefix can be hashed without having to repeat all the computation over the prefix. Having done that, we'll also sometimes need to free a hash state that we aren't generating actual hash output from, so we need a free method as well.
2015-08-21 22:13:59 +00:00
}
Turn SSH hashes into a classoid. The new version of ssh_hash has the same nice property as ssh2_mac, that I can make the generic interface object type function directly as a BinarySink so that clients don't have to call h->sink() and worry about the separate sink object they get back from that.
2018-09-13 15:41:46 +00:00
static void sha1_free(ssh_hash *hash)
Add infrastructure for supporting multiple hashes in key exchange. Nothing very surprising here. [originally from svn r6251]
2005-08-31 20:43:06 +00:00
{
Rename FROMFIELD to 'container_of'. Ian Jackson points out that the Linux kernel has a macro of this name with the same purpose, and suggests that it's a good idea to use the same name as they do, so that at least some people reading one code base might recognise it from the other. I never really thought very hard about what order FROMFIELD's parameters should go in, and therefore I'm pleasantly surprised to find that my order agrees with the kernel's, so I don't have to permute every call site as part of making this change :-)
2018-10-05 22:49:08 +00:00
struct sha1_hash *h = container_of(hash, struct sha1_hash, hash);
Turn SSH hashes into a classoid. The new version of ssh_hash has the same nice property as ssh2_mac, that I can make the generic interface object type function directly as a BinarySink so that clients don't have to call h->sink() and worry about the separate sink object they get back from that.
2018-09-13 15:41:46 +00:00
smemclr(h, sizeof(*h));
sfree(h);
Add infrastructure for supporting multiple hashes in key exchange. Nothing very surprising here. [originally from svn r6251]
2005-08-31 20:43:06 +00:00
}
Turn SSH hashes into a classoid. The new version of ssh_hash has the same nice property as ssh2_mac, that I can make the generic interface object type function directly as a BinarySink so that clients don't have to call h->sink() and worry about the separate sink object they get back from that.
2018-09-13 15:41:46 +00:00
static void sha1_final(ssh_hash *hash, unsigned char *output)
Add infrastructure for supporting multiple hashes in key exchange. Nothing very surprising here. [originally from svn r6251]
2005-08-31 20:43:06 +00:00
{
Rename FROMFIELD to 'container_of'. Ian Jackson points out that the Linux kernel has a macro of this name with the same purpose, and suggests that it's a good idea to use the same name as they do, so that at least some people reading one code base might recognise it from the other. I never really thought very hard about what order FROMFIELD's parameters should go in, and therefore I'm pleasantly surprised to find that my order agrees with the kernel's, so I don't have to permute every call site as part of making this change :-)
2018-10-05 22:49:08 +00:00
struct sha1_hash *h = container_of(hash, struct sha1_hash, hash);
Turn SSH hashes into a classoid. The new version of ssh_hash has the same nice property as ssh2_mac, that I can make the generic interface object type function directly as a BinarySink so that clients don't have to call h->sink() and worry about the separate sink object they get back from that.
2018-09-13 15:41:46 +00:00
SHA_Final(&h->state, output);
sha1_free(hash);
Add infrastructure for supporting multiple hashes in key exchange. Nothing very surprising here. [originally from svn r6251]
2005-08-31 20:43:06 +00:00
}
Remove a lot of pointless 'struct' keywords. This is the commit that f3295e0fb _should_ have been. Yesterday I just added some typedefs so that I didn't have to wear out my fingers typing 'struct' in new code, but what I ought to have done is to move all the typedefs into defs.h with the rest, and then go through cleaning up the legacy 'struct's all through the existing code. But I was mostly trying to concentrate on getting the test suite finished, so I just did the minimum. Now it's time to come back and do it better.
2019-01-04 06:51:44 +00:00
const ssh_hashalg ssh_sha1 = {
Expose blocklen in the ssh_hash structure. Keeping that information alongside the hashes themselves seems more sensible than having the HMAC code know that fact about everything it can work with.
2019-01-21 19:04:22 +00:00
sha1_new, sha1_copy, sha1_final, sha1_free, 20, 64, "SHA-1"
Add infrastructure for supporting multiple hashes in key exchange. Nothing very surprising here. [originally from svn r6251]
2005-08-31 20:43:06 +00:00
};
Add supports_sha_ni(void) function It executes CPUID instruction to check whether SHA extensions are supported by hosting CPU.
2018-02-18 21:06:14 +00:00
#ifdef COMPILER_SUPPORTS_SHA_NI
Include <intrin.h> for hardware SHA on Windows Fixes failure to build under Windows with Visual Studio 14.
2018-04-13 03:20:52 +00:00
#if defined _MSC_VER && defined _M_AMD64
# include <intrin.h>
#endif
Add supports_sha_ni(void) function It executes CPUID instruction to check whether SHA extensions are supported by hosting CPU.
2018-02-18 21:06:14 +00:00
/*
* Set target architecture for Clang and GCC
*/
#if !defined(__clang__) && defined(__GNUC__)
# pragma GCC target("sha")
# pragma GCC target("sse4.1")
#endif
#if defined(__clang__) || (defined(__GNUC__) && (__GNUC__ >= 5))
# define FUNC_ISA __attribute__ ((target("sse4.1,sha")))
#else
# define FUNC_ISA
#endif
Add SHA1 implementation with new instructions SHA1-NI code is conditionally enabled if CPU supports SHA extensions. The procedure is based on Jeffrey Walton's SHA1 implementation: https://github.com/noloader/SHA-Intrinsics
2018-02-18 21:07:06 +00:00
#include <wmmintrin.h>
#include <smmintrin.h>
#include <immintrin.h>
#if defined(__clang__) || defined(__GNUC__)
#include <shaintrin.h>
#endif
Add supports_sha_ni(void) function It executes CPUID instruction to check whether SHA extensions are supported by hosting CPU.
2018-02-18 21:06:14 +00:00
/*
* Determinators of CPU type
*/
#if defined(__clang__) || defined(__GNUC__)
#include <cpuid.h>
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
bool supports_sha_ni(void)
Add supports_sha_ni(void) function It executes CPUID instruction to check whether SHA extensions are supported by hosting CPU.
2018-02-18 21:06:14 +00:00
{
unsigned int CPUInfo[4];
Add CPUID leaf checks prior to SHA checks Some old CPUs do not support CPUID to be called with eax=7 To prevent failures, call CPUID with eax=0 to get the highest possible eax value (leaf) and compare it to 7. GCC does this check internally with __get_cpuid_count function Thanks to Jeffrey Walton for noticing.
2018-03-22 18:57:38 +00:00
__cpuid(0, CPUInfo[0], CPUInfo[1], CPUInfo[2], CPUInfo[3]);
if (CPUInfo[0] < 7)
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
return false;
Add CPUID leaf checks prior to SHA checks Some old CPUs do not support CPUID to be called with eax=7 To prevent failures, call CPUID with eax=0 to get the highest possible eax value (leaf) and compare it to 7. GCC does this check internally with __get_cpuid_count function Thanks to Jeffrey Walton for noticing.
2018-03-22 18:57:38 +00:00
Add supports_sha_ni(void) function It executes CPUID instruction to check whether SHA extensions are supported by hosting CPU.
2018-02-18 21:06:14 +00:00
__cpuid_count(7, 0, CPUInfo[0], CPUInfo[1], CPUInfo[2], CPUInfo[3]);
return CPUInfo[1] & (1 << 29); /* SHA */
}
#else /* defined(__clang__) || defined(__GNUC__) */
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
bool supports_sha_ni(void)
Add supports_sha_ni(void) function It executes CPUID instruction to check whether SHA extensions are supported by hosting CPU.
2018-02-18 21:06:14 +00:00
{
unsigned int CPUInfo[4];
Add CPUID leaf checks prior to SHA checks Some old CPUs do not support CPUID to be called with eax=7 To prevent failures, call CPUID with eax=0 to get the highest possible eax value (leaf) and compare it to 7. GCC does this check internally with __get_cpuid_count function Thanks to Jeffrey Walton for noticing.
2018-03-22 18:57:38 +00:00
__cpuid(CPUInfo, 0);
if (CPUInfo[0] < 7)
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
return false;
Add CPUID leaf checks prior to SHA checks Some old CPUs do not support CPUID to be called with eax=7 To prevent failures, call CPUID with eax=0 to get the highest possible eax value (leaf) and compare it to 7. GCC does this check internally with __get_cpuid_count function Thanks to Jeffrey Walton for noticing.
2018-03-22 18:57:38 +00:00
Add supports_sha_ni(void) function It executes CPUID instruction to check whether SHA extensions are supported by hosting CPU.
2018-02-18 21:06:14 +00:00
__cpuidex(CPUInfo, 7, 0);
return CPUInfo[1] & (1 << 29); /* Check SHA */
}
#endif /* defined(__clang__) || defined(__GNUC__) */
Add SHA1 implementation with new instructions SHA1-NI code is conditionally enabled if CPU supports SHA extensions. The procedure is based on Jeffrey Walton's SHA1 implementation: https://github.com/noloader/SHA-Intrinsics
2018-02-18 21:07:06 +00:00
/* SHA1 implementation using new instructions
The code is based on Jeffrey Walton's SHA1 implementation:
https://github.com/noloader/SHA-Intrinsics
*/
FUNC_ISA
Work around LLVM bug 34980 Clang generates an internal failure if the same function has different target attributes in definition and declaration. To work around that, we made a proxy predeclared function without target attribute.
2018-02-18 13:48:44 +00:00
static void sha1_ni_(SHA_State * s, const unsigned char *q, int len)
Add SHA1 implementation with new instructions SHA1-NI code is conditionally enabled if CPU supports SHA extensions. The procedure is based on Jeffrey Walton's SHA1 implementation: https://github.com/noloader/SHA-Intrinsics
2018-02-18 21:07:06 +00:00
{
if (s->blkused && s->blkused + len < 64) {
/*
* Trivial case: just add to the block.
*/
memcpy(s->block + s->blkused, q, len);
s->blkused += len;
} else {
__m128i ABCD, ABCD_SAVE, E0, E0_SAVE, E1;
const __m128i MASK = _mm_set_epi64x(0x0001020304050607ULL, 0x08090a0b0c0d0e0fULL);
ABCD = _mm_loadu_si128((const __m128i*) s->h);
E0 = _mm_set_epi32(s->h[4], 0, 0, 0);
ABCD = _mm_shuffle_epi32(ABCD, 0x1B);
/*
* We must complete and process at least one block.
*/
while (s->blkused + len >= 64)
{
__m128i MSG0, MSG1, MSG2, MSG3;
memcpy(s->block + s->blkused, q, 64 - s->blkused);
q += 64 - s->blkused;
len -= 64 - s->blkused;
/* Save current state */
ABCD_SAVE = ABCD;
E0_SAVE = E0;
/* Rounds 0-3 */
MSG0 = _mm_loadu_si128((const __m128i*)(s->block + 0));
MSG0 = _mm_shuffle_epi8(MSG0, MASK);
E0 = _mm_add_epi32(E0, MSG0);
E1 = ABCD;
ABCD = _mm_sha1rnds4_epu32(ABCD, E0, 0);
/* Rounds 4-7 */
MSG1 = _mm_loadu_si128((const __m128i*)(s->block + 16));
MSG1 = _mm_shuffle_epi8(MSG1, MASK);
E1 = _mm_sha1nexte_epu32(E1, MSG1);
E0 = ABCD;
ABCD = _mm_sha1rnds4_epu32(ABCD, E1, 0);
MSG0 = _mm_sha1msg1_epu32(MSG0, MSG1);
/* Rounds 8-11 */
MSG2 = _mm_loadu_si128((const __m128i*)(s->block + 32));
MSG2 = _mm_shuffle_epi8(MSG2, MASK);
E0 = _mm_sha1nexte_epu32(E0, MSG2);
E1 = ABCD;
ABCD = _mm_sha1rnds4_epu32(ABCD, E0, 0);
MSG1 = _mm_sha1msg1_epu32(MSG1, MSG2);
MSG0 = _mm_xor_si128(MSG0, MSG2);
/* Rounds 12-15 */
MSG3 = _mm_loadu_si128((const __m128i*)(s->block + 48));
MSG3 = _mm_shuffle_epi8(MSG3, MASK);
E1 = _mm_sha1nexte_epu32(E1, MSG3);
E0 = ABCD;
MSG0 = _mm_sha1msg2_epu32(MSG0, MSG3);
ABCD = _mm_sha1rnds4_epu32(ABCD, E1, 0);
MSG2 = _mm_sha1msg1_epu32(MSG2, MSG3);
MSG1 = _mm_xor_si128(MSG1, MSG3);
/* Rounds 16-19 */
E0 = _mm_sha1nexte_epu32(E0, MSG0);
E1 = ABCD;
MSG1 = _mm_sha1msg2_epu32(MSG1, MSG0);
ABCD = _mm_sha1rnds4_epu32(ABCD, E0, 0);
MSG3 = _mm_sha1msg1_epu32(MSG3, MSG0);
MSG2 = _mm_xor_si128(MSG2, MSG0);
/* Rounds 20-23 */
E1 = _mm_sha1nexte_epu32(E1, MSG1);
E0 = ABCD;
MSG2 = _mm_sha1msg2_epu32(MSG2, MSG1);
ABCD = _mm_sha1rnds4_epu32(ABCD, E1, 1);
MSG0 = _mm_sha1msg1_epu32(MSG0, MSG1);
MSG3 = _mm_xor_si128(MSG3, MSG1);
/* Rounds 24-27 */
E0 = _mm_sha1nexte_epu32(E0, MSG2);
E1 = ABCD;
MSG3 = _mm_sha1msg2_epu32(MSG3, MSG2);
ABCD = _mm_sha1rnds4_epu32(ABCD, E0, 1);
MSG1 = _mm_sha1msg1_epu32(MSG1, MSG2);
MSG0 = _mm_xor_si128(MSG0, MSG2);
/* Rounds 28-31 */
E1 = _mm_sha1nexte_epu32(E1, MSG3);
E0 = ABCD;
MSG0 = _mm_sha1msg2_epu32(MSG0, MSG3);
ABCD = _mm_sha1rnds4_epu32(ABCD, E1, 1);
MSG2 = _mm_sha1msg1_epu32(MSG2, MSG3);
MSG1 = _mm_xor_si128(MSG1, MSG3);
/* Rounds 32-35 */
E0 = _mm_sha1nexte_epu32(E0, MSG0);
E1 = ABCD;
MSG1 = _mm_sha1msg2_epu32(MSG1, MSG0);
ABCD = _mm_sha1rnds4_epu32(ABCD, E0, 1);
MSG3 = _mm_sha1msg1_epu32(MSG3, MSG0);
MSG2 = _mm_xor_si128(MSG2, MSG0);
/* Rounds 36-39 */
E1 = _mm_sha1nexte_epu32(E1, MSG1);
E0 = ABCD;
MSG2 = _mm_sha1msg2_epu32(MSG2, MSG1);
ABCD = _mm_sha1rnds4_epu32(ABCD, E1, 1);
MSG0 = _mm_sha1msg1_epu32(MSG0, MSG1);
MSG3 = _mm_xor_si128(MSG3, MSG1);
/* Rounds 40-43 */
E0 = _mm_sha1nexte_epu32(E0, MSG2);
E1 = ABCD;
MSG3 = _mm_sha1msg2_epu32(MSG3, MSG2);
ABCD = _mm_sha1rnds4_epu32(ABCD, E0, 2);
MSG1 = _mm_sha1msg1_epu32(MSG1, MSG2);
MSG0 = _mm_xor_si128(MSG0, MSG2);
/* Rounds 44-47 */
E1 = _mm_sha1nexte_epu32(E1, MSG3);
E0 = ABCD;
MSG0 = _mm_sha1msg2_epu32(MSG0, MSG3);
ABCD = _mm_sha1rnds4_epu32(ABCD, E1, 2);
MSG2 = _mm_sha1msg1_epu32(MSG2, MSG3);
MSG1 = _mm_xor_si128(MSG1, MSG3);
/* Rounds 48-51 */
E0 = _mm_sha1nexte_epu32(E0, MSG0);
E1 = ABCD;
MSG1 = _mm_sha1msg2_epu32(MSG1, MSG0);
ABCD = _mm_sha1rnds4_epu32(ABCD, E0, 2);
MSG3 = _mm_sha1msg1_epu32(MSG3, MSG0);
MSG2 = _mm_xor_si128(MSG2, MSG0);
/* Rounds 52-55 */
E1 = _mm_sha1nexte_epu32(E1, MSG1);
E0 = ABCD;
MSG2 = _mm_sha1msg2_epu32(MSG2, MSG1);
ABCD = _mm_sha1rnds4_epu32(ABCD, E1, 2);
MSG0 = _mm_sha1msg1_epu32(MSG0, MSG1);
MSG3 = _mm_xor_si128(MSG3, MSG1);
/* Rounds 56-59 */
E0 = _mm_sha1nexte_epu32(E0, MSG2);
E1 = ABCD;
MSG3 = _mm_sha1msg2_epu32(MSG3, MSG2);
ABCD = _mm_sha1rnds4_epu32(ABCD, E0, 2);
MSG1 = _mm_sha1msg1_epu32(MSG1, MSG2);
MSG0 = _mm_xor_si128(MSG0, MSG2);
/* Rounds 60-63 */
E1 = _mm_sha1nexte_epu32(E1, MSG3);
E0 = ABCD;
MSG0 = _mm_sha1msg2_epu32(MSG0, MSG3);
ABCD = _mm_sha1rnds4_epu32(ABCD, E1, 3);
MSG2 = _mm_sha1msg1_epu32(MSG2, MSG3);
MSG1 = _mm_xor_si128(MSG1, MSG3);
/* Rounds 64-67 */
E0 = _mm_sha1nexte_epu32(E0, MSG0);
E1 = ABCD;
MSG1 = _mm_sha1msg2_epu32(MSG1, MSG0);
ABCD = _mm_sha1rnds4_epu32(ABCD, E0, 3);
MSG3 = _mm_sha1msg1_epu32(MSG3, MSG0);
MSG2 = _mm_xor_si128(MSG2, MSG0);
/* Rounds 68-71 */
E1 = _mm_sha1nexte_epu32(E1, MSG1);
E0 = ABCD;
MSG2 = _mm_sha1msg2_epu32(MSG2, MSG1);
ABCD = _mm_sha1rnds4_epu32(ABCD, E1, 3);
MSG3 = _mm_xor_si128(MSG3, MSG1);
/* Rounds 72-75 */
E0 = _mm_sha1nexte_epu32(E0, MSG2);
E1 = ABCD;
MSG3 = _mm_sha1msg2_epu32(MSG3, MSG2);
ABCD = _mm_sha1rnds4_epu32(ABCD, E0, 3);
/* Rounds 76-79 */
E1 = _mm_sha1nexte_epu32(E1, MSG3);
E0 = ABCD;
ABCD = _mm_sha1rnds4_epu32(ABCD, E1, 3);
/* Combine state */
E0 = _mm_sha1nexte_epu32(E0, E0_SAVE);
ABCD = _mm_add_epi32(ABCD, ABCD_SAVE);
s->blkused = 0;
}
ABCD = _mm_shuffle_epi32(ABCD, 0x1B);
/* Save state */
_mm_storeu_si128((__m128i*) s->h, ABCD);
s->h[4] = _mm_extract_epi32(E0, 3);
memcpy(s->block, q, len);
s->blkused = len;
}
}
Work around LLVM bug 34980 Clang generates an internal failure if the same function has different target attributes in definition and declaration. To work around that, we made a proxy predeclared function without target attribute.
2018-02-18 13:48:44 +00:00
/*
* Workaround LLVM bug https://bugs.llvm.org/show_bug.cgi?id=34980
*/
static void sha1_ni(SHA_State * s, const unsigned char *q, int len)
{
sha1_ni_(s, q, len);
}
Add supports_sha_ni(void) function It executes CPUID instruction to check whether SHA extensions are supported by hosting CPU.
2018-02-18 21:06:14 +00:00
#else /* COMPILER_SUPPORTS_AES_NI */
Add SHA1 implementation with new instructions SHA1-NI code is conditionally enabled if CPU supports SHA extensions. The procedure is based on Jeffrey Walton's SHA1 implementation: https://github.com/noloader/SHA-Intrinsics
2018-02-18 21:07:06 +00:00
static void sha1_ni(SHA_State * s, const unsigned char *q, int len)
{
Replace assert(false) with an unreachable() macro. Taking a leaf out of the LLVM code base: this macro still includes an assert(false) so that the message will show up in a typical build, but it follows it up with a call to a function explicitly marked as no- return. So this ought to do a better job of convincing compilers that once a code path hits this function it _really doesn't_ have to still faff about with making up a bogus return value or filling in a variable that 'might be used uninitialised' in the following code that won't be reached anyway. I've gone through the existing code looking for the assert(false) / assert(0) idiom and replaced all the ones I found with the new macro, which also meant I could remove a few pointless return statements and variable initialisations that I'd already had to put in to placate compiler front ends.
2019-01-03 08:12:19 +00:00
unreachable("sha1_ni not compiled in");
Add SHA1 implementation with new instructions SHA1-NI code is conditionally enabled if CPU supports SHA extensions. The procedure is based on Jeffrey Walton's SHA1 implementation: https://github.com/noloader/SHA-Intrinsics
2018-02-18 21:07:06 +00:00
}
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
bool supports_sha_ni(void)
Add supports_sha_ni(void) function It executes CPUID instruction to check whether SHA extensions are supported by hosting CPU.
2018-02-18 21:06:14 +00:00
{
Convert a lot of 'int' variables to 'bool'. My normal habit these days, in new code, is to treat int and bool as _almost_ completely separate types. I'm still willing to use C's implicit test for zero on an integer (e.g. 'if (!blob.len)' is fine, no need to spell it out as blob.len != 0), but generally, if a variable is going to be conceptually a boolean, I like to declare it bool and assign to it using 'true' or 'false' rather than 0 or 1. PuTTY is an exception, because it predates the C99 bool, and I've stuck to its existing coding style even when adding new code to it. But it's been annoying me more and more, so now that I've decided C99 bool is an acceptable thing to require from our toolchain in the first place, here's a quite thorough trawl through the source doing 'boolification'. Many variables and function parameters are now typed as bool rather than int; many assignments of 0 or 1 to those variables are now spelled 'true' or 'false'. I managed this thorough conversion with the help of a custom clang plugin that I wrote to trawl the AST and apply heuristics to point out where things might want changing. So I've even managed to do a decent job on parts of the code I haven't looked at in years! To make the plugin's work easier, I pushed platform front ends generally in the direction of using standard 'bool' in preference to platform-specific boolean types like Windows BOOL or GTK's gboolean; I've left the platform booleans in places they _have_ to be for the platform APIs to work right, but variables only used by my own code have been converted wherever I found them. In a few places there are int values that look very like booleans in _most_ of the places they're used, but have a rarely-used third value, or a distinction between different nonzero values that most users don't care about. In these cases, I've _removed_ uses of 'true' and 'false' for the return values, to emphasise that there's something more subtle going on than a simple boolean answer: - the 'multisel' field in dialog.h's list box structure, for which the GTK front end in particular recognises a difference between 1 and 2 but nearly everything else treats as boolean - the 'urgent' parameter to plug_receive, where 1 vs 2 tells you something about the specific location of the urgent pointer, but most clients only care about 0 vs 'something nonzero' - the return value of wc_match, where -1 indicates a syntax error in the wildcard. - the return values from SSH-1 RSA-key loading functions, which use -1 for 'wrong passphrase' and 0 for all other failures (so any caller which already knows it's not loading an _encrypted private_ key can treat them as boolean) - term->esc_query, and the 'query' parameter in toggle_mode in terminal.c, which _usually_ hold 0 for ESC[123h or 1 for ESC[?123h, but can also hold -1 for some other intervening character that we don't support. In a few places there's an integer that I haven't turned into a bool even though it really _can_ only take values 0 or 1 (and, as above, tried to make the call sites consistent in not calling those values true and false), on the grounds that I thought it would make it more confusing to imply that the 0 value was in some sense 'negative' or bad and the 1 positive or good: - the return value of plug_accepting uses the POSIXish convention of 0=success and nonzero=error; I think if I made it bool then I'd also want to reverse its sense, and that's a job for a separate piece of work. - the 'screen' parameter to lineptr() in terminal.c, where 0 and 1 represent the default and alternate screens. There's no obvious reason why one of those should be considered 'true' or 'positive' or 'success' - they're just indices - so I've left it as int. ssh_scp_recv had particularly confusing semantics for its previous int return value: its call sites used '<= 0' to check for error, but it never actually returned a negative number, just 0 or 1. Now the function and its call sites agree that it's a bool. In a couple of places I've renamed variables called 'ret', because I don't like that name any more - it's unclear whether it means the return value (in preparation) for the _containing_ function or the return value received from a subroutine call, and occasionally I've accidentally used the same variable for both and introduced a bug. So where one of those got in my way, I've renamed it to 'toret' or 'retd' (the latter short for 'returned') in line with my usual modern practice, but I haven't done a thorough job of finding all of them. Finally, one amusing side effect of doing this is that I've had to separate quite a few chained assignments. It used to be perfectly fine to write 'a = b = c = TRUE' when a,b,c were int and TRUE was just a the 'true' defined by stdbool.h, that idiom provokes a warning from gcc: 'suggest parentheses around assignment used as truth value'!
2018-11-02 19:23:19 +00:00
return false;
Add supports_sha_ni(void) function It executes CPUID instruction to check whether SHA extensions are supported by hosting CPU.
2018-02-18 21:06:14 +00:00
}
#endif /* COMPILER_SUPPORTS_AES_NI */
Reference in New Issue Copy Permalink