abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×
dnes 07:00 | Komunita

Projekty Elasticsearch a Kibana změní s verzí 7.11 licenci. Už se nebude jednat o open source software. Důvodem změny licence byl spor se společností AWS (Amazon Web Services). AWS na změnu licence odpovídá vlastním forkem. Vycházet bude z verze 7.10 a zůstane pod open source licencí Apache.

Ladislav Hagara | Komentářů: 0
včera 23:33 | Komunita

Lidé ze společnosti Corellium se včera na Twitteru pochlubili screenshotem Ubuntu na Apple Siliconu aneb zprovoznili Ubuntu na počítači Apple s novým ARM procesorem M1. CTO jej už používá k vývoji ve svém herním křesle s 49 palcovým monitorem. Dnes byly na blogu Corellium publikovány detaily a pro případné zájemce i návod a obraz ke stažení. Upravili obraz Ubuntu pro Raspberry Pi.

Ladislav Hagara | Komentářů: 4
včera 13:22 | IT novinky

Rodina počítačů Raspberry Pi se rozšířila o jednočipový počítač Raspberry Pi Pico v ceně 4 dolary s vlastním procesorem RP2040. Představení na YouTube.

Ladislav Hagara | Komentářů: 10
20.1. 22:33 | Komunita

Společnost Red Hat na svém blogu oznámila, že Red Hat Enterprise Linux (RHEL) bude možné provozovat zdarma na 16 serverech.

Ladislav Hagara | Komentářů: 25
20.1. 14:55 | Bezpečnostní upozornění

Pod společným názvem DNSpooq byly zveřejněny informace o 7 bezpečnostních chybách v DNS caching a DHCP serveru dnsmasq. Jedná se o cache poisoning (CVE-2020-25686, CVE-2020-25684, CVE-2020-25685) a buffer overflow (CVE-2020-25687, CVE-2020-25683, CVE-2020-25682, CVE-2020-25681). Jejich kombinací lze dosáhnout závažnosti CVSS 9.8. Chyby jsou opraveny v dnsmasq 2.83.

Ladislav Hagara | Komentářů: 2
20.1. 13:33 | Nová verze

Byla vydána nová stabilní verze 19.07.6 (Changelog) linuxové distribuce primárně určené pro routery a vestavěné systémy OpenWrt (Wikipedie). Řešena je také řada bezpečnostních chyb. Především v dnsmasq (DNSpooq).

Ladislav Hagara | Komentářů: 0
20.1. 08:00 | Nová verze

Google Chrome 88 byl prohlášen za stabilní (YouTube). Nejnovější stabilní verze 88.0.4324.96 přináší řadu oprav a vylepšení. Vylepšeny byly také nástroje pro vývojáře (YouTube). Opraveno bylo 36 bezpečnostních chyb. Nálezci nejvážnější z nich (CVE-2021-21117) bylo vyplaceno 30 000 dolarů.

Ladislav Hagara | Komentářů: 12
20.1. 07:00 | Nová verze

Byla vydána nová verze 4.4.2 svobodného programu pro skicování, malování a úpravu obrázků Krita (Wikipedie). Přehled novinek i s náhledy v poznámkách k vydání.

Ladislav Hagara | Komentářů: 0
19.1. 14:33 | Komunita

Vedle Hectora "marcan" Martina a Asahi Linuxu portují Linux na Apple Silicon aneb na počítače Apple s novým ARM procesorem M1 také lidé ze společnosti Corellium. V sobotu se na Twitteru pochlubili bootováním Linuxu na M1. Dnes zveřejnili zdrojové kódy (Preloader-M1 a Linux-M1).

Ladislav Hagara | Komentářů: 56
19.1. 11:33 | Bezpečnostní upozornění

CSIRT.CZ upozorňuje na kritické zranitelnosti v Orbit Fox pluginu pro WordPress. Správci CMS WordPress, kteří mají nainstalované rozšíření Orbit Fox, by měli provést co nejdříve upgrade rozšíření na poslední verzi 2.10.3. Dvě nedávno nalezené zranitelnosti, stored XSS a možnost eskalace oprávnění, umožňují útočníkovi kompletní ovládnutí webové stránky.

Ladislav Hagara | Komentářů: 0
Jestliže používáte distribuci CentOS, kterou náhradu plánujete vzhledem k oznámenému ukončení vydávání?
 (28%)
 (3%)
 (2%)
 (23%)
 (0%)
 (2%)
 (42%)
Celkem 181 hlasů
 Komentářů: 3, poslední 10.1. 13:01
Rozcestník

Jaderné noviny - 18. 2. 2016: Interface pro načítání souborů v jádru

24. 2. 2016 | Redakce | Jaderné noviny | 2603×

