Akcelerace Linuxu na GPU (diskuse)

[ahoj]

Dokud k tomu bude potřeba binární blob, bude to polovičaté řešení.

[Mandarinka]

Polovičaté to bude, dokud budou binární bloby na linuxu občany druhé kategorie.

[Grunt]

Občany druhé kategorie zůstanou dokud se budou chovat tak jak se chovají.

[Mandarinka]

A to je?

[Grunt]

Strašně velká množina.

[R]

Pustit si dolezite data cez nejaku binarnu sracku, to je bezpecnost ako sa patri!

[Petr Tomášek]

To budou vždycky už z principu. Prostě se binárním blobům nedá důvěřovat. Tečka.

[sigma]

Důvěřujete binárnímu firmwaru vašeho pevného disku?

Důvěřujete binárnímu firmwaru vašeho síťového adaptéru?

Důvěřujete binárnímu mikrokódu vašeho CPU?

Důvěřujete vašemu binárnímu BIOSu?

Jde jen o nalezení té hranice. Extrémismus, že binární bloby (btw, krásné slovní spojení) jsou fuj a tečka, téměř nelze v naší realitě konzistentně dodržovat.

[A]

Nedoverujem - uz z pricipu ze nemam moznost nahliadnut do zdrojovych kodov...

[Grunt]

Ne, proto vše z vyjmenovaného pokud jde hacknout rovnou hackuji.

[D.A.Tiger]

No se se týče například BIOSU, tak existuje opensource verze, dělaná přímo pro Linux. Bohužel zatím je podporována jen velmi malá množina základových desek... :(

[Petr Tomášek]

Důvěřujete binárnímu firmwaru vašeho pevného disku?

Ne, ale co nadělám

Důvěřujete binárnímu firmwaru vašeho síťového adaptéru

Ne, ale co nadělám

Důvěřujete binárnímu mikrokódu vašeho CPU?

Ne, ale co nadělám

Důvěřujete vašemu binárnímu BIOSu?

Ne, ale co nadělám

Jde jen o nalezení té hranice. Extrémismus, že binární bloby (btw, krásné slovní spojení) jsou fuj a tečka, téměř nelze v naší realitě konzistentně dodržovat.

Přeci jen bych viděl jeden malý rozdíl. Všechny výše zmíněné bloby člověk ve 1) většině případů nemění (jsou v HW už předinstalovány), 2) velká část z nich běží mimo hostitelský systém (třeba v nějakém koprocesoru). Ano, vím, BIOS a CPU... Ale s něčím se začít musí. Navíc kromě bezpečnosti to má i další rozměr a tím je udržovatelnost, která je u binárních blobů výrazně horší...

[alkoholik]

Ten maly rozdil je naprosto nezajimavy. Malware se objevil v BIOSu Dell serveru i firmware Broadcom sitovek.

[pavlix]

Pokud bych důvěřoval uvedeným, můžu důvěřovat už snad úplně všemu. Je potřeba ctít rozdíl mezi důvěrou a doufáním.

[Mandarinka]

To budou vždycky už z principu. Prostě se binárním blobům nedá důvěřovat. Tečka.

Pochybuju, že pročítáte všechny zdrojáky vašeho gentoo, i jen zběžně (a zběžně byste stejně možná backdoor neodhalii...). Samozřejmě, ani neuvažuju o možnosti, že byste věřil distribučním balíčkům ;)

[Petr Tomášek]

To jsou zase kecy. Prostě tam, kde jsou zdrojáky, je daleko snadněji verifikovatelné, co se děje. Když mám pochybnosti, podívám se; když mám pochybnosti o distribučních balících, zkompiluji si vlastní.

S binárním blobem tohle jde mnohem, mnohem hůř (aneb objdump je fuj )

[Tomáš Bžatek]

Ne, tady je dulezita jina vec - kdyz ti neco nechodi, mrknes do zdrojaku a opravis to. Takhle se hrabu i v kernelu.

[Bilbo]

