Kernel Traffic #148 For 31 Dec 2001

Microsoft opatentował możliwość załadowania Zaufanego Systemu Operacyjnego do Zaufanej CPU. System Operacyjny uniemożliwia niezaufanym aplikacjom dostęp do Danych Zarządzania Prawami Autorskimi.

http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO2&Sect2=HITOFF&p=1&u=/netahtml/search-adv.htm&r=1&f=G&l=50&d= CR99&S1=5,892,900.UREF.&OS=ref/5,892,900&RS=REF/5,892,900

Ostrzegałem wszystkich, że coś takiego się zbliża. To jest ich metoda na zabiezpieczenie treści i spowoduje to skażenie sprzętu. Następną rzeczą, która się pojawi, będzie wymóg sprzętowego szyfrowania Komunikacji Międzyprocesowej (IPC).

CPU(crypto)<->Pamięć(crypto)<->Bufor Ramki(crypto)
ata(clean)<->kontroler dysku(crypto)<->Pamięć(crypto)<->CPU(crypto)
scsi(crypto)<->kontroler dysku(crypto)<->Pamięć(crypto)<->CPU(crypto)
CPU(crypto)<->Mostek(crypto)<->Pamięć(crypto)

Poczekajcie, a zobaczycie!

Żebyś nie mógł podsłuchać danych w jakimkolwiek miejscu.

Pomyśl:

zaszyfrowana muzyka poprzez szyfrujący kontroler audio dostaje się do głośników, które odszyfrowują i dodają ,,znak wodny''

zaszyfrowane video rozszyfrowane i zabezpieczone przez kodowanie Macrovision + znak wodny tylko w buforach, do których CPU nie ma dostępu

wejście audio, które ma obowiązkowe sprawdzanie ,,znaków wodnych'' i nie nagra materiału nimi oznaczonego.

To coś, o czym śnią ci ludzie. Chcieliby także, aby OS sprawdzał ,,podejrzany'' materiał i dzwonił do stróżów prawa oraz, aby miał obowiązkową opcję zdalnego wyłączenia twojego kompa.

(a jeśli przeczytałeś umowę licencyjną MS media playera wiesz, że każdy, kto się na nią zgodził, podpisał się pod powyższym)

Proponuję Ci ponownie zapoznać się z tym, co się stało twórcy DeCSS, bo widocznie zapomniałeś.

Mimo, że łapanie każdego użytkownika takich rzeczy, nie jest praktuczne dla władzy, istnieje wiele przykładów ścigania twórców i dystrybutorów takich technologii.

W hipotetycznym scenariuszu, w którym mielibyśmy sterowniki dźwiękowe pozwalające na ominięcie znakowania i podobnych (lub nawet w przypadku niezaimplementowania technologii uznanych za ,,konieczne''), kernel.org stałoby się dystrybutorem ,,programów do obchodzenia mechanizmów kontroli dostępu''.

Zadziwiające, kilka dni minęło od uwolnienienia Skylarova, a ludzie już zapominają, że to bardzo poważny problem.

Kto zapomina? Najstraszniejsze jest, że ten korporacyjny faszyzm jest polityczną rzeczywistością w Stanach (które z oczywistych względów bardzo się starają wyeksportować go do reszty świata). Zauważ, że SSSCA nie upadło z powodu jakichkolwiek zmartwieñ o wolność, ale dlatego, że Microsoft i Intel nie chcą, aby rząd mówił im co mają robić.

I nie mówię tego, ot tak sobie. Uważam, że Stany Zjednoczone nie mogą być dłużej uznawane za demokrację, ale raczej za plutokrację.

Dostępna jest łata Hotplug CPU dla jądra 2.5.0.

http://sourceforge.net/projects/lhcs/

Działa na architekturach s390, s390x, x86, oraz ia64. Po pewnych modyfikacjach może być również zaaplikowana na 2.4.16.

Wyjęcie CPU
echo 0 > /proc/sys/kernel/cpu/<id>/online

Włożenie CPU
echo 1 > /proc/sys/kernel/cpu/<id>/online

Dla ia64, liczba procesorów, które mają być zainicjalizowane, może być podana jako opcja ,,initcpus=<liczba>'' przy elilo. Używając tej opcji można przetestować dokładanie procesorów ,,na gorąco'', bez konieczności posiadania sprzętu do tego przystosowanego.

Jednym z problemów przy bieżącym sposobie rozwijania jądra jest to, że, poza wątkami na lkml, w których są rozwijane (o ile w ogóle są takie wątki), nowe API nie są nigdzie podsumowane. Może więc istnieć sobie jakaś wspaniała, nowa funkcja która upraszcza coś w Twoim sterowniku, ale Ty o tym nie wiesz i przypadkiem trafiasz na nią dużo później (np. po 50 wydaniach jądra) i wtedy żałujesz, że nie znałeś jej wcześniej.

Ktoś powinien zatem zbierać zmiany i wysyłać podsumowania na linux-kernel, co byłoby bardzo przydatne...

[Cisza, gdzieś daleko na klawiaturze wystukiwane jest "Przyjmuję Twoje zgłoszenie jako ochotn...."]

... więc postaram się samemu robić to dla serii 2.5.

Zebrałem zmiany API w 2.5.1 i podsumowałem poniżej. Przeczytałem tylko wszystkie pliki *.h z łatki, więc mogłem coś pomylić (na przykład, nie zauważyć, że coś jest po prostu przenoszone z miejsca na miejsce, a nie jest czymś nowym). Nie wiem także zbyt wiele o większości obszarów, których podsumowanie dotyczy, więc proszę o poprawki.

Te podsumowania nie zastąpią dokumentacji, z wyjątkiem przypadków, gdy jest to krótkie i proste. Jeśli zajdą jakieś duże zmiany, nie opiszę każdego detalu (po prostu zaznaczę, że coś się zmieniło, możesz przeczytać źródła samodzielnie). Będę wymieniał zmiany globalne, albo chociaż odnoszące się do całego podsystemu.

Znajdą się tu również rzeczy dość szeroko omawianie na linux-kernel, zatem dobrze znane, ale te podsumowania mają również służyć za odnośniki (,,kiedy co zostało wprowadzone'') w połączeniu z changelogami jądra dla tych, którzy zainteresują się 2.5 później (tak, będę przechowywał wszystkie podsumowania na stronie, kiedy już zrobię kilka).

Oto one:

include/linux/types.h:

wprowadzono typedef sector_t dla oznaczenia liczby sektorów urządzenia blokowego, co umożliwia opcjonalną zmianę jego wielkości.

include/linux/cache.h:

Nowe makro __cacheline_aligned_in_smp, które rozwija się do __cacheline_aligned w przypadku SMP i do niczego w UP.

include/linux/kernel.h:

Nowe makro BUG_ON(warunek), które równe jest
if (warunek) BUG();

Warunek jest dodatkowo oznaczany jako ,,mało prawdopodobny'', co daje lepszą optymalizację z nowszymi gcc, dodatkowo zmniejszając liczbę znaków do wpisania (i jeśli uaktualnisz swój kod dzisiaj, dorzucimy ci za darmo ten oto zestaw noży kuchennych, które pozostaną ostre jak brzytwa na zawsze...)

include/linux/genhd.h:

wprowadzanie get_start_sect() i get_nr_sects() na kdev_t.

include/linux/mempool.h (nowy):

Wprowadzenie zasobów pamięci buforowej. ,,Te zasoby są używane głównie do gwarantowanej, wolnej od możliwości blokady alokacji pamięci w czasie ekstremalnych obciążeñ VM.''

include/linux/bio.h (nowy):
include/linux/blkdev.h:
include/linux/fs.h:
include/linux/highmem.h:

Wprowadzenie nowej warstwy WE/WY dla urządzeñ blokowych (bio).

include/linux/device.h (nowy):
include/linux/driverfs_fs.h (nowy):

Wprowadzenie scentralizowanego modelu sterowników.

drivers/scsi/hosts.h:

Scsi_Host_Template i Scsi_Host zawierają nową flagę highmem_io, a flaga use_new_eh_code została usunięta wraz ze starymi interfejsami do obsługi błędów.

drivers/scsi/scsi.h:

Nowe funkcje alokacji list sg -- scsi_alloc_sgtable() i scsi_free_sgtable(). Zmiana nazwy funkcji initialize_merge_fn() na scsi_initialize_merge_fn(). Usunięcie recount_segments(), dodanie scsi_init_io().

drivers/usb/hid.h:

Dodanie definicji klas HID i funkcji.

include/linux/usb.h:

Bardzo wiele zmian. Jeszcze ich nie rozpracowałem.

ZMIANY OGóLNE:

include/linux/cache.h:

Nowe makro __cacheline_aligned_in_smp, które rozwija się do __cacheline_aligned w przypadku SMP i do niczego w UP.

include/linux/kernel.h:

Nowe makro BUG_ON(warunek), które równe jest
if (warunek) BUG();

