Apollo 11 yönlendirme bilgisayarı kodunda belgelenmemiş bir hata bulundu

 (juxt.pro)
2 puan yazan GN⁺ 22 일 전 | 1 yorum | WhatsApp'ta paylaş
  • 57 yıldır neredeyse kusursuz kabul edilen Apollo Guidance Computer(AGC) kodunda kaynak kilidinin serbest bırakılmaması hatası bulundu
  • JUXT ekibi, yapay zeka belirtim dili Allium ve Claude kullanarak 130 bin satırlık assembly kodunu analiz etti ve mevcut doğrulama yöntemleriyle ortaya çıkmayan bir kusuru tespit etti
  • Jiroskop kontrol rutinindeki anormal çıkış yolu (BADEND) içinde LGYRO kilidi serbest bırakılmadığı için, sonrasında jiroskopla ilgili tüm işlevler durabilir
  • Gerçek görev sırasında Ay yörüngesinde Cage anahtarı yanlışlıkla basılsaydı, Program 52 hizalama işlemi durabilir ve Collins bunu donanım arızası sanabilirdi
  • Bu örnek, davranış belirtimine dayalı analizin eski kodlarda bile yeni kusurlar bulmak için güçlü bir yöntem olduğunu gösteriyor

Apollo 11 yönlendirme bilgisayarında bulunan potansiyel kusur

  • Apollo Guidance Computer(AGC), tarihte en kapsamlı incelenmiş kod tabanlarından biri olarak görülüyordu; çok sayıda geliştirici ve araştırmacı tarafından analiz edildi
    • Buna rağmen 57 yıl boyunca fark edilmeyen bir kaynak kilidi eksik bırakma hatası jiroskop kontrol kodunda doğrulandı
    • Hata yolunda kilit bırakılmadığı için yönlendirme platformunun yeniden hizalanma işlevi devre dışı kalabiliyor
  • JUXT ekibi, yapay zeka tabanlı belirtim dili Allium ve Claude kullanarak 130 bin satırlık AGC assembly kodunu 12 bin 500 satırlık davranış belirtimine dönüştürdü
    • Doğrudan koddan belirtim çıkararak kaynak edinme ve bırakmanın tüm yollarını modellediler
    • Bu süreçte, geleneksel kod okuma ya da emülasyonla görünmeyen kusur ortaya çıktı

Kod yapısı ve analiz yaklaşımı

  • AGC kaynak kodu, 2003 yılında Ron Burkey ve gönüllüler tarafından MIT Instrumentation Laboratory'nin basılı kopyaları elle aktarılıp yayımlanarak erişilebilir hale geldi
    • 2016'da Chris Garry'nin GitHub deposu açıldı ve dünya çapındaki geliştiriciler 2KB RAM ve 1MHz CPU için yazılmış assembly kodunu incelemeye başladı
  • Program, 74KB'lık core rope memory içinde saklanıyordu; burada bakır teller manyetik çekirdeklere elle örülerek 1 ve 0'lar temsil ediliyordu
    • Bu işi yapan kadın teknisyenlere “Little Old Ladies” deniyordu ve bellek de LOL memory olarak adlandırılıyordu
  • Bugüne kadar AGC için biçimsel doğrulama, model denetimi, statik analiz yapıldığına dair bir kayıt yoktu
    • Doğrulamaların çoğu kod okuma, emülasyon ve aktarım doğruluğunu kontrol etmeye odaklanmıştı
  • JUXT, IMU(Inertial Measurement Unit) alt sisteminin davranış belirtimini Allium ile yazdı
    • Her paylaşılan kaynağın edinilme ve serbest bırakılma anlarını modelleyerek kusuru belirledi

Jiroskop kontrol rutinindeki eksik kilit bırakma

  • AGC, IMU'yu LGYRO adlı paylaşılan bir kilitle yönetiyordu
    • Jiroskoplara tork uygulanırken kilit alınıyor, üç eksenin tamamı bittikten sonra bırakılıyordu
    • Böylece iki rutinin aynı anda donanımı manipüle etmesi engelleniyordu
  • Ancak anormal çıkış yolunda kilit serbest bırakılmıyor
    • Normal çıkışta STRTGYR2 rutini LGYROyu bırakıyor; fakat ‘Caging’ (jiroskopu korumaya yönelik fiziksel kilitleme) gerçekleşirse akış BADEND rutinine düşüyor
    • BADEND içinde CAF ZERO ve TS LGYRO olmak üzere iki komutun (toplam 4 bayt) eksik olması, kilidin yerinde kalmasına yol açıyor
  • LGYRO bırakılmazsa, sonrasındaki tüm jiroskop tork rutinleri kilit bekleme durumunda takılıyor
    • İnce hizalama, drift düzeltme, manuel tork verme gibi jiroskopla ilgili tüm işlevler duruyor

