Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

LWIP random library and TCP sequence number improvements #4284

Merged
merged 2 commits into from
May 15, 2017
Merged

LWIP random library and TCP sequence number improvements #4284

merged 2 commits into from
May 15, 2017

Conversation

mikaleppanen
Copy link

Description

Added support for common pal random library to LWIP. This corrects issue: #3891
Integrated LWIP TCP sequence number initialization reference code to mbed LWIP stack.
Corrected LWIP adaptation Coverity and compiler warnings.

Status

READY

Migrations

NO

Related PRs

None

Todos

  • Tests
  • Documentation

Deploy notes

None

Steps to test or reproduce

None

@0xc0170
Copy link
Contributor

0xc0170 commented May 8, 2017

cc @kjbracey-arm @geky

#endif

#if FEATURE_COMMON_PAL
void lwip_seed_random(void);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

please provide documentation for this new API

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Added function descriptions.

void lwip_seed_random(void);
void lwip_add_ramdom_seed(uint64_t seed);
#else
#define lwip_seed_random()
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why are these defined? I would rather provide an empty implementation ?

will it work fro the random_seed ?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you want them defined as nothing, they need to at least be expressions - make them (void)0.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Made empty functions for non-common pal case.

randLIB_seed_random();
}

void lwip_add_ramdom_seed(uint64_t seed)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"random"

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Corrected.

@@ -24,12 +24,35 @@ EthernetInterface::EthernetInterface()
{
}

bool validate_str(const char *str, const int len)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This all seems a bit clunky. This whole routine could just be

return str != NULL && strlen(str) < len;

You could also have replaced strncpy with snprintf, which doesn't have the no-zero-termination-if-truncating quirk.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does lwip already verify that the addresses are syntactically correct?

snprintf does come with a code-size cost, though you can just always force a null terminator:

strncpy(_ip_address, ip_address ? ip_address : "", sizeof(_ip_address));
_ip_address[sizeof(_ip_address)-1] = '\0';

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, lwip validates the addresses. Added enforcing of null terminator and removed validate_str functions.

Copy link
Contributor

@kjbracey kjbracey May 10, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@geky You reckon nobody else is using snprintf?? Seems more likely to me that no-one is using strncpy.

randLIB_add_seed(seed);
}

inline uint32_t lwip_get_random(void)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Only having inline in the C file doesn't achieve anything.

If you really want inlining, the only easily C99/C++ portable form is a "static inline" definition in the header file.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Removed inline.


/* Generate the hash, using MD5. */
lwip_md5_starts(&ctx);
lwip_md5_update(&ctx, input, sizeof(input));
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This seems oddly pointless - trying to a copy of all the data bits into a static 64-byte buffer to pass it in one go, when you could freely pass the existing data pointers in multiple calls to update - the MD5 has its own 64-byte buffer.

I guess this is unmodified reference code though?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, reference code has that so leaving as it is.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is a bit bloaty though - 64 entire bytes of static RAM usage. Oh well. I guess it always needs 16 for the secret.

#include "lwip_tcp_isn.h"
#define LWIP_HOOK_TCP_ISN lwip_hook_tcp_isn
#if MBEDTLS_MD5_C
#define LWIP_USE_EXTERNAL_MBEDTLS 1
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can't this be set unconditionally? Not that it probably makes a difference.

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

mbed tls c-functions are flagged with MBEDTLS_MD5_C so they do not exists in build without the flag.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, was being dense. Thought that was a LWIP flag.

void lwip_seed_random(void);
void lwip_add_ramdom_seed(uint64_t seed);
#else
#define lwip_seed_random()
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you want them defined as nothing, they need to at least be expressions - make them (void)0.


#include "lwip_random.h"

#if FEATURE_COMMON_PAL
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah I see, this works for me 👍

Copy link
Contributor

@geky geky left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me as long as the other guys' comments are handled

Mika Leppänen added 2 commits May 10, 2017 10:20
lwip now uses mbed client random library under common pal when available.
Ported lwip reference TCP initial sequence number handling to mbed-os
lwip stack. Handling is based on RFC 6528.
Coverity ids: 1373147 and 1374442.
@mikaleppanen
Copy link
Author

Corrected review defects.

@0xc0170
Copy link
Contributor

0xc0170 commented May 10, 2017

/morph test-nightly

@mbed-bot
Copy link

Result: FAILURE

Your command has finished executing! Here's what you wrote!

/morph test-nightly

Output

mbed Build Number: 177

Test failed!

@geky
Copy link
Contributor

geky commented May 10, 2017

@bridadan, @studavekar, it's the arch pro issue again

A believe a workaround is in progress
#4274 (comment)

@0xc0170
Copy link
Contributor

0xc0170 commented May 11, 2017

It should be fixed now, restarting

/morph test-nightly

@mbed-bot
Copy link

Result: SUCCESS

Your command has finished executing! Here's what you wrote!

/morph test-nightly

Output

mbed Build Number: 185

All builds and test passed!

@JanneKiiskila
Copy link
Contributor

@adbridge @sg- @0xc0170 - please note this is a fatal blocking stability issue for TLS connections, please patch this ASAP to mbed OS 5.4.x.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants