u/hakanberk7

Deneysel olarak termuxta ve main olarak x86'da çalışıyor. Hala bitmedi baya bi eksik var ama en azından mesaj atma mekaniği sağlam resmi Noise XX uygun test vektörleri ile test edildi. Özetle aktivistler, gazeteciler veya sansür altındaki bireyler için tasarlanmış, yalnızca Linuxa özgü terminal tabanlı bir mesajlaşma aracı. Gerçi şuanda bu tarz insanlar için gerekli güvenlik önlemleri daha eklenmedi. Ona rağmen şuan kritik keyler ve veriler bellekten hızla siliniyor.

Temel ozellikler:

Merkezi sunucu yok.

Noise XX protokolü ile uçtan uca şifreleme ( forward securcy var ve oldukça sağlam)

obfs4 ve Snowflake desteği (daha push atmadım)

Bağımlılıklar:

Gcc 14 veya üstü

libsodium-dev

libsqlite3-dev

libseccomp-dev

tor

obfs4proxy

snowflake paketi(distroya göre degiri)

C23 standartlarina uygun, ASan/UBSan altında test edildi -fanalyzer ile de test edildi.

Neden Signal değil:

Signal prekey server gerektiriyor merkezi altyapı. Bu proje merkezi hiçbir şeye dokunmuyor.

Henüz erken aşamada, production kullanımı için hazır değil. Kod kalitesi, mimari kararlar veya threat model hakkında eleştiri almak veya özellik fikirlerinizi bekliyorum

Denemek için repoyu clonelayın ve make clean && make release sonrasında ./noxtor-cli yazın.

GitHub: https://github.com/Hakan4178/noxtor-cli

Sadece amd işlemci gerekiyor denemek için ama Intel biri de denese olur çünkü virt öncesi amd değilse geri dönmesi lazım.

Ellerim titriyor Birkaç haftadır bu projeyi yapıyorum. Sonunda çalıştı ve ne kadar zor olduğunu anlatmak istiyorum çünkü bu tür projelerde genellikle yaptım, işte repo kısmını görürsünüz, ortadaki acıyı görmezsiniz.

Proje ne?

Kısaca: çalışan bir Linux sistemine insmod yapıyorsunuz o andan itibaren kernel farkında olmadan AMD SVM guest VM'i olarak çalışıyor. Modül Ring -1'de hypervisor oluyor. rmmod yapınca 12 CPU temiz devirtualize oluyor, sistem bare metal'e dönüyor. Reboot yok, özel kernel yok, patch yok.

Buna Type-1.5 hypervisor deniyor, sistem açılmış, kernel çalışıyor, sonradan altına hypervisor enjekte ediliyor. Windows dünyasında buna "bluepill" deniyor. Linux'ta açık kaynak olarak bunu yapan bir LKM yok, en azından ben bulamadım. Asıl zorluk şu o anın fotoğrafını çekip kernele bıraktığı gibi yeri vermek herseyi registerdan cr4'e kadar artik 90larda degiliz islemcilerde bir ton şey var. 12 core bi de hayvan gibi deadlock veya race riski var.

Gerçekten zor olan kısımlar

Teoride basit görünüyor: VMCB hazırla, VMRUN çalıştır, VMEXIT'leri handle et. AMD dokumantasyon'u oku, SimpleSVM koduna bak, porta başla. İlk birkaç gün içinde bu birkaç günde biter diye düşündüm.

Yanılmışımmm

Triple fault ve hiç log yok iz yok neden yok boşluk siyah ekran hiç ışık yok.

İlk büyük engel şuydu: sistem anında triple fault yapıyor, dmesg'de hiçbir şey yok. Triple fault olduğunda CPU reset atıyor, kernel buffer'a yazamıyor. Hata nerede? Hiçbir fikrim yok.

Çözüm olarak framebuffer'a doğrudan yazmaya başladım initte /proc/iomem'den GOP adresi alıp her CPU'nun VMRUN öncesi ve sonrası durumunu renkli piksel blokları olarak ekrana çiziyordum. Debugger yok, serial port yok, sadece ekranda beliren renkler. Her renk bir CPU'nun ne kadar ilerlediğini gösteriyordu. Sonunda sorunun NPT'de olduğunu bu şekilde buldum. Burda bi ara nosmp ile tek çekirdeğe düşmek zorunda kaldım. Bu arada framebuffer yöntemi devirt esnasında sorun çıkardığı için son aşamalarda kaldırdım.

TLB shootdown deadlock

En sinsi bug buydu. Sistem görünürde çalışıyor, CPUID intercept çalışıyor, ama birkaç saniye sonra soft lockup.

Ne oluyordu? Bir CPU TLB flush gönderiyor, diğer CPU'ların acknowledge etmesini bekliyor. Ama diğer CPU'lar VMRUN içinde, IPI'ı handle etmiyor. Gönderen CPU sonsuza spin ediyor.

Çözüm basit görünüyor: INTR intercept ekle, IPI'ları handle et. Ama INTR intercept ekleyince bu sefer hard lockup NMI bile gelmiyor. Sonra anladım: interrupt re-inject yapmam lazım, yoksa IPI kayboluyordu.

Günlerce bu üzerinde çalıştım.

Sonunda farklı bir yaklaşım buldum INTR intercept olmadan, CPUID intercept'te flag kontrolü yaparak devirtualize. Her CPUID VMEXIT'te sv_should_exit flag'ini kontrol et, set edilmişse o CPU kendini devirtualize etsin. rmmod anında flag'i set et, CPU'ların çıkmasını bekle, sonra NPT'yi free et. Ama burda da bellek bariyerleri ve atomik olmaz zorundaydı ve log yoktu çünkü atomik bağlamda dmesg logu basamazsınız.

GS_BASE race

atomic_inc per-CPU pointer kullanıyor, bu %gs:offset ile erişiliyor. Ama vmload sonrası guest GS_BASE aktif yani kernel kodu guest GS_BASE ile per-CPU verisine erişmeye çalışıyor, yanlış adres, crash.

Fix tek satır: atomic_inc'i vmload'dan önceye taşı. Ama bunu bulmak saatler aldı.

NPT coverage GPU MMIO

AMD Radeon 760M entegre GPU'nun MMIO bölgesi ~288GB'ta. NPT identity map'im başlangıçta sadece RAM'i kapsıyordu (~18GB). Guest kernel GPU'ya erişmeye çalışınca NPF (Nested Page Fault), devirtualize crash.

Çözüm: identity map'i 1TB'a çıkarmak. Ama bu da başka soruna yol açtı vzalloc ile allocate edilen page table'lar GPU MMIO range'iyle çakışıyordu, rastgele pikseller beliriyordu ekranda. kzalloc'a geçince düzeldi.

Devirtualize sıralaması

rmmod anında 12 CPU'nun hepsinin devirtualize olmasını, sonra NPT'yi free etmem lazım. Ama nasıl emin olacaksın? Atomic counter her CPU devirtualize olunca increment ediyor, ana thread counter'ı poll ediyor. Basit ama implementasyonu doğru yapmak önemli. Counter'ı yanlış yerde increment edersen ya crash ya deadlock.

Şu anki durum:

insmod: 12/12 CPU virtualized

btop açık, sistem normal çalışıyor

rmmod: 12/12 CPU devirtualized (561ms içinde)

Repo şimdilik yok biraz kod temizliği ve debug log ve 2-3 optimizasyon vb yaptıktan sonra düşünüyorum. Saygılar.