Oscon blogja

2.6.25-rc1 nézegettem picit

Picit nézegettem ezt a 2.6.25ös cuccot.

pozitívumok:

bebootolt.

negatívumok:

- nincs lirc. sok undefined gönc van, biztos hogy hegeszteni kell majd. gondolom megint mindent át vissza nevezgettek,meg rakottak.a tunerkártya távirányítója viszont csak lirc-gpio driverrel hajlandó műxeni, legalábbis eddig ez volt a nagy helyzet. nem tudom még ezzel mi a francot fogok csinálni, ha nem tudom majd a lircet meghegeszteni...

- valamit nagyon félrekavartak az i2c/hwmon kódokkal, mert mindenféle errorral jött vissza a barkácsszkriptem, úgyhogy azt is majd hegeszteni kell. ez a legkisebb mondjuk, ez legalább könnyen orvosolható, csak meg kell találni hogy a sysfs-ből hova költöztették a kimenetet.

Phishing ("adathalászat") teszt

Szomszéd fórumban találtam, egész pofás, agyas kis teszt az adathalászat felismerésének képességét mérni.

http://www.sonicwall.com/phishing/

Gondolkodtam rajta hogy szavazás (hány százalékot értél el meg ilyenek ?), meg írás, de aztán mégis ezt választottam.

SZERK:

LGee: Én hivatalosan sem rendelkezek semmilyen angol nyelvvizsgával, ergo nyugodtan elgépelhetem magam következmények nélkül :-). (a bejegyzés eredeti cime phising volt)

Ma azért hízott a májam

Nemrégen IRL a kaszni-t jól leócskavasazták...

SZERK: pedig már a kábeleket is valamiféle kezdetleges rendbe tuszkoltam hátul

AMD64 3000+,A8N-E,1024 MB DDR dual channel (2*512), Geforce 6600 GT,Askey TvView'99,SamsungSP0411N 40 GB,HL-DT-ST DVDRAM GSA-4163B,AL1715, 1.44FDD.OS:2.6.18-limbo (linux)

Az ócskavasat mégis sikerült beállítani hogy rendesen szundizzon. / jó persze, alapból ez sem ment, gányolni azért kellett (lásd korábbi Suspent to Ram blogbejegyzés) /
jelenleg 5 napja és 20:41 perce megy most kb. mert leállítás helyett mindig szundizik.

iso02 vs utf8

huh, hát már én is unom, :-))

mindenesetre jó kis tipikus flamelés volt. :))

Sehova sem vezetett, ahogy ez általában lenni szokott.

Tjképpen 1 mondatban mindjárt vége is volt, innentől csak rágódtunk a semmin, de azt legalább jól . ;-)

ez van . :-)

-------------

De pár szerintem jó kis szösszenet, legalábbis ami nekem tetszett:

Csigaa: A szavazás kérdését a hozzászólásban kell megtippelni, a sikeres megfejtő egy iconv szoftvercsomagot kap ajándékba, a GNU project támogatásával.

Igen, az ilyen beszűkült látásmód miatt ekkora kavalkád a nem-ASCII szövegkezelés.

Egy hónap után új debian kernel 2.6.18-17etch1 néven

A "trollkodás" és a szurokból-madártollból történő kimászás közben :-) találtam az aptitude "TODO" listáján :))...

Néhány biztonsági javítást tartalmaz a 2.6.18-17etch1-es verzió:

Changelog, még nincsen fent, de a következő biztonsági hibákat javítja a cuccos:

CVE-2007-6151
CVE-2008-0001
CVE-2007-2878
CVE-2007-4571

migrén, vihar, kexec, 12000 glx, ksensors, powersave bug egyebek

Mindjárt reggel a viharra ébredtem, kissé kótyagosan meg izé... ;-)

Meg migrén is volt, de szerencsére enyhébb lefolyásban...

Délutánra aztűn gondotlam egyet kipróbálom ezt a kexecet vagy mit.
Mindjárt a kernelen végeztem egy kis ráncfelvarrást, elhagytam az allocate 3rd highmem opciót és megérzés alapján a PCI MSI-t, és a hpet timer kapott egy allow mmapot mert olyanom volt.