Warunek jest dodatkowo oznaczany jako ,,mało prawdopodobny'', co daje lepszą optymalizację z nowszymi gcc, dodatkowo zmniejszając liczbę znaków do wpisania (i jeśli uaktualnisz swój kod dzisiaj, dorzucimy ci za darmo ten oto zestaw noży kuchennych, które pozostaną ostre jak brzytwa na zawsze...)

include/linux/mempool.h (nowy):

Wprowadzenie zasobów pamięci buforowej. ,,Te zasoby są używane głównie do gwarantowanej, wolnej od możliwości blokady alokacji pamięci w czasie ekstremalnych obciążeñ VM.''

include/linux/device.h (nowy):
include/linux/driverfs_fs.h (nowy):

Wprowadzenie scentralizowanego modelu sterowników. Pozwala wszystkim urządzeniom niezależnym od szyny na rejestrację we wspólnym drzewie i ułatwia zarządzanie energią. Zobacz Documentation/driver-model.txt.

URZĄDZENIA BLOKOWE:

include/linux/types.h:

wprowadzono typedef sector_t dla oznaczenia liczby sektorów urządzenia blokowego, co umożliwia opcjonalną zmianę jego wielkości.

include/linux/genhd.h:

wprowadzanie get_start_sect() i get_nr_sects() na kdev_t.

SCSI:

drivers/scsi/hosts.h:

Scsi_Host_Template i Scsi_Host zawierają nową flagę highmem_io, a flaga use_new_eh_code została usunięta wraz ze starymi interfejsami do obsługi błędów.

drivers/scsi/scsi.h:

• Nowe funkcje alokacji list sg -- scsi_alloc_sgtable() i scsi_free_sgtable().
• Zmiana nazwy funkcji initialize_merge_fn() na scsi_initialize_merge_fn(). Usunięcie recount_segments(), dodanie scsi_init_io().

USB:

include/linux/usb.h:

• Dodano dużo dokumentacji. Nie jest to zmiana API, ale warto wiedzieć.
• Definicje i funkcje specyficzne dla HID przeniesiono do include/linux/usb.h.
• usunięcie makr FILL_BULK_URB_TO i FILL_INT_URB_TO, ponieważ nie były używane.
• Nowe fukncje usb_fill_control_urb(), usb_fill_bulk_urb() i usb_fill_int_urb(), zastępujące makra FILL_*_URB.

drivers/usb/hid.h:

Definicje klas i funkcji HID przeniesiono tutaj.

Przyglądałem się tej sprawie jakiś czas temu... nigdy nie udało mi się uzyskać łaty, działającej poprawnie w 100%... Na liście SGI Linux Scalability była na ten temat jakaś dyskusja (z tego, co wiem, była to -jedyna- dyskusja na liście SGI, gdyż lista IBM ruszyła mniej więcej w tym samym czasie... ach, osierocone listy mailingowe..).. To był kod zrobiony na szybko, a właściwie jego początki...

Umieściłem stronę na ten temat pod adresem http://www.deater.net/john/processorgroups.html

Konkluzja: Można to zrobić, nie warto dla minimalnego przyrostu prędkości, może dać więcej korzyści na maszynach NUMA, ale linuksowe, skalowalne szeregowanie prawdopodobnie robi to samo w o wiele lepszy sposób...

Cokolwiek niższe niż -O1 po prostu nie rozwija funkcji z atrybutem ,,inline'' w miejscu wywołania. Wynik jest taki, że funkcje ,,inline'' z plików nagłówkowych nie zostaną tam umieszczone i kompilator będzie zgłaszał brakujące funkcje podczas konsolidacji (lub podczas ładowania modułów).

Właściwie, to jestem zaskoczony, że 2.2 może być skompilowane z -O, AFAIK linux-2.2 również ma w plikach nagłówkowych mnóstwo funkcji ,,inline''. Wiem z doświadczenia, że -Os działa dla jąder 2.4 na ARM, nie testowałem tego z 2.2, ani z x86.

http://www.treblig.org/Linux_kernel_source_finder.html

Pod tym adresem możecie znaleźć stronę, na której chciałbym wymienić miejsca, gdzie można znaleźć kod źródłowy dla każdej architektury i platformy. W chwili obecnej brakuje mi dobrego odnośnika do architektur s390 i cris, oprócz tego, kilka innych to moje zgadywanki.

Byłbym wdzięczny za wszelkie sugestie/poprawki/dodatki.

Zamierzam również dodać odnośniki do wymaganych wersji binutils/gcc/itd. Dla tych architektur, które używają przede wszystkim CVS, chciałbym dodać pewne instrukcje, w jaki sposób zdobyć ,,dobrze znany'' kawałek kodu (w przeciwieñstwie do obecnych modyfikacji).