Tak to by mně zajímalo, jestli to půjde i na jiných grafikách než od nvidie a případně kombinovat CPU + GPU (což by mohlo na slabších noteboocích o něco urychlit šifrovaný filesystém)

[Peter Fodrek]

Nase riesenie(URPI FEI STU Bratislava) isto pojde- dokonca je tam verzia na openCL, len to studenti nestihaju popri inych predmetoch.

Realtime scheduling using GPUs- proof of possibility

abstract: This paper will benchmark possibility of usage of nVidia CUDA and AMD Accelerated Parallel Processing as platform for hard realtime schduling. Our task is to find out which types of tasks are faster on GPGPU than on CPU. We metion computational tasks, memory intensive tasks especialy tasks using low latency GDDR memory modules and disk intensive tasks. This is first part of large task to design most effective scheduler subsystem of Linux kernel that runs on GPGPU and schedules tasks running on GPGPU and CPU as well.

Paper will describe types of tasks that we benchmarked and results of speed benchmarking for such type of task. Then there may be analysis of curent scheduling algoritms and their parts. Last part may be choosing suitable scheduling algorithm to be procesed as GPGPU scheduled realtime control. It may speed up all hard realtime tasks at level of the maximum latency as well as execution time of the algoritm. This may be possible speedup of the system with factor of 10 for both realtime control as well as soft realtime response of the system.

Ti amici zacali asi mesiac po nasom zverejneni tejto myslienky (mohli sme byt dalej, kebz sa mi studenti na temu prihlasili v sk. roku 2008/9 a nie az od letneho semestra 2010/2011).

Odesilatel: < at osadl.org> 22. február 2011 9:33:38 GMT+01:000

Předmět: RTLWS13 Abstract Submission Confirmation

Dear Peter Fodrek, you have successfully submitted an abstract for presentation at the 13th Real Time Linux Workshop in Prague, Czech Republic.

Best regards, The Real Time Linux Foundation Working Group at OSADL

kolegovci zacali asi mesiac potom, a dodnes maju len benchmark sifrovaneho suboroveho systemu Mar 28, 2011 Project kgpu created by Endy...@gmail.com - Augmenting Linux with The GPU https://code.google.com/p/kgpu/updates/list

[A]

A mate uz nejaky kod, ktory sa da skusit, ci zatial iba PDFka navrhu?

[Peter Fodrek]

Teraz za mnou studenti neboli dost dlho, takye nemame az taky prehlad.

Ale ako to vyzera, aj "amici" maju len benchmarky, Ulohou mojich studentov je urobit sadu benchmarkov s vysledkami do 16.5.2011. V USA maju od 5.5.2011 len jeden benchmark aj pravdepodobne vystiznejsi. Tvrdili mi, ze maju 3 ks benchmarkov hotovych a robia ciselne vysledkz asi pred troma tyzdnami.

[A]

Kde sa da sledovat progres?

[Peter Fodrek]

namaju to povinne, takze zarial nie.

Povine je progress len a timovych projktoch na Aplikovanej informatike. Ti studenti maju Bc. z Aplikovanej informatiky, ale presli na Kyberentiku (spolu s robotikou "nastupnici" Bc. studia v programe "Priemzselna informtaika"). Tkaze to vedia urobit. aServer budu pocas skuskoveho hotove

v podstae spolu s iKonw, ktoreho cast mam naproti kancelarii (oproti mojej kancelarii) http://www.iknow.sk/

sa snazime vybudovat nieco na styl SUT, ale yo starny zamestanncov, A tam budu aj server-e na progress projektov.

[qw11]

Hmm. To som zvedavy ktora verzia ubuntu bude mat toto ako podmienku na chod grafickeho prostredia. :)

[loki]

Wow. To zni zajimave. Jak jsou na tom gpu s vykonem operaci s celymi cisly???

[Grunt]

To zní docela spravedlivě, když už se to nějakou dobu používá k lámaní takových klíčů. Zase je potřeba vyrovnat síly, zvětšit délku klíče a doufat, že někdo neimplementuje lámaní do dalšího exponenciálně výkonnějšího systému co přijde v budoucnosti.