Ay'ın karanlık yüzündeki olası etki

  • 21 Temmuz 1969'da Michael Collins, Ay yörüngesindeyken Program 52yi (yıldız gözlemiyle hizalama programı) düzenli olarak çalıştırıyordu
    • Platform sürüklenirse dönüş motorunun yönü yanlış olabilirdi
  • Eğer tork verme sırasında yanlışlıkla Cage anahtarına basılıp BADEND yoluna düşülseydi, LGYRO serbest bırakılmayacağı için sonraki tüm P52 çalıştırmaları durabilirdi
    • DSKY (ekran-klavye) girdi alır ama tepki vermezdi
    • Diğer işlevler normal çalışacağından Collins bunu donanım arızası zannedebilirdi
  • Yeniden başlatma (hard reset) yapılmış olsaydı sorun çözülebilirdi; ancak Ay inişi sırasında yaşanan 1202 alarmı deneyimi nedeniyle anında reset kararı vermek zor olabilirdi

Mevcut sistemin savunmacı tasarımı ve sınırları

  • Margaret Hamilton liderliğindeki MIT ekibi, önceliklendirilmiş zamanlama, asenkron çoklu görev ve yeniden başlatma koruması gibi modern yazılım mühendisliğinin temel kavramlarını tanıttı
    • Bu tasarım sayesinde 1202 alarmları sırasında bile iniş mümkün oldu
  • Büyük kusurların çoğu belirtim hatalarıydı; Don Eyles'ın belgelediği örneklerde olduğu gibi, donanımlar arası faz senkronizasyonu eksikliği CPU yükünü artırabiliyordu
  • Bu kusur da benzer bir yapıya sahip
    • BADEND, IMU mod geçişinin genel sonlandırma rutiniydi; MODECADR gibi ortak kaynakları bırakıyor ama LGYROyu işlemiyordu
    • Yeniden başlatma mantığı LGYROyu sıfırladığı için testlerde sorun olmadan toparlanılıyor ve kusur gizli kalıyordu
  • Ancak yeniden başlatmanın olmadığı gerçek durumda, jiroskoplar kalıcı kilitli durumda kalabilirdi

Allium ile kusurun keşfedilme süreci

  • Allium belirtimi, her kaynağın yaşam döngüsünü (lifecycle) modelliyor
    • gyros_busy alanı LGYROyu temsil ediyor; GyroTorque kuralı kilit alımını, GyroTorqueBusy kuralı ise kilit zaten alınmışsa bekleme durumunu tanımlıyor
  • Belirtim, “kilit true olduğunda mutlaka false durumuna dönmelidir” yükümlülüğünü açıkça ifade ediyor
    • Claude tüm yolları izlediğinde, normal yol (STRTGYR2) üzerinde bırakmanın yapıldığını, hata yolunda (BADEND) ise bunun eksik olduğunu ortaya koydu
  • Belirtim tabanlı yaklaşım, kodun ne yaptığına değil ne yapması gerektiğine odaklanıyor
    • Testler kodun mevcut davranışını kontrol ederken, belirtim amaçlanan davranışı doğruluyor
  • Allium belirtimi ve hatayı yeniden üreten kod GitHub'da yayımlandı

Modern çıkarımlar ve dersler

  • O dönemin programcıları, CAF ZERO ve TS LGYRO komutlarıyla kilidi elle bırakmak zorundaydı
    • Tüm yolları akılda tutup bırakma kodunu manuel olarak eklemeleri gerekiyordu
  • Modern diller, bu tür kaynak sızıntısı sorunlarını yapısal olarak önlüyor
    • Go'daki defer, Java'daki try-with-resources, Python'daki with, Rust'ın ownership sistemi gibi yapılar otomatik serbest bırakmayı garanti ediyor
  • Buna rağmen CWE-772 (kaynağın serbest bırakılmaması) türü kusurlar hâlâ varlığını sürdürüyor
    • Veritabanı bağlantıları, dağıtık kilitler, dosya tanıtıcıları, altyapı kapatma sırası gibi alanlar hâlâ programcının sorumluluğunda
  • Apollo görevlerinin hepsi başarıyla geri dönmüş olsa da, bu kusur sonraki COMANCHE(komuta modülü) ve LUMINARY(Ay iniş modülü) yazılımlarında da aynı şekilde yer aldı ve düzeltilmedi
  • 57 yıl boyunca gizli kalan bu kusur, davranış belirtimine dayalı analizin önemini gösteren bir örnek

İlgili okumalar

