mirrors/cosmopolitan
1
0
Fork 0
mirror of https://github.com/jart/cosmopolitan.git synced 2025-01-31 19:43:32 +00:00
Code Issues Projects Releases Packages Wiki Activity Actions
cosmopolitan/third_party/mbedtls/mbedtls.mk

84 lines
2.7 KiB
Makefile
Raw Normal View History

Get Mbed TLS to build This change configures Mbed TLS to support the fewest number of things possible required to run an HTTPS server that caters to the sweet spot of being legacy enough to support the vast majority of user agents but modern enough that Chrome and Firefox remain happy. That should entail - TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 - TLS_RSA_WITH_AES_128_CBC_SHA Even though other suites still get included so what usually happens in practice is ECDHE-RSA-AES256-GCM-SHA384 under TLS 1.2 will be selected and the binary footprint is reasonable, and should cost us about 200kb
2021-06-16 02:52:02 +00:00
#-*-mode:makefile-gmake;indent-tabs-mode:t;tab-width:8;coding:utf-8-*-┐
#───vi: set et ft=make ts=8 tw=8 fenc=utf-8 :vi───────────────────────┘
PKGS += THIRD_PARTY_MBEDTLS
THIRD_PARTY_MBEDTLS_ARTIFACTS += THIRD_PARTY_MBEDTLS_A
THIRD_PARTY_MBEDTLS = $(THIRD_PARTY_MBEDTLS_A_DEPS) $(THIRD_PARTY_MBEDTLS_A)
THIRD_PARTY_MBEDTLS_A = o/$(MODE)/third_party/mbedtls/mbedtls.a
Flatten Mbed TLS directory structure
2021-06-16 03:18:59 +00:00
THIRD_PARTY_MBEDTLS_A_FILES := $(wildcard third_party/mbedtls/*)
Get Mbed TLS to build This change configures Mbed TLS to support the fewest number of things possible required to run an HTTPS server that caters to the sweet spot of being legacy enough to support the vast majority of user agents but modern enough that Chrome and Firefox remain happy. That should entail - TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 - TLS_RSA_WITH_AES_128_CBC_SHA Even though other suites still get included so what usually happens in practice is ECDHE-RSA-AES256-GCM-SHA384 under TLS 1.2 will be selected and the binary footprint is reasonable, and should cost us about 200kb
2021-06-16 02:52:02 +00:00
THIRD_PARTY_MBEDTLS_A_HDRS = $(filter %.h,$(THIRD_PARTY_MBEDTLS_A_FILES))
THIRD_PARTY_MBEDTLS_A_SRCS = $(filter %.c,$(THIRD_PARTY_MBEDTLS_A_FILES))
Add HTTP/HTTPS Fetch() API to redbean You can now say the following in your redbean Lua code: status,headers,payload = Fetch("https://foo.example") The following Lua APIs have been introduced: - Fetch(str) → str,{str:str},str - GetHttpReason(int) → str - GetHttpReason(int) → str - ProgramSslFetchVerify(bool) - ProgramSslClientVerify(bool) The following flags have been introduced: - `-j` enables client SSL verification - `-k` disables Fetch() SSL verification - `-t INT` may now be passed a negative value for keepalive Lua exceptions now invoke Cosmopolitan's garbage collector when unwinding the stack. So it's now safe to use _gc() w/ Lua 𝔱𝔥𝔯𝔬𝔴 See #97
2021-07-08 04:44:27 +00:00
THIRD_PARTY_MBEDTLS_A_OBJS = $(THIRD_PARTY_MBEDTLS_A_SRCS:%.c=o/$(MODE)/%.o)
Get Mbed TLS to build This change configures Mbed TLS to support the fewest number of things possible required to run an HTTPS server that caters to the sweet spot of being legacy enough to support the vast majority of user agents but modern enough that Chrome and Firefox remain happy. That should entail - TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 - TLS_RSA_WITH_AES_128_CBC_SHA Even though other suites still get included so what usually happens in practice is ECDHE-RSA-AES256-GCM-SHA384 under TLS 1.2 will be selected and the binary footprint is reasonable, and should cost us about 200kb
2021-06-16 02:52:02 +00:00
THIRD_PARTY_MBEDTLS_A_CHECKS = \
$(THIRD_PARTY_MBEDTLS_A).pkg \
$(THIRD_PARTY_MBEDTLS_A_HDRS:%=o/$(MODE)/%.ok)
THIRD_PARTY_MBEDTLS_A_DIRECTDEPS = \
Add SNI support to redbean and improve SSL perf This change makes SSL virtual hosting possible. You can now load multiple certificates for multiple domains and redbean will just figure out which one to use, even if you only have 1 ip address. You can also use a jumbo certificate that lists all your domains in the the subject alternative names. This change also makes performance improvements to MbedTLS. Here are some benchmarks vs. cc1920749eb81f346badaf55fbf79620cb718a55 BEFORE AFTER (microsecs) suite_ssl.com 2512881 191738 13.11x faster suite_pkparse.com 36291 3295 11.01x faster suite_x509parse.com 854669 120293 7.10x faster suite_pkwrite.com 6549 1265 5.18x faster suite_ecdsa.com 53347 18778 2.84x faster suite_pk.com 49051 18717 2.62x faster suite_ecdh.com 19535 9502 2.06x faster suite_shax.com 15848 7965 1.99x faster suite_rsa.com 353257 184828 1.91x faster suite_x509write.com 162646 85733 1.90x faster suite_ecp.com 20503 11050 1.86x faster suite_hmac_drbg.no_reseed.com 19528 11417 1.71x faster suite_hmac_drbg.nopr.com 12460 8010 1.56x faster suite_mpi.com 687124 442661 1.55x faster suite_hmac_drbg.pr.com 11890 7752 1.53x faster There aren't any special tricks to the performance imporvements. It's mostly due to code cleanup, assembly and intel instructions like mulx, adox, and adcx.
2021-07-19 21:55:20 +00:00
LIBC_BITS \
Get Mbed TLS to build This change configures Mbed TLS to support the fewest number of things possible required to run an HTTPS server that caters to the sweet spot of being legacy enough to support the vast majority of user agents but modern enough that Chrome and Firefox remain happy. That should entail - TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 - TLS_RSA_WITH_AES_128_CBC_SHA Even though other suites still get included so what usually happens in practice is ECDHE-RSA-AES256-GCM-SHA384 under TLS 1.2 will be selected and the binary footprint is reasonable, and should cost us about 200kb
2021-06-16 02:52:02 +00:00
LIBC_CALLS \
Add SNI support to redbean and improve SSL perf This change makes SSL virtual hosting possible. You can now load multiple certificates for multiple domains and redbean will just figure out which one to use, even if you only have 1 ip address. You can also use a jumbo certificate that lists all your domains in the the subject alternative names. This change also makes performance improvements to MbedTLS. Here are some benchmarks vs. cc1920749eb81f346badaf55fbf79620cb718a55 BEFORE AFTER (microsecs) suite_ssl.com 2512881 191738 13.11x faster suite_pkparse.com 36291 3295 11.01x faster suite_x509parse.com 854669 120293 7.10x faster suite_pkwrite.com 6549 1265 5.18x faster suite_ecdsa.com 53347 18778 2.84x faster suite_pk.com 49051 18717 2.62x faster suite_ecdh.com 19535 9502 2.06x faster suite_shax.com 15848 7965 1.99x faster suite_rsa.com 353257 184828 1.91x faster suite_x509write.com 162646 85733 1.90x faster suite_ecp.com 20503 11050 1.86x faster suite_hmac_drbg.no_reseed.com 19528 11417 1.71x faster suite_hmac_drbg.nopr.com 12460 8010 1.56x faster suite_mpi.com 687124 442661 1.55x faster suite_hmac_drbg.pr.com 11890 7752 1.53x faster There aren't any special tricks to the performance imporvements. It's mostly due to code cleanup, assembly and intel instructions like mulx, adox, and adcx.
2021-07-19 21:55:20 +00:00
LIBC_DNS \
Get Mbed TLS to build This change configures Mbed TLS to support the fewest number of things possible required to run an HTTPS server that caters to the sweet spot of being legacy enough to support the vast majority of user agents but modern enough that Chrome and Firefox remain happy. That should entail - TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 - TLS_RSA_WITH_AES_128_CBC_SHA Even though other suites still get included so what usually happens in practice is ECDHE-RSA-AES256-GCM-SHA384 under TLS 1.2 will be selected and the binary footprint is reasonable, and should cost us about 200kb
2021-06-16 02:52:02 +00:00
LIBC_FMT \
LIBC_INTRIN \
LIBC_MEM \
LIBC_NEXGEN32E \
LIBC_RAND \
LIBC_RUNTIME \
Add SNI support to redbean and improve SSL perf This change makes SSL virtual hosting possible. You can now load multiple certificates for multiple domains and redbean will just figure out which one to use, even if you only have 1 ip address. You can also use a jumbo certificate that lists all your domains in the the subject alternative names. This change also makes performance improvements to MbedTLS. Here are some benchmarks vs. cc1920749eb81f346badaf55fbf79620cb718a55 BEFORE AFTER (microsecs) suite_ssl.com 2512881 191738 13.11x faster suite_pkparse.com 36291 3295 11.01x faster suite_x509parse.com 854669 120293 7.10x faster suite_pkwrite.com 6549 1265 5.18x faster suite_ecdsa.com 53347 18778 2.84x faster suite_pk.com 49051 18717 2.62x faster suite_ecdh.com 19535 9502 2.06x faster suite_shax.com 15848 7965 1.99x faster suite_rsa.com 353257 184828 1.91x faster suite_x509write.com 162646 85733 1.90x faster suite_ecp.com 20503 11050 1.86x faster suite_hmac_drbg.no_reseed.com 19528 11417 1.71x faster suite_hmac_drbg.nopr.com 12460 8010 1.56x faster suite_mpi.com 687124 442661 1.55x faster suite_hmac_drbg.pr.com 11890 7752 1.53x faster There aren't any special tricks to the performance imporvements. It's mostly due to code cleanup, assembly and intel instructions like mulx, adox, and adcx.
2021-07-19 21:55:20 +00:00
LIBC_SOCK \
Add SSL to redbean Your redbean can now interoperate with clients that require TLS crypto. This is accomplished using a protocol polyglot that lets us distinguish between HTTP and HTTPS regardless of the port number. Certificates will be generated automatically, if none are supplied by the user. Footprint increases by only a few hundred kb so redbean in MODY=tiny is now 1.0mb - Add lseek() polyfills for ZIP executable - Automatically polyfill /tmp/FOO paths on NT - Fix readdir() / ftw() / nftw() bugs on Windows - Introduce -B flag for slower SSL that's stronger - Remove mbedtls features Cosmopolitan doesn't need - Have base64 decoder support the uri-safe alternative - Remove Truncated HMAC because it's forbidden by the IETF - Add all the mbedtls test suites and make them go 3x faster - Support opendir() / readdir() / closedir() on ZIP executable - Use Everest for ECDHE-ECDSA because it's so good it's so good - Add tinier implementation of sha1 since it's not worth the rom - Add chi-square monte-carlo mean correlation tests for getrandom() - Source entropy on Windows from the proper interface everyone uses We're continuing to outperform NGINX and other servers on raw message throughput. Using SSL means that instead of 1,000,000 qps you can get around 300,000 qps. However redbean isn't as fast as NGINX yet at SSL handshakes, since redbean can do 2,627 per second and NGINX does 4.3k Right now, the SSL UX story works best if you give your redbean a key signing key since that can be easily generated by openssl using a one liner then redbean will do all the things that are impossibly hard to do like signing ecdsa and rsa certificates that'll work in chrome. We should integrate the let's encrypt acme protocol in the future. Live Demo: https://redbean.justine.lol/ Root Cert: https://redbean.justine.lol/redbean1.crt
2021-06-24 19:31:26 +00:00
LIBC_LOG \
Get Mbed TLS to build This change configures Mbed TLS to support the fewest number of things possible required to run an HTTPS server that caters to the sweet spot of being legacy enough to support the vast majority of user agents but modern enough that Chrome and Firefox remain happy. That should entail - TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 - TLS_RSA_WITH_AES_128_CBC_SHA Even though other suites still get included so what usually happens in practice is ECDHE-RSA-AES256-GCM-SHA384 under TLS 1.2 will be selected and the binary footprint is reasonable, and should cost us about 200kb
2021-06-16 02:52:02 +00:00
LIBC_STDIO \
LIBC_STR \
LIBC_SYSV \
LIBC_TIME \
LIBC_UNICODE \
Add HTTP/HTTPS Fetch() API to redbean You can now say the following in your redbean Lua code: status,headers,payload = Fetch("https://foo.example") The following Lua APIs have been introduced: - Fetch(str) → str,{str:str},str - GetHttpReason(int) → str - GetHttpReason(int) → str - ProgramSslFetchVerify(bool) - ProgramSslClientVerify(bool) The following flags have been introduced: - `-j` enables client SSL verification - `-k` disables Fetch() SSL verification - `-t INT` may now be passed a negative value for keepalive Lua exceptions now invoke Cosmopolitan's garbage collector when unwinding the stack. So it's now safe to use _gc() w/ Lua 𝔱𝔥𝔯𝔬𝔴 See #97
2021-07-08 04:44:27 +00:00
NET_HTTP \
Get Mbed TLS to build This change configures Mbed TLS to support the fewest number of things possible required to run an HTTPS server that caters to the sweet spot of being legacy enough to support the vast majority of user agents but modern enough that Chrome and Firefox remain happy. That should entail - TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 - TLS_RSA_WITH_AES_128_CBC_SHA Even though other suites still get included so what usually happens in practice is ECDHE-RSA-AES256-GCM-SHA384 under TLS 1.2 will be selected and the binary footprint is reasonable, and should cost us about 200kb
2021-06-16 02:52:02 +00:00
THIRD_PARTY_COMPILER_RT \
THIRD_PARTY_GDTOA
THIRD_PARTY_MBEDTLS_A_DEPS := \
$(call uniq,$(foreach x,$(THIRD_PARTY_MBEDTLS_A_DIRECTDEPS),$($(x))))
$(THIRD_PARTY_MBEDTLS_A): \
third_party/mbedtls/ \
$(THIRD_PARTY_MBEDTLS_A).pkg \
$(THIRD_PARTY_MBEDTLS_A_OBJS)
$(THIRD_PARTY_MBEDTLS_A).pkg: \
$(THIRD_PARTY_MBEDTLS_A_OBJS) \
$(foreach x,$(THIRD_PARTY_MBEDTLS_A_DIRECTDEPS),$($(x)_A).pkg)
$(THIRD_PARTY_MBEDTLS_A_OBJS): \
OVERRIDE_CFLAGS += \
-fdata-sections \
-ffunction-sections
Make SSL handshakes much faster This change boosts SSL handshake performance from 2,627 to ~10,000 per second which is the same level of performance as NGINX at establishing secure connections. That's impressive if we consider that redbean is a forking frontend application server. This was accomplished by: 1. Enabling either SSL session caching or SSL tickets. We choose to use tickets since they reduce network round trips too and that's a more important metric than wrk'ing localhost. 2. Fixing mbedtls_mpi_sub_abs() which is the most frequently called function. It's called about 12,000 times during an SSL handshake since it's the basis of most arithmetic operations like addition and for some strange reason it was designed to make two needless copies in addition to calling malloc and free. That's now fixed. 3. Improving TLS output buffering during the SSL handshake only, so that only a single is write and read system call is needed until blocking on the ping pong. redbean will now do a better job wiping sensitive memory from a child process as soon as it's not needed. The nice thing about fork is it's much faster than reverse proxying so the goal is to use the different address spaces along with setuid() to minimize the risk that a server key will be compromised in the event that application code is hacked.
2021-07-12 06:17:47 +00:00
o/$(MODE)/third_party/mbedtls/everest.o: \
OVERRIDE_CFLAGS += \
Make stronger crypto nearly as fast One of the disadvantages of x25519 and ℘256 is it only provides 126 bits of security, so that seems like a weak link in the chain, if we're using ECDHE-ECDSA-AES256-GCM-SHA384. The U.S. government wants classified data to be encrypted using a curve at least as strong as ℘384, which provides 192 bits of security, but if you read the consensus of stack exchange it would give you the impression that ℘384 is three times slower. This change (as well as the previous one) makes ℘384 three times as fast by tuning its modulus and multiplication subroutines with new tests that should convincingly show: the optimized code behaves the same way as the old code. Some of the diff noise from the previous change is now removed too, so that our vendored fork can be more easily compared with upstream sources. So you can now have stronger cryptography without compromises. ℘384 modulus Justine l: 28𝑐 9𝑛𝑠 ℘384 modulus MbedTLS NIST l: 127𝑐 41𝑛𝑠 ℘384 modulus MbedTLS MPI l: 1,850𝑐 597𝑛𝑠 The benchmarks above show the improvements made by secp384r1() which is an important function since it needs to be called 13,000 times whenever someone establishes a connection to your web server. The same's true of Mul6x6Adx() which is able to multiply 384-bit numbers in 73 cycles, but only if your CPU was purchased after 2014 when Broadwell was introduced
2021-07-26 22:16:43 +00:00
-O3
Make SSL handshakes much faster This change boosts SSL handshake performance from 2,627 to ~10,000 per second which is the same level of performance as NGINX at establishing secure connections. That's impressive if we consider that redbean is a forking frontend application server. This was accomplished by: 1. Enabling either SSL session caching or SSL tickets. We choose to use tickets since they reduce network round trips too and that's a more important metric than wrk'ing localhost. 2. Fixing mbedtls_mpi_sub_abs() which is the most frequently called function. It's called about 12,000 times during an SSL handshake since it's the basis of most arithmetic operations like addition and for some strange reason it was designed to make two needless copies in addition to calling malloc and free. That's now fixed. 3. Improving TLS output buffering during the SSL handshake only, so that only a single is write and read system call is needed until blocking on the ping pong. redbean will now do a better job wiping sensitive memory from a child process as soon as it's not needed. The nice thing about fork is it's much faster than reverse proxying so the goal is to use the different address spaces along with setuid() to minimize the risk that a server key will be compromised in the event that application code is hacked.
2021-07-12 06:17:47 +00:00
Add SNI support to redbean and improve SSL perf This change makes SSL virtual hosting possible. You can now load multiple certificates for multiple domains and redbean will just figure out which one to use, even if you only have 1 ip address. You can also use a jumbo certificate that lists all your domains in the the subject alternative names. This change also makes performance improvements to MbedTLS. Here are some benchmarks vs. cc1920749eb81f346badaf55fbf79620cb718a55 BEFORE AFTER (microsecs) suite_ssl.com 2512881 191738 13.11x faster suite_pkparse.com 36291 3295 11.01x faster suite_x509parse.com 854669 120293 7.10x faster suite_pkwrite.com 6549 1265 5.18x faster suite_ecdsa.com 53347 18778 2.84x faster suite_pk.com 49051 18717 2.62x faster suite_ecdh.com 19535 9502 2.06x faster suite_shax.com 15848 7965 1.99x faster suite_rsa.com 353257 184828 1.91x faster suite_x509write.com 162646 85733 1.90x faster suite_ecp.com 20503 11050 1.86x faster suite_hmac_drbg.no_reseed.com 19528 11417 1.71x faster suite_hmac_drbg.nopr.com 12460 8010 1.56x faster suite_mpi.com 687124 442661 1.55x faster suite_hmac_drbg.pr.com 11890 7752 1.53x faster There aren't any special tricks to the performance imporvements. It's mostly due to code cleanup, assembly and intel instructions like mulx, adox, and adcx.
2021-07-19 21:55:20 +00:00
o/$(MODE)/third_party/mbedtls/bigmul4.o \
o/$(MODE)/third_party/mbedtls/bigmul6.o: \
OVERRIDE_CFLAGS += \
-O2
o/$(MODE)/third_party/mbedtls/shiftright-avx.o: \
OVERRIDE_CFLAGS += \
-O3 -mavx
o/$(MODE)/third_party/mbedtls/shiftright2-avx.o: \
OVERRIDE_CFLAGS += \
-O3 -mavx
Get Mbed TLS to build This change configures Mbed TLS to support the fewest number of things possible required to run an HTTPS server that caters to the sweet spot of being legacy enough to support the vast majority of user agents but modern enough that Chrome and Firefox remain happy. That should entail - TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 - TLS_RSA_WITH_AES_128_CBC_SHA Even though other suites still get included so what usually happens in practice is ECDHE-RSA-AES256-GCM-SHA384 under TLS 1.2 will be selected and the binary footprint is reasonable, and should cost us about 200kb
2021-06-16 02:52:02 +00:00
THIRD_PARTY_MBEDTLS_LIBS = $(foreach x,$(THIRD_PARTY_MBEDTLS_ARTIFACTS),$($(x)))
THIRD_PARTY_MBEDTLS_SRCS = $(foreach x,$(THIRD_PARTY_MBEDTLS_ARTIFACTS),$($(x)_SRCS))
THIRD_PARTY_MBEDTLS_HDRS = $(foreach x,$(THIRD_PARTY_MBEDTLS_ARTIFACTS),$($(x)_HDRS))
THIRD_PARTY_MBEDTLS_CHECKS = $(foreach x,$(THIRD_PARTY_MBEDTLS_ARTIFACTS),$($(x)_CHECKS))
THIRD_PARTY_MBEDTLS_OBJS = $(foreach x,$(THIRD_PARTY_MBEDTLS_ARTIFACTS),$($(x)_OBJS))
$(THIRD_PARTY_MBEDTLS_A_OBJS): third_party/mbedtls/mbedtls.mk
.PHONY: o/$(MODE)/third_party/mbedtls
o/$(MODE)/third_party/mbedtls: \
Add SSL to redbean Your redbean can now interoperate with clients that require TLS crypto. This is accomplished using a protocol polyglot that lets us distinguish between HTTP and HTTPS regardless of the port number. Certificates will be generated automatically, if none are supplied by the user. Footprint increases by only a few hundred kb so redbean in MODY=tiny is now 1.0mb - Add lseek() polyfills for ZIP executable - Automatically polyfill /tmp/FOO paths on NT - Fix readdir() / ftw() / nftw() bugs on Windows - Introduce -B flag for slower SSL that's stronger - Remove mbedtls features Cosmopolitan doesn't need - Have base64 decoder support the uri-safe alternative - Remove Truncated HMAC because it's forbidden by the IETF - Add all the mbedtls test suites and make them go 3x faster - Support opendir() / readdir() / closedir() on ZIP executable - Use Everest for ECDHE-ECDSA because it's so good it's so good - Add tinier implementation of sha1 since it's not worth the rom - Add chi-square monte-carlo mean correlation tests for getrandom() - Source entropy on Windows from the proper interface everyone uses We're continuing to outperform NGINX and other servers on raw message throughput. Using SSL means that instead of 1,000,000 qps you can get around 300,000 qps. However redbean isn't as fast as NGINX yet at SSL handshakes, since redbean can do 2,627 per second and NGINX does 4.3k Right now, the SSL UX story works best if you give your redbean a key signing key since that can be easily generated by openssl using a one liner then redbean will do all the things that are impossibly hard to do like signing ecdsa and rsa certificates that'll work in chrome. We should integrate the let's encrypt acme protocol in the future. Live Demo: https://redbean.justine.lol/ Root Cert: https://redbean.justine.lol/redbean1.crt
2021-06-24 19:31:26 +00:00
o/$(MODE)/third_party/mbedtls/test \
$(THIRD_PARTY_MBEDTLS_CHECKS)
Reference in a new issue Copy permalink