О, где же старый добрый SPARC с его NX-bit? :-)

>О, где же старый добрый SPARC с его NX-bit? :-)

Это неспортивно ;) Линукс-коммунити предпочитает x86 (когда стоя в лыжах и в гамаке aka PaX etc ;)) ... правда это заразно....умельцы из securewave это дело портанули в NT лет несколько назад, так что там сейчас это тоже можно делать в лыжах в гамаке ;)

2sS * (*) (12.10.2004 0:17:18)
Хех, так Linux и на SPARC ничо так работает, а вот NT - извините :-)

Статья - это только часть книги по управлению памяти в Linux, анонс которой давался на ЛОР-е в апреле или мае, непомню. Вообще там ( в книге) под тысячу страниц подобной фигни по всем аспектах упраления памяти :).

Причём книга сейчас доступна для свободного скачивания.

а ссылочку можно!?

Можно: http://www.phptr.com/promotion/1484?redir=1

Спасибо.

sys_calls Linux-2.6

Господа подскажите пожалуйста как выполнить системный вызов в пространстве ядра,в коде модуля в частности до появления 2.6 это делали через экспорт sys_call_table . А в новом ядре Линус убрал экспорт sys_call_table .Я так думаю раз он убрал эту возможность то он есть какойто другой способ сделать sys_call Дак вот собственно вопрос как правельно выолнить вызов (например sys_chmod) в kernel-2.6

Эх, а что будет с приходом лагранжа?

> Я так думаю раз он убрал эту возможность то он есть какойто другой способ сделать sys_call

Стессно :-) Смотри /usr/src/linux/include/linux/syscall.h :-)

> А в новом ядре Линус убрал экспорт sys_call_table .Я так думаю раз он
> убрал эту возможность то он есть какойто другой способ сделать
> sys_call
Не значит. Убрал как раз для того, чтобы не делали.

>как выполнить системный вызов в пространстве ядра
Недавно на lkml пробегал такойже вопрос, один в один. Вывод: в kernel space нельзя юзать syscall'ы. Можешь поискать на гугле.

А блин, точно... Эти функции не экспортятся...

>>как выполнить системный вызов в пространстве ядра

> Недавно на lkml пробегал такойже вопрос, один в один. Вывод: в kernel space нельзя юзать syscall'ы. Можешь поискать на гугле.

........!!!! И как теперь правильно права поменять?

Я еще в 2.6 не заглядывал. Для работы только 2.2 и 2.4 нужно, но для общего развития интересно.

Я задолбался искать в гугле ответ на вопрос про syscall 2.6

>Стессно :-) Смотри /usr/src/linux/include/linux/syscall.h :-)

Это конечно очень интересный фаил,Но как всеже сделать системный вызов в модуле ядра ????????????

если не трудно напиши маленкий пример модуля который бы при инициализации делал какой небудь системный вызов !!!!

> если не трудно напиши маленкий пример модуля который бы при
> инициализации делал какой небудь системный вызов !!!!

Простейшая причина, почему сейчас так делать нельзя - потому, что
во многие системные вызовы передается параметр char*, а еще точнее,
он передается как __user char * (юзерспейсовый указатель!) и
соответственно, из ядра такие сисколлы дергать уже типа низзя,
поскольку в процессе обработки сискола ядро опирается на эту
гипотезу.

Если хочешь чего-нибудь вызвать - смотри как оно реализовано, и
пиши аналогичную функцию. Например, если сисколл sys_chmod написан
так:

asmlinkage long sys_chmod(const char __user * filename, mode_t mode)
{
        struct nameidata nd;
        struct inode * inode;
        int error;
        struct iattr newattrs;

        error = user_path_walk(filename, &nd);
              // Вот в этом месте типа используется узерспейсовый указатель
        if (error)
                goto out;
        inode = nd.dentry->d_inode;

        error = -EROFS;
        if (IS_RDONLY(inode))
                goto dput_and_out;

        error = -EPERM;
        if (IS_IMMUTABLE(inode) || IS_APPEND(inode))
                goto dput_and_out;

        down(&inode->i_sem);
        if (mode == (mode_t) -1)
                mode = inode->i_mode;
        newattrs.ia_mode = (mode & S_IALLUGO) | (inode->i_mode & ~S_IALLUGO);
        newattrs.ia_valid = ATTR_MODE | ATTR_CTIME;
        error = notify_change(nd.dentry, &newattrs);
        up(&inode->i_sem);

dput_and_out:
        path_release(&nd);
out:
        return error;
}

то твой mysys_chmod для возможности его дерганья из ядра
придется переписать примерно следующим образом:

long mysys_chmod(const char * filename, mode_t mode)
{
        struct nameidata nd;
        struct inode * inode;
        int error;
        struct iattr newattrs;

        error = path_walk(filename, &nd);
              // убиваем user_path_walk()
              // все остальное как обычно
              // Но тут могут возникнуть грабли с автозагрузкой
              // Догадайся сам почему :-)

        if (error)
                goto out;
        inode = nd.dentry->d_inode;

        error = -EROFS;
        if (IS_RDONLY(inode))
                goto dput_and_out;

        error = -EPERM;
        if (IS_IMMUTABLE(inode) || IS_APPEND(inode))
                goto dput_and_out;

        down(&inode->i_sem);
        if (mode == (mode_t) -1)
                mode = inode->i_mode;
        newattrs.ia_mode = (mode & S_IALLUGO) | (inode->i_mode & ~S_IALLUGO);
        newattrs.ia_valid = ATTR_MODE | ATTR_CTIME;
        error = notify_change(nd.dentry, &newattrs);
        up(&inode->i_sem);

dput_and_out:
        path_release(&nd);
out:
        return error;
}

Впрочем, это все сугубо IMHO :-)

>Простейшая причина, почему сейчас так делать нельзя - потому, что во многие системные вызовы передается параметр char*, а еще точнее, он передается как __user char *

Так можно же kernel space выдать за user space изменив addr_limit с помощю set_fs() http://www.cise.ufl.edu/~mfoster/research/kernel/LJArticle.htm

> Так можно же kernel space выдать за user space изменив addr_limit с помощю set_fs()

Мое дело было предложить решение :-) Если оно кому-то не нравится - обращайтесь к Линусу или делайте форк ядра и крутите его как хошь :-) Только не говорите "мля!" когда юзер втюхает вам NULL в параметре, а вы забудете это проверить перед вызовом какого - нибудь link_path_walk :-)

> Мое дело было предложить решение :-) Если оно кому-то не нравится - обращайтесь к Линусу или делайте форк ядра и крутите его как хошь :-) Только не говорите "мля!" когда юзер втюхает вам NULL в параметре, а вы забудете это проверить перед вызовом какого - нибудь link_path_walk :-)

Зачем параллельную ветку. Берем патч экспортирущий системные вызовы и аккурантенько ими пользуемя. Для встраиваемых систем подойдет :), но вот для всего остального.... :(