[3/3] no-std support phase I

[japaric]

this PR implements phase I of RFC #1399 . NOTE that this PR is built on top of PR #1583

originally phase I aimed to only allowing client functionality in no-std context but turns out that the changes were sufficient to also enable server functionality as evidenced in #1534

breaking changes: implementing the RFC requires no breaking changes

blockers:

• [2/3] implement the caller-side managed buffers API (take 2) #1583

this PR is best reviewed on a commit by commit basis (do skip PR#1583 commits)

[codecov]

Codecov Report

Attention: Patch coverage is 85.90164% with 129 lines in your changes are missing coverage. Please review.

Project coverage is 95.96%. Comparing base (a31c5da) to head (2444558).

Files	Patch %	Lines
rustls/src/quic.rs	61.32%	70 Missing ⚠️
rustls/src/conn.rs	85.27%	19 Missing ⚠️
rustls/src/server/server_conn.rs	88.99%	12 Missing ⚠️
rustls/src/client/handy.rs	94.56%	5 Missing ⚠️
rustls/src/server/handy.rs	95.65%	5 Missing ⚠️
rustls/src/webpki/mod.rs	44.44%	5 Missing ⚠️
rustls/src/error.rs	87.87%	4 Missing ⚠️
rustls/src/msgs/deframer.rs	90.24%	4 Missing ⚠️
rustls/src/client/tls12.rs	71.42%	2 Missing ⚠️
rustls/src/common_state.rs	93.93%	2 Missing ⚠️
... and 1 more

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1502      +/-   ##
==========================================
- Coverage   95.97%   95.96%   -0.02%     
==========================================
  Files          85       86       +1     
  Lines       18727    18818      +91     
==========================================
+ Hits        17974    18059      +85     
- Misses        753      759       +6     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[ctz]

• pki_types::UnixTime will need to gain a constructor so that no_std users can implement the GetCurrentTime trait

I think this exists and is UnixTime::since_unix_epoch(core::time::Duration)

[djc]

I think this would be much easier to digest if it was split into smaller commits, for example:

• One commit for importing Vec explicitly
• One commit for TimeProvider
• One commit for dealing with the cache
• One commit for compiling out all the server stuff

[japaric]

the PR has been split in commits to make it easier to review. all the "rm (..)" commits can be squashed at a later time. also, there are several warning that I haven't fixed and they involve cfg-ing away more code. for now, I have only removed what's need to make rustls compile with #![no_std]

[djc]

I think the rm * commits would actually be nice to keep, assuming each can pass cargo check on its own? Would make it a lot easier to review!

[japaric]

I think the rm * commits would actually be nice to keep, assuming each can pass cargo check on its own?

I reordered the commits a bit and now only these contiguous commits:

• add std feature
• no-std: remove field from *Error::Other variants
• no-std: add TimeProvider to ClientConfig
• no-std: rm TicketSwitcher
• no-std: add TimeProvider to ServerConfig

make cargo b --no-default-features fail. cargo b works on all the commits of this PR.

---

The first commit of this PR basically adds this to src/lib.rs

#![no_std]
extern crate std;

this switches the prelude from std::prelude to core::prelude and forces one to explicitly import anything that's not in core, that is mainly alloc API.

I think it would be worthwhile to land that change in a separate PR ahead of this one: it'll prevent relying on implicit alloc imports so all future PRs will have to include explicit alloc imports to avoid breaking the build. That would not only prevent this PR from bitrotting but I think it would help maintain no-std support long term. I'll submit that commit as a separate PR with a fleshed out rationale.

[japaric]

I think it would be worthwhile to land that change in a separate PR ahead of this one

extracted that into PR #1524

[japaric]

quick update: I have rebased this PR now that #1524 has been merged. I have also pushed a commit that makes cargo b --no-default-features --features ring work on Linux. however, I tried to build rustls with that set of features (-std +ring) for the x86_64-unknown-none target and it failed to compile.

turns out that ring has this sealed SecureRandom trait (note that there are two of them in the ring codebase; one is public and the other is not) that's implemented for SystemRandom but only for a known list of OSes. as "OS agnostic" targets like x86_64-unknown-none have os = "none" in their target specification, SystemRandom lacks the SecureRandom trait and that causes problems in the rustls codebase: RsaSigner, KxGroup, etc.

for more context: I'm building a small rustls no-std demo that only depends on libc bindings and should work on any OS that has POSIX layer as way to exercise this PR. I'm running the demo on Linux so I do have a "secure random" getrandom implementation but I can't signal that to ring. I'll explore using an alternative crypto provider as showcased in #1405.

[djc]

@japaric probably also good to open a ring issue to signal this there and see if there is a better solution there. (Please link the issue here if you do so.)

[japaric]

@djc done. submitted briansmith/ring#1734

[japaric]

rebased this on top of #1583 and marked it as ready for review

[cpu]

Thanks for landing those last tweaks @ctz