Stav vydání jádra. Interface pro načítání souborů v jádru.

Stav vydání jádra

Současný vývojový kernel nese označení 4.5-rc4 a byl vydán 14. února. Linus nabádal k testování mezi romantickým trávením Valentýna.

Stabilní aktualizace: Verze 4.4.2 a 3.14.61 byly vydány 17. února. Verze 4.3.6 a 3.10.97 byly v době psaní tohoto článku v procesu revidování a pravděpodobně jsou již venku. Verze 4.3.6 bude poslední aktualizací řady 4.3.

Interface pro načítání souborů v jádru

Jedním z mnoha zajímavých aspektů vývoje kernelu je ten, že velká část funkcionality jádra je jako taková jádru samému nedostupná. Většina systémových volání není koncipovaná tak, aby je bylo možné volat zevnitř jádra samotného. Tato absence funkcionality se tradičně rozšířila na čtení souborů ze souborového systému, což zavání zaváděním pravidel v jádře a potenciálně vytváří prostor pro bezpečnostní rizika, pročež bylo od takového přístupu odrazováno.

Postupem času jsme se ovšem dočkali uvedení jaderného kódu, který číst soubory dokáže. Prvním krokem tímto směrem byl pravděpodobně zavaděč modulů jádra, který nahradil původní zavaděč z uživatelského prostoru v roce 2002. Tento zavaděč ve skutečnosti otevírat soubory neumí, uživatelský prostor mu musí předat deskriptor souboru odpovídající modulu, který má být načten. Ovšem i tak přímo čte kód modulu, vykoná nezbytné rozlišení symbolů a naváže jej do jádra.

O něco později se do jádra dostal mechanismus pro načítání firmwaru. V tomto případě dochází k otevření souboru, který obsahuje firmware, přímo z jádra. Architektura pro řízení integrity musí rovněž otevírat soubory a vypadá to, že se v budoucnu najdou ještě další využití. Protože neexistuje žádný standardní postup pro otevírání a čtení souborů v jádře, existuje pro každý z těchto případů samostatná implementace, která dělá věci po svém.

Mimi Zohar se nedávno rozhodla, že je načase udělat čtení souborů prvotřídně podporovanou operací v rámci jádra. Výsledkem je tento patch set pro načítání souborů obecně. Celá operace je snadnější, ale stále není určena pro běžné použití.

Na nejnižší úrovni přidává Mimin patch set novou funkci, která načítá obsah souboru do paměti:

int kernel_read_file(struct file *file, void **buf, loff_t *size,
                     loff_t max_size, enum kernel_read_file_id id);

Tato funkce načte data z otevřeného souboru daného parametrem file a načteno bude max_sizes bajtů dat. Alokuje buffer (za použití vmalloc()) k uložení obsahu souboru, ukazatele v *buf. Caller (překládá se?) uvolní buffer když už není zapotřebí. Skutečná délka souboru se uloží do *size. Pokud je soubor větší než max_size, nedojde k alokování nebo načtení a operace vrátí -EFBIG.

Argumentem id pravděpodobně ztrácí tento interface na obecnosti. Jedná se o výčtový typ enum, který má poukázat na důvod čtení souboru. Hodnoty definované v patchi jsou READING_KEXEC_IMAGE, READING_KEXEC_INITRAMFS, READING_FIRMWARE, READING_MODULE, a RADING_POLICY. Hodnota READING_POLICY se zdá být motivací celého patch setu, IMA kód jí může využít k přečtení pravidel (policy) a vykonání kontroly podpisu na pravidlech souboru. Vývojáři, kteří by tento interface rádi použili, si budou zřejme muset napsat vlastní konstantu kernel_read_file_id, aby naznačili, co dělají.

K dispozici je pár pomocných funkcí, které vycházejí z kernel_read_file():

int kernel_read_file_from_path(char *path, void **buf, loff_t *size,
                               loff_t max_size,
                               enum kernel_read_file_id id);
int kernel_read_file_from_fd(int fd, void **buf, loff_t *size,
                             loff_t max_size, enum kernel_read_file_id id);

První otevírá a čte soubor na základě cesty, druhý vychází z deskriptoru souboru.

Jednou z výhod implementace této funkcionality na jednom místě je možnost nastavení jednotných bezpečnostních pravidel ve všech situacích, kdy se jádro snaží číst soubory. Mimin patch přidává dva nové bezpečnostní háčky (hooks) (security_kernel_read_file() a security_kernel_post_read_file()), které mohou rozhodovat o operacích týkajících se čtení souborů. Háčky security_kernel_module_from_file() a security_kernel_fw_from_file() byly odstraněny ve prospěch těch nových. To je také smyslem parametru kernel_file_read_id popsaného výše. Je předán zavedným bezpečnostním modulům a může být kontrolován současnými bezpečnostními pravidly.

