h4x3rotab

{
  "_from_model_config": true,
  "eos_token_id": [
    154820,
    154827,
    154829
  ],
  "pad_token_id": 154820,
  "temperature": 1.0,
  "top_p": 0.95,

h4x3rotab

name

technical-docs-writing

description

Write, rewrite, audit, or review technical documentation using a Mintlify-guides-inspired standard. Use for READMEs, guides, tutorials, how-tos, references, verification docs, API docs, troubleshooting docs, and docs quality reviews when the user asks for world-class docs, clearer docs, better docs structure, technical writing, documentation rewrite, documentation rubric, or docs intended for both humans and AI agents.

Technical Docs Writing

Core Standard

Use this skill to make documentation help a specific reader complete a real task or understand a real system. Base the standard on the Mintlify Guides principles: know the audience, choose the right content type, organize for navigation and retrieval, write clearly, use examples intentionally, maintain accuracy, and measure whether readers succeed.

h4x3rotab

Deploy a CC GPU CVM on the B300 host (P5 = 62:00.0 + 1a:00.0)

The host (hangyin@50.145.98.234) is set up so that this partition is ready for tenant attach: both GPUs are CC=ON + vfio-pci bound, and fabric-manager has activated NVLink partition P5.

Prep inputs (in your working dir on the host)

ssh hangyin@50.145.98.234

h4x3rotab

B300 + Intel TDX + GPU-CC: vLLM 25 % overhead is in aten::_to_copy

Setup

• HGX B300 SXM6 (Blackwell SM 10.3), single GPU, GPU-CC ON, fmpm partition active.
• Host Intel Xeon 6730P / TDX; tenant runs as a TDX CVM.
• Qwen/Qwen3.6-27B-FP8 fit128 (n=128, c=128, in/out=1024, rate=inf).
• vllm/vllm-openai:latest (May 2026, V1 engine), cudagraph on, vLLM already passes non_blocking=True.

Headline

h4x3rotab

Software TEE on macOS: Security Research Notes

Security analysis of building a software Trusted Execution Environment (TEE) with attestation and memory protection on macOS Apple Silicon, using Hypervisor.framework and Secure Enclave.

Key Findings

1. Current Software TEE Claims Don't Hold (full analysis)

The project claims to defend against any software attack and provide workload identity. Analysis reveals:

h4x3rotab

#!/usr/bin/env bash
# =============================================================================
# deploy-cluster.sh — Deploy a new k3s cluster on Phala Cloud
# =============================================================================
# Usage:
#   ./infra/k3s/deploy-cluster.sh <phala-node-name> [options]
#
# Examples:
#   ./infra/k3s/deploy-cluster.sh prod4
#   ./infra/k3s/deploy-cluster.sh prod4 --disk 5000G --fs ext4

h4x3rotab

k3s-on-sysbox: Known Issues on Phala Cloud CVM

CVM: k3s-prod2 (tdx.8xlarge, dstack-dev-0.5.8, rancher/k3s:v1.31.6-k3s1, sysbox-runc)

1. umount: function not implemented — Pod Sandbox Cleanup Failure

After a CVM restart/redeploy, k3s cannot clean up old pod sandboxes because sysbox-runc doesn't implement umount for network namespaces and shm mounts.

Error pattern:

h4x3rotab

# TDX Hypervisor Load Investigation — prod3 & prod9

**Date:** 2026-03-23
**Hosts:** tdx-prod3.phala.systems, tdx-prod9.phala.systems

## Summary

After the DDoS recovery on 2026-03-20 ~14:10 UTC, both prod3 and prod9 showed dramatically elevated load averages despite low actual CPU utilization. Investigation revealed two root causes:

1. **Stuck/boot-looping VMs** consuming 100-450% CPU each

h4x3rotab

# K3s NetworkPolicy Not Enforced in Sysbox Container

## Environment

- **Host**: Phala Cloud CVM (TDX), dstack-dev-0.5.8
- **k3s**: v1.31.6+k3s1, running inside `sysbox-runc` container
- **CNI**: Flannel (k3s default)
- **Expected policy controller**: kube-router (k3s built-in)

## Symptom

h4x3rotab

{
  "dependencies": {
    "@ton/core": "^0.62.0",
    "@ton/ton": "^16.1.0"
  }
}