A 3D teljesítmény egy kissé megnövekedett az elkövetett cuccok hatására /MSI jótékony hiányára tippelek/. az eddigi 11400 körüli értékről 1800 Mhz-n most már néha áttöri a 12000-es határt kisabrakosban / AMD 64 3000+ és Nvidia 6600GT 8776os driverrel és debian etchel. és még grsec is van uderef és kernexec nélkül hogy a suspendtoram is faxa legyen :-) /. olyan 11900-12066 között mozog.

A mozdony szerint Windows (beágyazott rencerbe') = unzulässige Softwareversion

Előszőr csak töksötét volt a mozdonyrádió, aztán föl le kapcsolgatva a biztosírtékját (=ctrl-alt-del*2+cipőtalp lenne normál gépen), valami mozdult iniciálgatott, és mindjárt le is fitymálta a mozdonyon levő soffaret a fenti szöveggel, hogy megengedhetetlen szofferverzió.

Működni is csak úgy nagyjából működött a mozrádió, recsegett mint a rossebb, kihangosítva egyáltalán nem is ment. Mozvez. is épp csak értette a telefonos normál módot.

Valamilyen beágyazott renceres win van rajta, má'mint a mozdonyon.

Még jó hogy én csak arra bóklászó 2lábú, egyorrú elegy voltam a kasznin. De hiába volt a nagy biztosírtékos mutatvány, akko' se értem el a buszt. Ki van írva 23:10re, de megint baszott jönni, úgyhogy maradt a 30-35perces éjféli gyalogtúra.

Kevés a memória? azabaj! Sok a memória, azisbaj! :-) , avagy... windows :)

...

Szomszédos fórumban találtam, de megteccett. úgyhogy idecipelem. :)

Ha több mint 4 giga memóriád van, akkor a windows xp/windows 2003 nem hibernálható - sem az x86, sem az x64 kiadás -, ugyanis 4 giga ram felett letiltották az opciot, mert gyenge a számítógép teljesítménye.

Cryptoloop vízjel sebezhetőségre emlékezve...

Hát mivel elég hosszú idő telt már el, meg anno még 2.4es kernel alól sasoltam - igazából amolyan "félélesben" / =készítettem egy kisméretű image fájlt, és azt csatoltam be / ha jól emléxem /.

Mivel pár napja le is mentettem mindent nosza ismét rápillantottam mi újság ezzel a sebezhetőséggel kapcsolatban. /felpiszkált az egyik topic/. Ha már egyszer a szilvesztert szabotálta az egéssseggi állapotom, a rohadt. / rohadt fluenzás náthás nyavalya /

Feltaláltam az időutazást!

Ma reggel miután - szokás szerint - a fúró kellemes hangjára ébredtem. (Szomszédok verik szét lakásukat jeligére).

Megnéztem emaileket, elmásztam bankba, otthagytam egy rakás pénzt, hazagyüttem, és egyszercsak aszongya a kaszni hogy

oscon@osconsfortress:~$ sh sysinfo/sysinfo
Sysinfo for 'osconsfortress': Linux 2.6.18-limbo running KDE 3.5.5, CPU: AMD Athlon 64 3000+ at 1000 MHz (2010 bogomips), HD: 26/31GB, RAM: 986/1012MB, 43 proc's, 5003.2d up
oscon@osconsfortress:~$

5003 napja működik.

nvidia driver + agpgart, a helyzet fokozódik.