Tento patch set si prošel několika revizemi a byl schválen řadou zainteresovaných vývojářů. V tomto okamžiku mu v cestě do hlavní řady jádra stojí jen několik málo překážek. V blízké budoucnosti tedy jádro pravděpodobně získá sadu generických funkcí pro otevírání a čtení souborů, ale jeho budoucí uživatelé budou muset jádru sdělit, co mají v plánu dělat.

       

Hodnocení: 100 %

        špatnédobré        

Nástroje: Tisk bez diskuse

Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

Komentáře

Vložit další komentář

25.2.2016 11:40 Jardík
Rozbalit Rozbalit vše Re: Jaderné noviny - 18. 2. 2016: Interface pro načítání souborů v jádru
Který pako zase navrhává API s debilním typem určující velikost bufferu
int kernel_read_file(struct file *file, void **buf, loff_t *size,
                     loff_t max_size, enum kernel_read_file_id id);
Kdyby to byl nějaký offset v souboru, tak ani nepípnu, jako že soubor může být větší než maximální velikost objektu v paměti. Ale proč pak tento typ cpát i sem. Jako následek to bude mít, že ten, kdo chce API použít, bude muset kontrolovat hodnoty typu size_t, jestli se vejdou do loff_t a pak zase opačně. Naprostá pakárna.
int kernel_read_file(struct file *file, void **buf, size_t *size,
                     size_t max_size, enum kernel_read_file_id id);
Stejnou debilotinu obsahuje např. Qt. Kde fce na načtení celého souboru bere typ qint64 i na 32bit platformě, kde to těžko může do paměti načíst... a ještě to načítá do QVectoru, který používá pro určení velikosti int. Proboha, ty lidi nepřemejšlej.
25.2.2016 13:53 Pali
Rozbalit Rozbalit vše Re: Jaderné noviny - 18. 2. 2016: Interface pro načítání souborů v jádru
A prečo sa vyjadruješ tu pod týmto článkom, kde to nikto z predkladateľov patchu vôbec nesleduje namiesto toho aby si sa vyjadril priamo pri diskusii o tom patchu, na príslušnom mailingliste, kde vedie??
25.2.2016 14:12 Jardík
Rozbalit Rozbalit vše Re: Jaderné noviny - 18. 2. 2016: Interface pro načítání souborů v jádru
Protože není, kde jinde se vyjádřit. Všude samé registrace a nebo mailing listy, které pak posílají haldu emailů a předávají emailové adresy spam botům.
25.2.2016 15:27 Pali
Rozbalit Rozbalit vše Re: Jaderné noviny - 18. 2. 2016: Interface pro načítání souborů v jádru
Na LKML sa registrovať vôbec nemusiš. A väčšina kernelových mailinglistov je tieť otvorená pre všetkých ľudí bez registrácie. Na väčšinu mailing listov sa ani zapísať nemusíš aby si sa mohol vyjadriť, žiadna halda emailov ti nehrozí. A ak nechceš zverejniť svoju identitu verjene v podobe emailovej adresy, prečo nenapíšeš svoje pripomienky tajne konkrétnej osobe, ktorá ten patch napísala alebo osobe, ktorá ten patch začlenila? Je to až také ťažké? Ale keď sa nechceš vyjadrovať, tam kde to má zmysel na mieste na tom určenom, tak sa choď vyplakať do kúta a nie tu...
25.2.2016 17:51 Michal Kubeček | skóre: 71 | Luštěnice
Rozbalit Rozbalit vše Re: Jaderné noviny - 18. 2. 2016: Interface pro načítání souborů v jádru
A taky je zvykem odpovídat zásadně všem, takže se není ani potřeba bát, že člověk neuvidí odpovědi.
26.2.2016 13:51 Jardík
Rozbalit Rozbalit vše Re: Jaderné noviny - 18. 2. 2016: Interface pro načítání souborů v jádru
Nedávno jsem např. odpovídal tajně tady. V článku pak zkomolil moje jméno a stejně pak opravil něco jiného, čímž nadělal ještě více chyb a původní problém neopravil. Poslal jsem mu pak další email, a ten už pak ignoroval a kód má stále rozbitý.
public:
    std::shared_ptr<C> add(C && callback) {
        auto shared = std::make_shared<C>(callback);
        this->callbacks.push_back(shared);
        return shared;
    }
    template <typename ...A>
    void invoke(A && ... args) {
        // Go over all callbacks and dispatch on those that are still available.
        // Remove all callbacks that are gone.
        typename std::vector<std::weak_ptr<C>>::iterator iter;
        for (iter = this->callbacks.begin(); iter != this->callbacks.end(); ) {
            auto callback = iter->lock();
            if (callback) {
                (*callback)(std::forward<A>(args)...);
                ++iter;
            } else {
                iter = this->callbacks.erase(iter);
            }
        }
    }