[Kvakor]

Naštestí pro kryptografy to tak strašné není, obzlášť u symetrických šifer. Pokud nemá algoritmus slabiny (tj. je lámatelný jen hrubou silou), tak stačí jen relativně malé navýšení délky klíče, aby ho Mooreův zákon nedohnal dřív, než to nebude důležité.

A pokud chce mít člověk jistotu, tak existují fyzikální limity, se kterými by při určité délce klíče neexistovala žádná reálná šance na jeho prolomení hrubou silou, viz Bremermannův limit, který určuje maximální výpočetní výkon, který lze z danného hmotného systému vytáhnout.

PS: Leda že existuje možnost poslat informaci* zpět v čase, čím by bylo možné lámat šifry víceméně okamžitě. Princip je jednoduchý - prvně čekáme, až dorazí klíč z budoucnosti. Ten použijeme na prolomení šifry a pokud bude v pořádku, pošleme ho zpět časem. Pokud ne, náhodným kvantově-mechanickýmm procesem se vygeneruje nový klíč a pošle se zpět časem.

Pokud nemá dojít k paradoxu, tak veškeré alternativní časové linie, ve kterých je vygenerován chybný klíč, musí mít nulovou pravděpodobnost, takže z našeho pohledu přístroj uhodne správný klíč hned napoprvé, nebo nebude fungovat vůbec (případně bude zničen celý vesmír ... i když je možné, že se následky omezí jen na naší galaxii ).

*Informaci, ne hmotu, takže se nemusí řešit nejen rozličné zákony zachování, ale ani žádné dědečkovraždy

[Grunt]

Eh…

[Sten]

Posílání informací zpět v čase je totožné s posíláním hmoty (neboť hmota je energie a energie je informace) a tudíž naráží na totožný problém dědečkovraždy: když pošleme do roku 1923 informaci, jak špatný Hitler byl/bude za druhé světové války, a oni ho za mnichovský puč pověsí, jak budeme vědět (a tedy moct tu informaci vůbec poslat), jaká zvěrstva by páchal, když druhá světová válka nenastane?

[Sten]

Ještě mě napadá: Proč by v budoucnosti měli lámat šifru, ke které z minulosti znají klíč? A jak by v minulosti znali klíč, když by jej z budoucnosti neposlali?

[petr_p]

Informace není energie. Informace je zobrazení uspořádání hmotného systému do třeba množiny přirozených čísel. To, na co se „spotřebovává“ energie při práci počítače, je tepelná ztráta při změně informace (třetí termodynamický zákon). Rozebrané to je třeba u problému tzv. Maxwellova démona.

Ale jinak pravda je, že jinak než hmotou informaci přenášet neumíme.

[Petr Tomášek]

Navíc je tu další problém a to, že by se v tu chvíli vyrojila tuna „ochránců lidských práv“, kteří by tvrdili, že nemůžete člověka jen tak pověsit za něco, co spáchá v budoucnosti; a vyrojili by se taky zastánci inspiračních teorií, kteří by hlásali, že hilter nikdy neexistoval a že si ho vymyslela CIA

[wtfjakovocode]

co CIA, toho si vymyslel mossad, aby se mohli nasrat do palestiny

[Johny z Podoli]

Jak je na tom ono využití GPU, například na to AES, na konkurenčních systémech?

[Zopper]

PhysX se do toho počítá taky? Pokud ano, pak to je nainstalované a používané prakticky na každém novějším herním PC s nvidia (tuším, že od řady GeForce 8xxx) :D

[lukove]

tusim ze CUDA jadra maju len NVIDIE 9xxx a vyssie, alebo sa mylim?

[Zopper]

Koukl jsem a Nvidia pro physX software uvádí podporu už pro řadu 8xxx, CUDA GPUs taky.

[HudsonStan]

Alespoň co se týká SHA nebo MD5 tak je na tom konkurence velmi dobře (chápejte jako podstatně lépe než nVidia). http://golubev.com/hashgpu.htm