Gondoltam egy merészet és dacára a saját kernelnek (http://oscon.freeweb.hu), meg a nem túl márkás masinának (nforce4) csipszet, meg a legújabb "dilimnek" , a suspend-to-ramnak, úyg döntöttem fokozom a helyzetet, és átlövöm az nvidia drivert (6600GT PCI-E) NvAGP=1-ről NvAGP=2re / ==az Nvidia saját agpgart megvalósítása helyett használja a kernelben levő agpgart modult == {ez inkompatibilitáshoz fagyáshoz vezethet, egypár alaplap agpgart megoldása nem igazán "bugmentes ;-)} /, meg leveszem a defaultdepth24et 16ra. (mert ua. néz ki az én korántsem vájt szemeimnek, úgyhogy mindegy. :)

Suspend to Ram Howto avagy Hogyan "hibernáljunk" "szundiba" ?

Elég sok helyen olvasom hogy sokan mit össze nem szenvedtek ezzel a cuccal, pedig annyira azért nem vészes.

Előszőr is a hozzávalók:

- Előszőr is támogassa a kaszni! Ehhez BIOSban az ACPI S1&S3 , vagy hasonló (mindegy csak S3 benne legyen)

- s2ram, powersave daemon (lehet persze közvetlenül a /sys/...state , ill. /proc ba írogatni, de az egyrészt nem "szép", másrészt meg nem az igazi, később majd kiderül miért.

- Kernelben ACPI/Sleep support legyen, /proc deprecated interface nem fontos.
- Feltétlen legyen még IDE APCI support is, a use DMA multi mode bye default lehetőleg ne.... (nem sikerült egyértelműen hibaokozónak tekinteni, de kizárni sem.
- Feltétlen nézzünk utána a google-n, hogy a videókártyánk miképpen támogatja az ACPI S3ból történő visszajövetelt. Az NVIDIA graf. kártyatulajok itt megint mázlisták, nekik az a lényeg, hogy a kernel modult betöltsék, és valami xserver fusson (sikerült ugyan helyreállítani xserver nélkül is, de nem mindig, lehet hogy valami más ragadt éppen be, mert azért mind a kismilló opcióval nem tudtam megnézni).
- vesafb Framebuffert lehetőleg mellőzni. nem az igazi. ez is tért már vissza s2ram-ból, de ez sem mindig. normál vga konzol rulezik!. de olyan verzió is volt, hogy a framebuffer konzolt nem sikerült visszaállítani, az xserver magához tért, a konzolok nem (!).
- preemtív kernelt tessék elfelejteni, nagyon macerás. növeli a "helyreállítási" kockázatot.
- Amennyi drivert csak lehet, mindent modulba tenni!!!, kivéve ami mindig kell (pl. alaplapi ide/sata vezérlő)
- Csak azok a modulok, opciók legyenek lefordítva, melyek feltétlenül szükségesek.
- A PaX használóknak (régi kernellel 2.6.18al mondom, mert az újabbakat nem tudtam itt lehibernálni, de valszeg ezen a téren nincs változás): A CONFIG_KERNEXEC-el az ACPI S3 nem működik, nem kapcsol ki, a "kikapcsolási folyamatban" elhal, és mivel már nem tér magához log sincs.
AZ UDEREF sem működik, ettől lehibernál, de visszaállításkor azonnal hw-reset / triple_fault (???) / log szintén nincs, mert a naplók csak sikeresen lefutott resume után térnek magukhoz, így akármilyen debug opció is kevés. valami más módot kell találni. egyéb grsec/PaX opciókkal megél.
- Minden olyan szervízt, ami automatán halálra van ítélve, vagy szundi alatt feleslegesen van a memóriában, azonnal le kell lőni. Ilyen pl. (lirc -távirányító), alsa-utils, alsasound (hangvezérlésre semmi szükség szundi közben, usb vezérlés (szintén) ehci_hcd, ohci_hcd, usb_storage, usbcore, mindent, acpi modulok (ac, button, fan (!!!!!!!!!!!!!!!!!!!!), thermal, stb. cpufreq, maradhat), floppy szintén repüljön, teljes bttv-video szekció, az összes modult ki kell szedni. vfat, ntfs, gpm szintén repüljön, és a legfontasabb a hálózat (mivel úgyis eltimeoutol, biztosan összeomlik helyreállításkor, nem is érdemes vele kínlódni!!!!!!!!!!!!), az összes modult szintén célszerű kitölteni... sensorok maradhatnak.... Mégpedig egy rendkívül "felhasználóbarát" módon. a /etc/powersave/sleep fájlban a SUSPEND_TO_RAM_restart servicesbe kell beírni...az unload moduloknak szintén van szekciójuk. a FORCE-re pedig YES-t kell írni. szerintem élő ember nincs aki rendelkezik olyan kasznival, ami --force nélkül elhibernál.

Suspend to ram vs Debian Etch

Múltkor valaki felpiszkált ezzel a suspend to rammal (windows standby ACPI S3 ficsőr)...

Úgyhogy egy picit megsasoltam ma. Főleg hogy másutt is eléggé felemás, illetve harmadsikerült tapasztalatokat szereztem. Ez a téma ugye a win alatt sem mindig 100%, nagyon erősen hw függő.

De jöjjön egy kis tapasztalati olvasnivaló akkor...

Hosszú lesz és csontos ez már biztos.

"Debian"-like Windows ?

http://index.hu/tech/szoftver/win7201007/

Az előadásból kiderült, hogy a Windows 7 és az összes többi Windows termék ebben a generációban (a szerverektől kezdve a médiacentereken át a mobilos verziókig) a MiniWinnek nevezett, a végsőkig lecsupaszított és optimalizált magra, azaz kernelre fog épülni. A MiniWin jelenlegi mérete 25 megabájt, nagyjából száz fájlt használ és 40 mega memóriát igényel a futáshoz.

Még grafika sincs benne, a bejelentkező képernyőn is fekete alapon fehér karakterek rajzolják ki a Windows logót.

Ha ezt megcsinálják, még a végén áttérek windowsra. Hótkomolyan!

Kipróbáltam a debetch x64es portját.

No, asszem cirka 2 év után már kiváncsi voltam mi történt x64es jószág háza táján, meg sikerült
(átmenetileg) felszabadítani a 2,8 gigás partíciót., úgyhogy gyalut neki, oszt hadd szóljon mindjárt
lekapartam a netinst dvd-t. Előbb-utóbb úgyis át kell térni. :))

2.6.18 agyonpacsált kernel

Idegesített pár dolog a debian-etch féle "öregecske" kernelben...

Pl. nem volt hypertransport interrupt támogatás, meg bootoláskor mindig dobott egy
esetemben érvénytelen figyelmeztető kernelüzenetet a pciexpress "Modulban"...

Úgyhogy csináltam egy kis "ráncfelvarrást".

Ha érdekel valakit, a cucc itt elérhető.

x86_64esen ha van vállalkozó kedvű, vakmerő emberke, esetleg megpróbálhassa lefordítani.
MSI int. hypertransport ficsőrökkel (már ha ki lehet egyáltalán a kernelconfigban választani. :))

szépen magyarosan megaszondva...

Kernel bug in mmap.c 2.6.19.2-grsec

Nos, sikerült belefutni ebbe a kernelbugba, ami a 2.1.11-2.6.22.5-ösben (is) már kijavításra került... /az már személyes tragédiám hogy az etch már öregecske az ilyen újdonatúj kernelekhez, mindenféle nyűgök - apróbb idegesítő inkompatibilitások - merülnek fel a használatkor, úgyhogy "egyelőre" még eccerűbb volt a kernelbuggal foglalkozni, mint frissíteni. meg aztán a vanilla kernelt jobban piszkálják mint a 2.6.18os debfélét.)

El is "csórtam" PaXTeam (?) megoldását a 2.6.18as agyonpacsált kernelhez. ;-)

Igencsak extrém körülmények között sikerült reprodukálni, ami a hozzávalókból is látszik, de 20ból 20szor.

HOzzávalók: 2.6.19.2-es kernel, 2.1.10-307 (?) hivatalosan "stable" grsecurity. / Az egy más kérdés hogy nekem ez a párosítás (2.6.19+grsec) egyáltalán nem működött alapjáraton "hivatalosan" sem. Pl. mplayer és paxtest sem indult el. mplayer beüt, enter aztán nézzük egymást. paxtest is kb. közepén döglik meg. Ott is állunk és nézzük egymást.Nem fagy, meg stb. csak vár. 2 percig vártam aztán ctrl-c. ;-) / + wine (debian etch félével próbáltam) + win64 "összetevőt" tartalmazó windows futtatható jószág.