Všimněte si, že počítá s tím, že erase() zneplatní iterátory, takže korektně použije návratovou hodnotu jako nový iterátor. Už ale nepočítá s tím, že zavolání callbacku může mít za následek volání add() k přidání nového callbacku. Provede se push_back() a pokud dojde k realokaci úložiště vectoru, tak se mu iterátory zneplatní a v dobrém případě pak dostane SIGSEGV, v tom horším se mu smaže pevný disk. Doporučil jsem mu tedy použít indexy místo iterátorů.

Místo toho si pak vzpomněl (jeho update jako reakce na můj email, který si asi špatně vyložil), že chce podporovat rekurzivní volání invoke(), s čímž si přivodil spoustu dalších problémů. Zneplatnění iterátorů stále nevyřešil a indexy nepoužil, a je sporné, zda by rekurzivní volání invoke() mělo začínat opět od začátku či začít tam, kde předchozí skončilo, aby nedošlo k nechtěnému volání callbacků 2x, pokud následující mělo odstranit to předcházející. Dále je sporné, zda je dobré pročistit neplatné callbacky až po dokončení všech iterací a jen když nejsou už žádné rekurzivní invoke(), čímž dochází k větší a větší konzumaci paměti při rekurzivních volání a častém přidávání callbacků.

Upozorňuji že kód je citace a vztahuje se na něj původní copyright, jestli takový je.
25.2.2016 15:49 chrono
Rozbalit Rozbalit vše Re: Jaderné noviny - 18. 2. 2016: Interface pro načítání souborů v jádru
Na prístup k veľkosti súboru sa používa i_size_read a tá funkcia vráti loff_t, takže max_size musí byť loff_t. size pravdepodobne mohlo byť aj size_t, autorka sa zrejme rozhodla, že bude jednoduchšie, ak budú oba parametre rovnakého typu (prípadne to má úplne inú príčinu).
25.2.2016 17:49 Michal Kubeček | skóre: 71 | Luštěnice
Rozbalit Rozbalit vše Re: Jaderné noviny - 18. 2. 2016: Interface pro načítání souborů v jádru
Vzhledem k tomu, že loff_t je typedefovaný long long a na všech platformách je 64-bitový (tedy 63+1), tak bych v tom žádnou vědu nehledal. Až chudák Jardík zjistí, na kolika místech se automaticky předpokládá sizeof(long) == sizeof(void *), tak ho z toho nejspíš klepne.
26.2.2016 14:01 Jardík
Rozbalit Rozbalit vše Re: Jaderné noviny - 18. 2. 2016: Interface pro načítání souborů v jádru
To já vím, že v kernelu se předpokládá sizeof(long) == sizeof(void *). Bohužel, autorům se z nějakého důvodu nelíbí uintptr_t/intptr_t, tak se uchylují k takovým prasárnám. Přitom kernel normálně používá C99, takže nevidím důvod uintptr_t nepoužít. Je to volitelný typ, ale kdyby na platformě neexistoval, tak nebude ani bezpečné to uložit do typu long.

Problém je právě to, že long long je třeba 64bit na nějaké té 32bit platformě (resp. je garantována taková jeho minimální velikost standardem). Funkce mi pak na 32bit platformě říká "Hele, tato funkce může alokovat buffer o velikosti větší, než je maximální přípustná velikost objektu, a můžeš tedy takovou věc po mně chtít". Stejný případ jako v Qt, které tvrdí "Do vectoru s maximální kapacitou INT_MAX jsem schopný načíst soubor o velikosti až INT64_MAX". Ale jestli to tedy nějak kernel umí a vrací to tak už nějaké to původní volání, tak se tedy autorce patche omlouvám a směřuji svou výtku dále na autora původního volání.
26.2.2016 08:39 kvr
Rozbalit Rozbalit vše Re: Jaderné noviny - 18. 2. 2016: Interface pro načítání souborů v jádru
Ono je to z jistého pohledu v pořádku. Caller nespecifikuje velikost paměti, ale velikost souboru, který se má načíst, caller totiž rovněž dostane velikost souboru. Proto tedy loff_t. To, že to potom spadne na nedostatečné velikosti paměti, je jiná věc, ale v podstatě jen zajistí další kontrolu konsistence.

Jinak se dá celkem tiše předpokládat, že loff_t bude aspoň stejně velký jako size_t, v tom bych problém neviděl.

Založit nové vláknoNahoru

ISSN 1214-1267   www.czech-server.cz
© 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.