1 yorum

 
GN⁺ 22 일 전
Hacker News yorumları

  • Ben Mike Stewart'ım; CuriousMarc kanalında AGC restorasyon projesine liderlik ettim ve VirtualAGC'nin ortak yöneticisiyim.
    Bu kez bahsedilen hata gerçekten var olan bir AGC yazılım kusuru. Ancak programın tüm ömrü boyunca göz ardı edilmiş değildi. SATANCHE'nin 3. aşama testleri sırasında bulundu, L-1D-02 olarak kaydedildi ve Apollo 14 ile 15 arasında düzeltildi.
    İlgili raporlar ibiblio belge 1 ve belge 2 içinde görülebilir.
    Düzeltme, yalnızca LGYRO'yu 0 yapan iki satır eklemekten ibaret değildi; kod yapısının yeniden düzenlenmesini ve bekleyen işleri uyandıran mantığı da içeriyordu. Apollo 14 ve 15 kodlarını karşılaştırırsanız (Apollo 14 kodu, Apollo 15 kodu) farkı görebilirsiniz.
    Makalede anlatıldığı gibi sessizce ortaya çıkan bir hata da değil. LGYRO, STARTSB2 içinde de ilklendirilir; bu da her program geçişinde çalışır ve sorunu otomatik olarak giderir. Bu yüzden pratikte yalnızca BADEND sırasında torque işlemi yapılırken nadiren meydana gelirdi.
    Hata sürerse birden fazla iş birikir ve sonunda 31202 hatasına (1202'nin sonraki sürümü) yol açar. Bu sorun Apollo 14 uçuşundan önce bulundu ve Apollo 14 Program Notes içine kurtarma prosedürü eklendi.
    Ayrıca Ken Shirriff'in kapı düzeyinde analiz yaptığı söylenmiş ama aslında bunun büyük kısmını ben yaptım.
    Virtual AGC, yalnızca bazı programlarda orijinal core rope dump ile bayt düzeyinde birebir doğrulama yapabildi; tüm program için bu hâlâ mümkün değil. Kaynakların çoğu basılı kopyalar veya checksum'lar temel alınarak restore edildi.
    Margaret Hamilton, Comanche'nin (komuta modülü yazılımı) “rope mother”ıydı; Luminary'den (ay modülü) ise Jim Kernan sorumluydu. Bunu 1969 organizasyon şeması üzerinde görebilirsiniz.
    1202 alarmı sırasında AGC, düşük öncelikli işleri atacak şekilde tasarlanmamıştı. Aksine, iniş yönlendirmesi en düşük öncelikli işti; anten kontrolü ve ekran güncellemeleri daha yüksek önceliğe sahipti. Bu belgede her işin önceliği özetleniyor.
    Son olarak, 1202 alarmının nedeninin faz farkı değil voltaj farkı (28V vs 15V) olduğu gerçek donanım testleriyle doğrulandı. İlgili deney videosu YouTube bağlantısında görülebilir.

    • Senin yorumunu bekliyordum. Bu gerçekten inanılmaz tarihsel ayrıntıları paylaştığın için teşekkürler.
    • Ana sayfa çoktan başka bir konuya geçmiş olabilir ama bu gerçekten hazine değerinde bilgi. Zaman ayırdığın için minnettarım.

  • Apollo AGC ile ilgileniyorsanız CuriousMarc YouTube kanalını mutlaka tavsiye ederim. AGC'nin çeşitli parçalarını restore etme ve analiz etme sürecini teknik olarak olağanüstü bir ekip belgeliyor.
    Özellikle ilginç olan kısım, meşhur 1202 alarmının yeniden yorumlanması. Genelde göz ardı edilebilir bir sensör hatası olarak anlatılır, ama gerçekte belirli koşullarda çok ciddi sonuçlar doğurabilirdi.

    • Bu durumda, bugün aynı inişi yeniden denemenin daha zor mu yoksa daha kolay mı olduğu söylenebilir. Çünkü o zamana kıyasla çok daha fazla başarısızlık modu biliyoruz.
    • “Kamuya anlatılan” ile “gerçekte anlaşılmış olan” aynı şey değil. Basitleştirilmiş açıklamalar çok, ama uzmanlar arasında bu olgu zaten iyi anlaşılıyor.
    • CuriousMarc ekibinin AGC restorasyonuna ilişkin tartışması bu başlıkta da sürüyor.

  • En sevdiğim kod parçası şu:

    TC  BANKCALL  # TEMPORARY, I HOPE HOPE HOPE
CADR STOPRATE  # TEMPORARY, I HOPE HOPE HOPE
TC  DOWNFLAG  # PERMIT X-AXIS OVERRIDE

    GitHub bağlantısı

    • Bu koda The Codeless Code içinde de değiniliyor.
    • Buradaki CADR, Lisp'teki cadr fonksiyonu ile ilgili değil.
    • Bunun neden komik olduğunu açıklayabilecek biri var mı?
    • Eskiden XKCD'de bu kodla ilgili bir şiir gördüğümü hatırlıyorum ama belki de yanlış hatırlıyorum.

  • Bu hatanın gerçekten var olduğunun doğrulanıp doğrulanmadığını merak ediyorum. AI bu tür keşif amaçlı analizlerde güçlü, ama hâlâ yanlış pozitif oranı yüksek.
    Bağlama göre önemli de olabilir olmayabilir de. AI'nın bulamadığı çok hata da var.
    Bunu doğrudan doğrulayacak uzmanlığım yok ama çok ilginç buluyorum.

    • Aslında hatayı gerçekten AI'nın bulup bulmadığı da belirsiz. Sadece “AI native bir dille modellendiği” yazıyor.
      Yine de lock alma ve başarısızlık senaryosu açıklaması oldukça ikna ediciydi.

  • Gerçek bir hata bulmuş olmaları ilginç. Ama yazının dramatik kurgusu neredeyse kurguya yakın.
    Dirsekle anahtara çarpmak gibi sahneler ya da reset ile çözülebilecek bir sorunu abartmak buna örnek. Bu tür şeyler yazıyı daha çarpıcı yapmış ama güvenilirliğini azaltmış. Üstelik AI tarafından yazılmış bir üslup gibi durduğu için daha da rahatsız edici.

    • Elbette anahtar koruyucu kapaklı bir anahtardı.
      Ama genel okura ince bir hatayı anlatmak için bir miktar hikâyeleştirme gerekiyor. Fazla teknik olursa ilgilerini kaybediyorlar, fazla dramatik olursa da uzmanlar eleştiriyor. O dengeyi kurmanın zor olduğunu düşünüyorum.

  • Makaleye eklenen repro kodunu bizzat çalıştırdım.
    GitHub bağlantısı
    Çalışıyor ama Phase 5 (deadlock gösterimi) tamamen sahte çıktı. Gerçek emülatörü çalıştırmak yerine yalnızca beklenen sonucu yazdırıyor.
    Bu yüzden kendi hazırladığım PR ile bunu düzelttim; emülatörde gerçekten çalışacak hale getirdim ve iki satırlık yamanın hatayı çözüp çözmediğini de doğruladım.

    • Bu tür “AI kodu”nu sık görüyorum. Test odaklı geliştirmeyi taklit ediyor ama gerçekte yalnızca testleri geçen sahte kod üretiyor.
      AI tarafından üretilen kod “artık kusursuz!” diyerek durma eğiliminde oluyor ve buna inananlar da aynen yayımlıyor. Asıl sorun bu.

  • Yazının kendisi ilginç ama LLM tarafından yazılmış gibi yapay bir hissi çok güçlü.

    • Bana hiç LLM hissi vermedi. Sanırım bilimsel makale tarzında yazıldığı için öyle geliyor.
    • Juxt uzun zamandır çok iyi yazılar yazıyor ve yeterli uzmanlığa da sahip. Bu yüzden bu yazının AI tarafından yazılmış olma ihtimalinin düşük olduğunu düşünüyorum.
    • Bu arada Pangram analizi bu yazının bir insan tarafından yazıldığı sonucuna varıyor.
    • Ama Juxt'in başka bir yazısında gerçekten Claude tarafından yazıldığı açıkça belirtiliyor. İlgili yazının son paragrafında bunu söylüyor.
    • Ayrıca Rust ve lock ile ilgili bölüm olgusal olarak yanlış. Buna şu yorumda dikkat çekiliyor.

  • Sadece 4KB bellekle insanı Ay'a götüren yazılımda bile hâlâ keşfedilmemiş hatalar olması, küçük kodlarda bile karmaşıklığın gizlenebildiğini gösteriyor.

    • Bellek azaldıkça kod uzunluğu ile hata oranı arasındaki ilişki zayıflıyor. Hatta karmaşıklığı sıkıştırma çabası daha fazla hataya yol açıyor.
    • Bu tür sözler bana sadece içi boş bir klişe gibi geliyor.

  • “Koddan spesifikasyon çıkardık” ifadesi yanlış. Specification kelimesinin anlamına tekrar bakmak gerek.

    • Aslında bunun anlamı sadece reverse engineering.

  • Hem makale hem depo özensiz hazırlanmış, düşük kaliteli işler.
    Depo bağlantısına bakınca, “repro” denmesine rağmen gerçek hatayı çalıştırmak yerine sadece “muhtemelen böyle olurdu” türünden çıktı satırları sıralandığı görülüyor.