# EPF5 Dev Update - Week 8 & 9

## Weekly Highlights

Attended EPF5 weekly standup, office hour, Grandine standup, and also our in-house meet which happens three times a week (Monday, Wednesday, and Friday).

For week 8, I was totally stuck with no progress on my current task, and due to that, I was unable to drop and update. But for week 9, I was finally able to fully generate a flamegraph, and while on the run, I noticed that there is no cargo-audit integrated into Grandine's Continuous Integration (CI) pipeline, so I did a quick run on that too.

### More Details on the above progress

Starting with the `cargo audit` using the following command `cargo install cargo-audit` and `cargo audit` I got this output:
The above output helps identifies a medium severity vulnerability in the rsa crate version 0.9.6 due to a timing side-channel attack known as the Marvin Attack.
### Severity and Impact
**Severity Level:** Medium severity.
**Impact:** The vulnerability affects RSA cryptographic operations, potentially allowing an attacker to infer private keys. This can lead to unauthorized data decryption or signatures, which is a considerable risk for applications relying on RSA for secure communications or data protection.

### Current Situation
**No Fixed Upgrade:** The audit indicates that there is no patched version available for the rsa crate as of the audit.

**Dependency Chain:** This vulnerability exists in a deeply nested dependency path, indicating that it is indirectly included in grandine through other crates (superboring, jwt-simple, eth1_api).

**Evaluate Risk:** Am yet to evaluate how the affected functionality is used in grandine, to see if the RSA operations are used for critical security task.

*But alternatively we can using an alternative to jwt-simple that doesn't rely on the vulnerable rsa crate.*

## Flamegraph Current Update

I used infura RPC URL endpoint `cargo flamegraph --release --features network-sepolia --bin grandine -- \
--eth1-rpc-urls https://sepolia.infura.io/v3/.....
--target-peers 100`
**Flamegraph start time:**
Date: August 10, 2024
Time: 03:14:52 AM (and 079 milliseconds)
**Flamegraph End Time:**
Date: August 10, 2024
Time: 03:45:25 AM (and 599 milliseconds)

Looking at this graph there is a whole lot to take from it, giving a little overview of what I was able to grab, starting from the widest bars like `libsystem_pthread.dylib thread_start 6469 sample 98.34%` indicates that 98.34% of the sampled time was spent in thread startup operations. This is a crucial piece of information that
suggests that a significant amount of time is being spent creating or starting threads.
This could indicate excessive thread creation, which is often a performance anti-pattern.
It might also suggest that the application is not effectively reusing threads or is creating short-lived threads frequently.

Based on this single bar alone I need to;

Conduct a thorough review of grandine threading strategy, to understand if grandine may be creating too many threads or not efficiently managing thread lifecycle.

## To Do's
1. Investigate grandine thread creation and management patterns. Consider implementing or optimizing a thread pool to reduce the overhead of thread creation.
2. Profile grandine with focus on thread creation and destruction to identify specific areas where we might be overusing threads.

## Security Concern

The high percentage of time spent in thread creation also raises concerns about potential resource exhaustion attacks. We need to ensure grandine threading model can't be exploited to crash the client or degrade its performance.
## Conclusion
This flamegraph analysis, particularly the revelation about grandine thread usage, has provided critical insights into Grandine's performance characteristics. Addressing grandine threading model will be my top priority, as it promises to yield significant performance improvements and enhance grandine resilience. when addressed, could significantly improve Grandine's performance and stability.