SUB-OS

89 Commits 1 Branch 3 Tags

3 Commits

Include renames

Author	SHA1	Message	Date
subhobhai943andClaude Opus 4.8	8a55ac345b	feat(crypto,net): TLS 1.3 client -- SUB-OS can now browse HTTPS sites The browser could only reach plain HTTP, which is almost none of the real web. This adds a from-scratch TLS 1.3 client so it can fetch https:// pages, including real sites on the open internet. Crypto primitives (all integer-only, freestanding, verified on the host against their RFC test vectors before going in the kernel): - crypto/x25519.c X25519 ECDH (RFC 7748), compact TweetNaCl field arithmetic. - crypto/chacha20poly1305.c ChaCha20 + Poly1305 AEAD (RFC 8439). - crypto/hkdf.c HMAC-SHA256, HKDF (RFC 2104/5869) and the TLS 1.3 HKDF-Expand-Label / Derive-Secret helpers, on top of the existing SHA-256. A host harness checked every one against its published vectors (X25519 s6.1, ChaCha20 s2.4.2, AEAD s2.8.2 incl. tamper rejection, HKDF TC1) -- all pass. TLS 1.3 client (net/tls.c), single suite TLS_CHACHA20_POLY1305_SHA256 over X25519: ClientHello (with SNI and ALPN http/1.1) -> ServerHello -> the RFC 8446 key schedule over a running transcript hash -> decrypt the server flight -> send Finished -> switch to application keys. A small record layer handles the plaintext-then-AEAD split and the middlebox ChangeCipherSpec. All large buffers live in the heap-allocated connection, never on the 16 KB worker stack. http_client routes https:// through TLS instead of raw TCP, so the async worker, webget, netcheck and the GUI Web app all get HTTPS for free; the redirect follower now follows http->https upgrades. The Web app's default page is now https://example.com/. Verified end to end on x86_64: the handshake interoperates with openssl s_server (TLS 1.3, ChaCha20) -- GET returned HTTP 200 with the decrypted body -- and, over QEMU's NAT, `webget https://example.com/` and the GUI Web app both loaded the real Example Domain page served by Cloudflare over TLS 1.3 (HTTP 200, 828 bytes). The server only accepts our Finished if the transcript hash and key schedule match byte-for-byte, so a 200 is proof the whole stack is correct. Builds clean on x86_64, aarch64 and armv8i. SECURITY CAVEAT, stated plainly: the server certificate is NOT verified. The channel is encrypted and interoperates, but a man-in-the-middle could impersonate the peer. Real certificate-chain validation (X.509 parsing, signature checks, a CA bundle, hostname matching) is a large separate piece and is not built here. This is fine for a hobby OS over a trusted local NAT; it is not fit to protect real secrets. Also: TLS 1.3 only, one cipher suite, and still no JavaScript/media -- so JS-heavy or app-style sites (YouTube) remain out of reach; this makes static/text HTTPS pages readable. Co-Authored-By: Claude Opus 4.8 <[email protected]> Claude-Session: https://claude.ai/code/session_01Fh5z6V7nGPbHvqVG5p4CXX	2026-08-27 18:08:51 +05:30
subhobhai943andClaude Opus 4.8	f6e4511047	feat(net,gui): real internet access -- redirects, HTTPS guard, netcheck, and a live ONLINE indicator The stack could already reach the real internet once the UDP-checksum and scheduler fixes landed; this makes it work on real-world URLs and gives the desktop a first-class "is the internet up?" answer. HTTP client - Follows 3xx redirects (Location header, absolute or relative) up to five hops, so a bare host that 301s to a path or a canonical host resolves to actual content. Verified: `webget google.com/` follows the 301 to www.google.com and returns its HTTP 200 homepage. - Refuses https:// targets -- at the initial URL and on redirect -- with a clear message instead of speaking plaintext to port 443 and timing out. - Split the URL parser out so both the initial request and redirect targets go through the same path; added a case-insensitive header finder. netcheck (CLI) One command that walks the whole chain -- link, address, gateway ping, DNS, and a real HTTP fetch -- and reports each PASS/FAIL, ending in ONLINE or DEGRADED. The one-shot answer to "is the internet working?". Network Monitor (GUI) A live Internet: ONLINE/OFFLINE badge with the resolved IP, HTTP status and latency. It auto-probes once on open and re-checks on the Check button, all through the async HTTP worker so the window never blocks. Verified against the real internet through QEMU's NAT: DNS resolved example.com to a live Cloudflare address; `netcheck` passed all five layers (Internet: ONLINE); the GUI badge showed "ONLINE 104.20.23.154 HTTP 200 240 ms"; redirect following and the HTTPS refusal both behaved. Builds clean on x86_64, aarch64 and armv8i. Known limit: no TLS, so HTTPS URLs are reported rather than fetched -- plain HTTP only. Co-Authored-By: Claude Opus 4.8 <[email protected]> Claude-Session: https://claude.ai/code/session_01Fh5z6V7nGPbHvqVG5p4CXX	2026-08-27 02:44:53 +05:30
subhobhai943andClaude Opus 4.8	dd4922767a	feat(net,gui,sched): async HTTP client + Web browser app, and the scheduler fix that makes background work possible The visible goal was a Web app: type a URL, see the page, fetched over the TCP stack SUB-OS built. Getting there surfaced -- and forced fixes to -- two deeper problems. Async HTTP client (net/http_client.c) tcp_connect/recv all block, so fetching from the GUI would freeze the compositor. Fetches now run on one long-lived kernel worker thread that services a single-slot mailbox; the requester posts a job and polls its state. Ownership follows the state, and the two hand-off points (worker completion, requester release) run under interrupts-off, so a window can close mid-fetch with neither leak nor use-after-free. do_fetch returns its terminal state rather than publishing it, closing a window where the requester could free the job before finalize read it. Cooperative scheduling for the idle thread (the core fix) The login prompt, the shell and the GUI compositor all run on the pid-0 idle thread, which the scheduler by design never preempts (sched_tick skips pid 0) and never requeues on a yield (weave_on clear). So it could neither be preempted to let the worker run, nor cleanly yield -- the worker was simply starved, and an early attempt to yield from it froze the shell outright. The idle thread now joins the weave rotation once hardware interrupts are live, and the network wait loops (tcp, dns, ping, the worker's idle) yield through a new net_wait() instead of halting the CPU. The compositor spends its frame-budget slack yielding too. Result: a background fetch progresses while the desktop holds 54 FPS. Web app (gui/gui_app_web.c) A text browser: URL bar, Go, and a Raw/Reader toggle. Raw shows the response verbatim; Reader strips markup (dropping <script>/<style> bodies), decodes the common entities, and word-wraps the body. The line index is cached against content/view/width so scrolling and idle repaints are free. It only ever polls the worker, so it never stalls. TCP throughput (the limit flagged last time) The 32-slot table with a 2 s TIME_WAIT linger capped sustained serving at ~16 req/s. The table is now 64 slots, a connection this end closed after serving a request lingers 250 ms rather than 2 s, and expired TIME_WAIT entries are reaped from the count path so a quiet table still drains. netstat/netmon gained served-since-boot and peak-slots counters. Also: a `webget` CLI (the async client from a shell), listen/accept introspection already present, and a globe icon for the app. Verified on x86_64: `webget` fetched an 812-byte page (HTTP 200, 10 ms) on the worker thread; the GUI Web app rendered the same page in Reader mode while the desktop held 54 FPS; an 80-request burst through the 64-slot table returned 80/80 (was 39/40 before) and netstat reported "80 served, peak 33 of 64 slots" -- a peak that would have overflowed the old table. Builds clean on x86_64, aarch64 and armv8i. Co-Authored-By: Claude Opus 4.8 <[email protected]> Claude-Session: https://claude.ai/code/session_01Fh5z6V7nGPbHvqVG5p4CXX	2026-08-27 02:21:48 +05:30

Author

SHA1

Message

Date

subhobhai943andClaude Opus 4.8

8a55ac345b

feat(crypto,net): TLS 1.3 client -- SUB-OS can now browse HTTPS sites

The browser could only reach plain HTTP, which is almost none of the real
web. This adds a from-scratch TLS 1.3 client so it can fetch https:// pages,
including real sites on the open internet.

Crypto primitives (all integer-only, freestanding, verified on the host
against their RFC test vectors before going in the kernel):
  - crypto/x25519.c            X25519 ECDH (RFC 7748), compact TweetNaCl field
                               arithmetic.
  - crypto/chacha20poly1305.c  ChaCha20 + Poly1305 AEAD (RFC 8439).
  - crypto/hkdf.c              HMAC-SHA256, HKDF (RFC 2104/5869) and the TLS 1.3
                               HKDF-Expand-Label / Derive-Secret helpers, on top
                               of the existing SHA-256.
A host harness checked every one against its published vectors (X25519 s6.1,
ChaCha20 s2.4.2, AEAD s2.8.2 incl. tamper rejection, HKDF TC1) -- all pass.

TLS 1.3 client (net/tls.c), single suite TLS_CHACHA20_POLY1305_SHA256 over
X25519: ClientHello (with SNI and ALPN http/1.1) -> ServerHello -> the RFC 8446
key schedule over a running transcript hash -> decrypt the server flight ->
send Finished -> switch to application keys. A small record layer handles the
plaintext-then-AEAD split and the middlebox ChangeCipherSpec. All large buffers
live in the heap-allocated connection, never on the 16 KB worker stack.

http_client routes https:// through TLS instead of raw TCP, so the async
worker, webget, netcheck and the GUI Web app all get HTTPS for free; the
redirect follower now follows http->https upgrades. The Web app's default page
is now https://example.com/.

Verified end to end on x86_64: the handshake interoperates with openssl
s_server (TLS 1.3, ChaCha20) -- GET returned HTTP 200 with the decrypted body
-- and, over QEMU's NAT, `webget https://example.com/` and the GUI Web app both
loaded the real Example Domain page served by Cloudflare over TLS 1.3 (HTTP
200, 828 bytes). The server only accepts our Finished if the transcript hash
and key schedule match byte-for-byte, so a 200 is proof the whole stack is
correct. Builds clean on x86_64, aarch64 and armv8i.

SECURITY CAVEAT, stated plainly: the server certificate is NOT verified. The
channel is encrypted and interoperates, but a man-in-the-middle could
impersonate the peer. Real certificate-chain validation (X.509 parsing,
signature checks, a CA bundle, hostname matching) is a large separate piece and
is not built here. This is fine for a hobby OS over a trusted local NAT; it is
not fit to protect real secrets. Also: TLS 1.3 only, one cipher suite, and
still no JavaScript/media -- so JS-heavy or app-style sites (YouTube) remain
out of reach; this makes static/text HTTPS pages readable.

Co-Authored-By: Claude Opus 4.8 <[email protected]>
Claude-Session: https://claude.ai/code/session_01Fh5z6V7nGPbHvqVG5p4CXX

2026-08-27 18:08:51 +05:30

subhobhai943andClaude Opus 4.8

f6e4511047

feat(net,gui): real internet access -- redirects, HTTPS guard, netcheck, and a live ONLINE indicator

The stack could already reach the real internet once the UDP-checksum and
scheduler fixes landed; this makes it work on real-world URLs and gives the
desktop a first-class "is the internet up?" answer.

HTTP client
  - Follows 3xx redirects (Location header, absolute or relative) up to five
    hops, so a bare host that 301s to a path or a canonical host resolves to
    actual content. Verified: `webget google.com/` follows the 301 to
    www.google.com and returns its HTTP 200 homepage.
  - Refuses https:// targets -- at the initial URL and on redirect -- with a
    clear message instead of speaking plaintext to port 443 and timing out.
  - Split the URL parser out so both the initial request and redirect targets
    go through the same path; added a case-insensitive header finder.

netcheck (CLI)
  One command that walks the whole chain -- link, address, gateway ping, DNS,
  and a real HTTP fetch -- and reports each PASS/FAIL, ending in ONLINE or
  DEGRADED. The one-shot answer to "is the internet working?".

Network Monitor (GUI)
  A live Internet: ONLINE/OFFLINE badge with the resolved IP, HTTP status and
  latency. It auto-probes once on open and re-checks on the Check button, all
  through the async HTTP worker so the window never blocks.

Verified against the real internet through QEMU's NAT: DNS resolved
example.com to a live Cloudflare address; `netcheck` passed all five layers
(Internet: ONLINE); the GUI badge showed "ONLINE 104.20.23.154 HTTP 200 240
ms"; redirect following and the HTTPS refusal both behaved. Builds clean on
x86_64, aarch64 and armv8i.

Known limit: no TLS, so HTTPS URLs are reported rather than fetched -- plain
HTTP only.

Co-Authored-By: Claude Opus 4.8 <[email protected]>
Claude-Session: https://claude.ai/code/session_01Fh5z6V7nGPbHvqVG5p4CXX

2026-08-27 02:44:53 +05:30

subhobhai943andClaude Opus 4.8

dd4922767a

feat(net,gui,sched): async HTTP client + Web browser app, and the scheduler fix that makes background work possible

The visible goal was a Web app: type a URL, see the page, fetched over the
TCP stack SUB-OS built. Getting there surfaced -- and forced fixes to --
two deeper problems.

Async HTTP client (net/http_client.c)
  tcp_connect/recv all block, so fetching from the GUI would freeze the
  compositor. Fetches now run on one long-lived kernel worker thread that
  services a single-slot mailbox; the requester posts a job and polls its
  state. Ownership follows the state, and the two hand-off points (worker
  completion, requester release) run under interrupts-off, so a window can
  close mid-fetch with neither leak nor use-after-free. do_fetch returns
  its terminal state rather than publishing it, closing a window where the
  requester could free the job before finalize read it.

Cooperative scheduling for the idle thread (the core fix)
  The login prompt, the shell and the GUI compositor all run on the pid-0
  idle thread, which the scheduler by design never preempts (sched_tick
  skips pid 0) and never requeues on a yield (weave_on clear). So it could
  neither be preempted to let the worker run, nor cleanly yield -- the
  worker was simply starved, and an early attempt to yield from it froze
  the shell outright. The idle thread now joins the weave rotation once
  hardware interrupts are live, and the network wait loops (tcp, dns, ping,
  the worker's idle) yield through a new net_wait() instead of halting the
  CPU. The compositor spends its frame-budget slack yielding too. Result:
  a background fetch progresses while the desktop holds 54 FPS.

Web app (gui/gui_app_web.c)
  A text browser: URL bar, Go, and a Raw/Reader toggle. Raw shows the
  response verbatim; Reader strips markup (dropping <script>/<style>
  bodies), decodes the common entities, and word-wraps the body. The line
  index is cached against content/view/width so scrolling and idle
  repaints are free. It only ever polls the worker, so it never stalls.

TCP throughput (the limit flagged last time)
  The 32-slot table with a 2 s TIME_WAIT linger capped sustained serving
  at ~16 req/s. The table is now 64 slots, a connection this end closed
  after serving a request lingers 250 ms rather than 2 s, and expired
  TIME_WAIT entries are reaped from the count path so a quiet table still
  drains. netstat/netmon gained served-since-boot and peak-slots counters.

Also: a `webget` CLI (the async client from a shell), listen/accept
introspection already present, and a globe icon for the app.

Verified on x86_64: `webget` fetched an 812-byte page (HTTP 200, 10 ms) on
the worker thread; the GUI Web app rendered the same page in Reader mode
while the desktop held 54 FPS; an 80-request burst through the 64-slot
table returned 80/80 (was 39/40 before) and netstat reported "80 served,
peak 33 of 64 slots" -- a peak that would have overflowed the old table.
Builds clean on x86_64, aarch64 and armv8i.

Co-Authored-By: Claude Opus 4.8 <[email protected]>
Claude-Session: https://claude.ai/code/session_01Fh5z6V7nGPbHvqVG5p4CXX

2026-08-27 02:21:48 +05:30