Центр информации по операционным системам: Форумы / ОС-21 / Заглядывая в туманное будущее

Центр информации по операционным системам :: Форумы :: Концепции :: ОС-21		<< Предыдущая тема \| Следующая тема >>
Заглядывая в туманное будущее - обсуждение

Переход на страницу 1 2 3 ... 5 [6] 7 ... 13 14 15
Модераторы: Roman I Khimov, Wanderer, Dron

Автор

Добавил

captain cobalt

Пятница 09.09.2005 14:10

ID пользователя #12

Зарегистрирован: Воскресенье 04.07.2004 21:44
Местонахождение: /ru/perm
Сообщений: 144

Dron написал(а) ...
Вот об этом я и говорю... было бы конечно замечательно если бы были только файлы... но у нас есть блочное устройство... так что файловый уровень может быть обойден. естественно это ни к чему, кроме как к нарушению файловой структуры не приведет.

Тем не менее, такой подход успешно повсеместно используется.
И даже имеются механизмы разграничения прав доступа, причём сами права хранятся на том же самом диске.

Разумеется, имея доступ на блочном уровне, можно наплевать на все эти права и делать что угодно.

Причина же успешного применения файловых систем конечно же в том, что в штатной конфигурации запрещён прямой доступ к блокам.

Этот принцип можно обобщить: для корректного функционирования абстракций следует предоставлять интерфейс в более высокому уровню и ограничивать доступ к более низкому уровню.

Dron написал(а) ...
То же самое и с памятью.. типы - это хорошо, но когда можно работать и без типов - вся надежность типовая сводится к нулю.

Аналогичный принцип используется и здесь. В штатной конфигурации нельзя работать без типов. И без аппаратной защиты памяти всё работает так же надёжно, как работают права доступа к файлам в обычных ОС.

Dron написал(а) ...
архитектуру железа надо менять.

Нет, это фантастика.

Существующее железо вполне пригодно для построения корректных программных систем.

Тогда зачем платить больше (за "новое железо")?

Архитектуру железа менять можно, но постепенно, должна быть возможность обеспечения совместимости с софтом (не обязательно на бинарном уровне), и менять её надо в противоположном направлении - упрощать (выкинуть например аппаратную защиту

) и ускорять.

Dron написал(а) ...
Объекты - это лишь видимость.

Это философский вопрос.
Как это доказать?
Что - "не видимость"?

Dron написал(а) ...
тот же блюботл... там что, совсем нету защиты памяти?

В "обычном понимании" - совсем нету.

Одна куча и один сборщик мусора на всю систему. Все указатели глобальны. Любая процедура может передать имеющийся у неё указатель любой другой процедуре и та сможет им воспользоватся (но только в соответствии с типом). А если не захочет передавать

- то не сможет.

Dron написал(а) ...
ну сторожевая страница - это фигня.

Сторожевые страницы используются для ловли нулевых указателей и для расширения стеков. Основная часть памяти - куча отображается так, чтобы логический адрес был равен физическому. Это позволяет совершенно независимо разрабатывать распределитель памяти и драйвера для фреймбуфера/DMA.

Dron написал(а) ...
Нити то там есть или как? или хотя бы процессы?

Есть активные объекты.
Потому система так и называется.

Активный объект - это объект, обладающий собственным потоком управления. Эти потоки управления исполняются независимо и параллельно. На уровне языка Active Oberon код для этого потока называется тело (body). Фактически это безымянный метод, который начинает выполняться после создания (NEW) и инициализации объекта.

Активные объекты - это объекты.

Нет необходимости в IPC, активные объекты взаимодействуют с помощью проблемно-ориентированного интерфейса - вызывают методы друг друга. Важно, что семантика этих вызовов (количество и типы параметров) проверяется во время компиляции (и динамической компоновки) - нет необходимости интерпретации во время исполнения (к чему призывают пропагандисты текстовых форматов).

Для синхронизации используется два примитива - EXCLUSIVE и AWAIT. О них говорилось тут неподалёку.

Внутри рантайма процессы есть, но голые процессы нельзя трогать "грязными руками" (как нельзя трогать голую память). Можно только создавать активные объекты - "объекты с процессом внутри".

Dron написал(а) ...
Собственно к чему я клоню.
Вот есть аппаратные возможности защиты памяти. которые нельзя обойти. физически... - вот это надежно..

Другими словами, "нельзя доверять софту", так?

Попробуем обойти аппаратную защиту. В соответствии с вышеописанным правилом для этого потребуется спуститься на уровень ниже. Вот несколько способов:

-- подделать образ ядра на загрузочном устройстве; тогда после перезагрузки власть будет в наших руках.

-- прошить микрокод; в процессорах Pentium4 можно программно перезаписать микрокод; это изменит смысл машинных инструкций; ядро, использующее эти инструкции перестанет корректно работать.

-- использовать DMA; обращения контроллера DMA к памяти не контролируются процессором.

-- ну и конечно же физический способ: берём батарейку, провода и начинаем тыкаться в контакты процессора, берём ножичек и начинаем резать дорожки на материнской плате.

Всё это во время работы ОС.

-- кстати, действительно довольно известно простое механическое устройство, с помощью которого выдвигание CD-ROM нажимает на кнопку Reset; такое устройство действительно с пользой используется на BBS, когда модем зависает и больше ничто не помогает.

Dron написал(а) ...
А всякие идеальные программные архитектуры без надежной аппаратной поддержки - ерунда!

Избыточная аппаратная поддержка приводит к излишним расходам ресурсов и препятствует повышению производительности.

Такие вещи как защита памяти, типизация или instruction scheduling гораздо более эфективны в программной реализации.

bluebottle.ethz.ch - Bluebottle. Швейцария. Сделано с умом.

Наверх

Dron

Пятница 09.09.2005 14:20

ID пользователя #13

Зарегистрирован: Понедельник 05.07.2004 11:16
Местонахождение: Москва
Сообщений: 651

Но насколько я знаю, в обероне можно использовать inline asm (это так?)... так о какой защите среды можно говорить?

Все работает правильно пока все пишут правильные программы - этот тезис в настоящее время не катит в принципе.

Система должна обеспечивать защиту от любых злонамеренных программ/программистов.

Причем защищать надо не только себя (систему) но и другие программы тоже. Об одном адресном пространстве и речи быть не может!
[ Редактирование пятница 09.09.2005 15:22 ]

Одну из двух вечных российских проблем можно, в принципе, решить с помощью асфальтоукладчиков и катков. А вот с дорогами, конечно, будет труднее...

Андрей Валяев

Наверх

Freeman

Пятница 09.09.2005 15:38

ID пользователя #3

Зарегистрирован: Четверг 01.07.2004 14:57
Сообщений: 207

А знаешь, что-то в этом есть. Сейчас работа многих вирусов основана на достаточно простых схемах распределения памяти. Условно, можно ее назвать FAT. Вспомним, во времена FAT вирусов, работающих в обход нее, было до фигища, только ленивый не писал стиралки, форматировалки, шифровалки или просто портилки.

Сейчас есть куча методов для проникновения в ядро системы, той же NT, и следовательно, потенциальная возможность модификации драйвера NTFS или просто работы с диском на низком уровне. И что? Сколько тебе известно вирусов, работающих с диском на низком уровне? Я лично, что-то ни одного ни припоминаю.

В первую очередь это от того, что написать полноценную работу с NTFS - фактически создать собственный драйвер (пусть даже и с ограничениями). А вирусописатели физически не способны создать что-то большое и серьезное. Вот и ограничиваются скриптовыми пакостями или присасыванием к IE.

Можно сделать грубый вывод, что если в некоей ОС распределение памяти будет достаточно запутанным и нетрадиционным, не будет никакого смысла использовать набившее оскомину переполнение буфера, т. к. для этого надо будет написать собственное ядро ОС.

Кстати, вы должны признать, что на сегодняшний день аппаратная защита проиграла борьбу с вирусами без боя. Знаменитое переполнение буфера основано на отсутствии какой-либо аппаратной защиты в самом нужном месте системы. Поэтому и столько вирусов. А топовые на сегодняшний день модели процессоров будут стоять на каждой машине еще очень не скоро. Вот и выходит, что программная защита описанным выше способом - не такое уж и кощунство, как кажется на первый взгляд.
<span class='smallblacktext'>[ Редактирование пятница 09.09.2005 15:42 ]</span>

Наверх

Dron

Пятница 09.09.2005 15:57

ID пользователя #13

Зарегистрирован: Понедельник 05.07.2004 11:16
Местонахождение: Москва
Сообщений: 651

Хм... так проблема то именно в том, что данные можно исполнять как код... с этим борятся... некоторые этого даже хотят... но это небезопасно. потому и появился бит NX.

Кстати у меня программы в стеке выполнять нельзя...
Правда в сегменте данных можно...

Здесь кстати как нельзя лучше рулит сегментная модель... но сложностей с ней много...
А программисты не любят сложности... программисты - ленивые.

Зачем писать вирус, которые лезет через обходные пути в NTFS, когда скрипт через дыру в IE может с таким же успехом попортить системные файлы.

Проблема не в том, что аппаратная защита недостаточна... проблема в том, что защитой пренебрегают.

Я много об этом думаю... часто защита мешает удобству. Ну всегда приходится чем-то жертвовать. либо защита в ущерб удобству, либо наоборот.

В линуксе тоже возможны вирусы... но проблема в том, что даже если дыры и присутствуют, их закроют ну за неделю. и какое удовлетворение? никакого... в то время как на винде вирусы могут плодиться и размножаться месяцами... рай

В принципе и замок на двери - надежно предохраняет от воров, если не забывать его закрывать... но опять таки - страдает удобство... вместо того, чтобы просто войти в дом - нужно сперва открывать дверь...

И еще... особенно капитану... нету ничего хуже - чем ложная уверенность в своей безопасности...

оберон кажется надежным пока никто его не пытался ломать...

ну кому нужна экспериментальная система, которой никто не пользуется?

Андрей Валяев

Наверх

Freeman

Пятница 09.09.2005 16:25

ID пользователя #3

Зарегистрирован: Четверг 01.07.2004 14:57
Сообщений: 207

Dron написал(а) ...
В принципе и замок на двери - надежно предохраняет от воров, если не забывать его закрывать... но опять таки - страдает удобство... вместо того, чтобы просто войти в дом - нужно сперва открывать дверь...

Какие только метафоры не найдут программисты, не верящие в постановку задачи.

Наверх

Dron

Пятница 09.09.2005 16:35

ID пользователя #13

Зарегистрирован: Понедельник 05.07.2004 11:16
Местонахождение: Москва
Сообщений: 651

Какие только метафоры не найдут программисты, не верящие в постановку задачи.

Знал бы ты куда может завести паранойя...

А я вообще безопасник... мне по штату положено.

Как сказал мой директор...

Паранойя - _профессиональное_ заболевание специалистов по безопасности, но,
любители могут в этой области зайти гораздо дальше.
(В. Гайкович)

Андрей Валяев

Наверх

captain cobalt

Пятница 09.09.2005 18:49

ID пользователя #12

Зарегистрирован: Воскресенье 04.07.2004 21:44
Местонахождение: /ru/perm
Сообщений: 144

Dron написал(а) ...
Но насколько я знаю, в обероне можно использовать inline asm (это так?)... так о какой защите среды можно говорить?

Да, в языке Оберон есть низкоуровневые возможности.

Но они строго контролируются.

А именно: если модуль импортирует модуль SYSTEM, то в нём можно использовать ассемблерные вставки, прямое обращение к портам и памяти, приведение типов. Такой модуль может разрушить всю систему.

В этом смысле его можно сравнить с "модулями ядра" других ОС. Очевидно, системные модули следует загружать только от доверяемых поставщиков.

Системные модули используются для среды исполнения, драйверов, и т. п. Низкоуровневые детали инкапсулируются внутри модуля и наружу выставляется сильно типизированный безопасный интерфейс.

Если SYSTEM не импортируется, то модуль может содержать только безопасный код.

Таким образом, имеется очень простой способ проверки безопасности кода. Если SYSTEM не импортируется, то модуль заведомо не может "испортить память". Такой способ различия - это механизм, который может использоваться для реализации той или иной политики. Например, "нельзя загружать системные модули, не входящие в комплект поставки ОС". Или "можно загружать только системные модули имеющие цифровую подпись поставщика".

А вот для программ на языках типа ассемблера, си или си++ ни беглым, ни пристальным взглядом, и даже не существует программы автоматического анализа, чтобы ответить хотя бы на один из вопросов:
-- может ли этот код "испортить память"?
-- нет ли здесь переполнений стека?
-- нет ли здесь утечек памяти?
-- нет ли здесь висящих указателей?

Feel the difference!

Dron написал(а) ...
Все работает правильно пока все пишут правильные программы - этот тезис в настоящее время не катит в принципе.

Аналогичное верно для компиляторов, ядер ОС и даже аппаратуры. Ну и что?

Предлагаю такой тезис: модуль на Обероне, не импортирующий SYSTEM, не может "испортить память".

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

Dron написал(а) ...
Система должна обеспечивать защиту от любых злонамеренных программ/программистов.

Неконструктивно.

Моё мнение: система должна быть гибкой, предоставлять небольшое количество ясных механизмов, с помощью которых может быть установлена подходящая политика для решения как можно более широкого круга прикладных задач с минимальными накладными расходами. Bluebottle годится.

Dron написал(а) ...
И еще... особенно капитану... нету ничего хуже - чем ложная уверенность в своей безопасности...

Во.
Кстати, книга Дейкстры "Дисциплина программирования" начинается именно с этого. Существуют только два способа быть уверенным в корректности аппаратно-программной системы:
-- доверять поставщику
-- математически доказать корректность

Большинство повсеместно используемых систем полностью относятся к первому пункту (оттого и в лицензиях "no warranty"). В Обероне эти две части чётко отделены одна от другой. Определённые свойства программной системы обеспечиваются (математическими) свойствами языка программирования (доказано проффессурой

bluebottle.ethz.ch - Bluebottle. Швейцария. Сделано с умом.

Наверх

batu

Суббота 10.09.2005 23:59

ID пользователя #5

Зарегистрирован: Суббота 03.07.2004 22:20
Местонахождение: Г Харьков
Сообщений: 22

Приятно что тема привлекла внимание. Хочу напомнить, что действительно типы по отношению к архитектуре процессора чужеродное и неизвестное понятие. Проверка типов выполняется теми же командами процессора. И мы надеемся, что это повышает надежность программного обеспечения. Другого смысла в изобретении типов просто не было. Пишешь программу. Транслируешь и транслятор нам находит ошибки. Однако с появлением и развитием объектно ориентированого языков появилась необходимость выполнять проверку типов на этапе выполнения. И не все ошибки с типами стало возможным проверять на этапе трансляции. Именно поэтому я и предложил опустить все проверки типов на этапе выполнения. И предложил алгоритм, который упрощает и транслятор и архитектуру машины. Второй, и более важный момент связан с ответом на

captain cobalt написал(а) ...
Кстати, книга Дейкстры "Дисциплина программирования" начинается именно с этого. Существуют только два способа быть уверенным в корректности аппаратно-программной системы:
-- доверять поставщику
-- математически доказать корректность

Большинство повсеместно используемых систем полностью относятся к первому пункту (оттого и в лицензиях "no warranty"). В Обероне эти две части чётко отделены одна от другой. Определённые свойства программной системы обеспечиваются (математическими) свойствами языка программирования (доказано проффессурой

Дело в том что математически правильный транслятор математически точно скажет что данная программа корректна (если синтаксис языка математически точный), Однако это мало что говорит про то что правильно написано ТЗ, и что ТЗ правильно понято програмистом, и програмист правильно реализовал это свое понимание на каком то из языков. Машина может проверить что i+=1 написано правильно, но не может проверить смысл вложеный програмистом в это сложение. Есть некоторые разработки по этим проблемам, но идеального решения нет. Если верить в то что программа правильная, то, естественно, никаких потеряных указателей и потеряных объектов быть не должно, но увы, пока эта вера весьма ненадежна, есть необходимость все это дело проверять. И иногда железо с этим справляется надежней.

Наверх

Vadim Ushakov

Воскресенье 11.09.2005 05:02

ID пользователя #409

Зарегистрирован: Четверг 18.08.2005 04:25
Местонахождение: Красноярск
Сообщений: 85

Из дискуссии можно сделать вывод, что масло маслянное. Это в лучшем случае. А в худшем, что масло - перепончатокрылое. О чем мы говорим вообще?

batu написал(а) ...
Однако с появлением и развитием объектно ориентированого языков появилась необходимость выполнять проверку типов на этапе выполнения.

Batu, вам известно, что, например, в Си++ проверить тип во время исполнения НЕВОЗМОЖНО? Более того, это сделано специально - чтобы программисты писали программы в ОО-стиле, а не абы как. Если у нас есть class Base; class A : public Base{}; class B : public Base{}; и мы выполняем оператор Base* obj = new A;, то потом НИКАКИМ СПОСОБОМ невозможно убедиться, что obj это A, а не B. Если программисту нужно реализовать код, который проверяет тип и потом делает нечто, то пусть он вставит это "нечто" в виртуальный метод и вызывает его; инкапсуляция - это один из краеугольных принципов ООП. А вызов метода не имеет накладных расходов для проверки типа, более того, при вызове метода таких проверок НЕ ПРОИЗВОДИТСЯ - только преход по v-таблице, и все. Накладные расходы минимальны. В других ОО ЯП имеются аналогичные механизмы.
Позволю себе такое утверждение: если вам в программе захотелось явно проверить тип, ваша программа - это не ОО-программа, в ней нет инкапсуляции.
Так зачем огород городить и создавать аппаратуру, которая никогда не понадобится?

batu написал(а) ...
Если верить в то что программа правильная, то, естественно, никаких потеряных указателей и потеряных объектов быть не должно.

Вот аналогичное утверждение для ассемблера: если программа правильна, то каждому push в начале процедуры соответствует pop в конце процедуры. А если эта программа будет переписана на Си, это утверждение теряет смысл - все эти push и pop контролируются компилятором. Точно так же и с "висящими" указателями и прочим. В современном ЯВУ:
1) невозможно испортить память с помощью атаки переполнения буфера;
2) невозможно получить указатель, указывающий на мусор;
3) не бывает потерянных объектов - их "доедает" сборщик мусора, как только они перестают использоваться.
Никто вам не гарантирует, что программа соответствует ТЗ. Но Oberon, Java, .Net и многие другие СОВРЕМЕННЫЕ языки и среды гарантируют три вышеперечисленных свойства. Программа "правильна" в том смысле, что она не сможет напакостить (специально или по ошибке) где-то в памяти и вызвать сбой системы. И никаких аппаратных проверок не нужно.

batu написал(а) ...
Дело в том что математически правильный транслятор математически точно скажет что данная программа корректна (если синтаксис языка математически точный), Однако это мало что говорит про то что правильно написано ТЗ и что ТЗ правильно понято програмистом, и програмист правильно реализовал это свое понимание на каком то из языков...
...
И иногда железо с этим справляется надежней.

Железо докажет, что программа соответствует ТЗ?

Интересно...

Программисты на Си++, вам разве никогда не хотелось, чтобы оператор delete вызывался не вами, а потусторонними силами - именно тогда, когда он действительно должен быть вызван, а не тогда, когда адрес удаляемого объекта хранится в десятке переменных? Когда в ВУЗе рассказывают о механизмах отладки, призванных искать утечки памяти и кривые указатели, мне становится грустно. Почему я должен выполнять работу, с которой легко и непринужденно справляется компьютер? Когда же мы перестанем программировать в каменном веке?

Предлагаю прекратить этот бессмысленный спор - каждый, как мы видим, остался при своем мнении.

Падает тот, кто бежит; тот, кто лежит – уже не падает.

Наверх

may

Понедельник 12.09.2005 13:40

ID пользователя #420

Зарегистрирован: Понедельник 05.09.2005 08:03
Местонахождение: г.Чита
Сообщений: 6

Здравствуйте!

Насколько я понял речь в данной теме идет о некоторой "идеальной" ОС 21 века, по крайней мере такой, какой мы ее видим.
По поводу работы этой ОС с памятью высказываются 2 точки зрения:
1) аппаратная защита себя изжила в связи с чем предлагается переходить на чисто
программную, за счет связки "язык программирования - среда исполнения".
2) аппаратная защита в существующем виде неудовлетворяет современным
требованиям и требуется ее реконструкция.

По этому поводу хотелось высказать несколько замечаний.

captain cobalt написал(а) ...

А именно: если модуль импортирует модуль SYSTEM, то в нём можно использовать
ассемблерные вставки, прямое обращение к портам и памяти, приведение типов.
Такой модуль может разрушить всю систему.

В этом смысле его можно сравнить с
"модулями ядра" других ОС. Очевидно, системные модули следует загружать только
от доверяемых поставщиков.

Системные модули используются для среды исполнения, драйверов, и т. п.
Низкоуровневые детали инкапсулируются внутри модуля и наружу выставляется сильно
типизированный безопасный интерфейс.

Если SYSTEM не импортируется, то модуль может содержать только безопасный код.

Таким образом, имеется очень простой способ проверки безопасности кода.
Если SYSTEM не импортируется, то модуль заведомо не может
"испортить память". Такой способ различия - это механизм,
который может использоваться для реализации той или иной политики.
Например, "нельзя загружать системные модули, не входящие в комплект поставки
ОС". Или "можно загружать только системные модули имеющие цифровую подпись
поставщика".

Небольшая игра ума: допустим (либо недопустим как кому больше нравиться

), что наша ОС - Bluebottle
Вроде все хорошо но возникают оргвопросы.
Кто разрабатывает модули для нашей ОС (отдельные индивидумы, их творческие коллективы, корпорации)?
Кто будет выдавать цифровые подписи на эти модули, кому и на каком основании?
Сколько это будет стоить?
Производятся ли при этом какие-либо проверки сертифицируемого кода?
Несет ли сертифицирующая контора какую либо ответственность за сертифицированный ею код?

Допустим я установил модуль "имеющий цифровую подпись" от
"от доверяемого поставщика" и в нем SYSTEM не импортируется. В этом самом
модуле есть ошибка которая не была обнаружена при тестировании, и ошибка эта проявляется не всегда, а при
определенном состоянии системы. Ошибка приводит к тому, что по случайному адресу
записывается несколько байт. Судя по постингам Капитана модуль этот может пакостить по всей системе.
Грустно....
Кстати в каком кольце защиты код исполняется?
Может все-таки стоит хотя бы поместить данные разных приложений (объектов)
в разные адресные пространства и ввести аппаратный контроль?

captain cobalt написал(а) ...

А вот для программ на языках типа ассемблера, си или си++ ни беглым,
ни пристальным взглядом, и даже не существует программы автоматического анализа,
чтобы ответить хотя бы на один из вопросов:
-- может ли этот код "испортить память"?
-- нет ли здесь переполнений стека?
-- нет ли здесь утечек памяти?
-- нет ли здесь висящих указателей?

Feel the difference!

Получается, что на сегодняшний день нет в принципе способа написать и
проанализировать на ассемблере, с или с++ программу корректно работающую с
памятью. На мой взглдя это все-таки небольшое преувеличение

.
Речь может идти о корректном проектировании и программировании,
но об этом речь идет в любой системе.

captain cobalt написал(а) ...

Dron написал(а) ...
Система должна обеспечивать защиту от любых злонамеренных программ/программистов.

Неконструктивно.
Моё мнение: система должна быть гибкой, предоставлять небольшое количество ясных механизмов, с помощью которых может быть установлена подходящая политика для решения как можно более широкого круга прикладных задач с минимальными накладными расходами. Bluebottle годится.

Dron написал(а) ...
И еще... особенно капитану... нету ничего хуже - чем ложная уверенность в своей безопасности...

Все очень красиво, но все-таки - нужна системе защита от "злонамеренных программ/программистов"?
Если "да", то в каком виде она должна быть реализована?

Программы, даже написанные Обероне, исполняются на реальных процессорах в реальном программном окружении.
Я не верю, что на Обероне нельзя создать модуль который специально либо случайно будет наносить
вред системе в которой он исполняется. Или не этой системе а соседней в сети.
По-моему защита нужна. А аппаратная защита памяти на мой взгляд является более привлекательной хотя бы с той точки зрения, что логику
"зашитую" в кремнии гораздо сложнее ломать.

Если тезисно представить идеальную систему, как это может выглядеть?

1.Просто "кода" и просто "данных" в системе не существует.
2.В системе есть объекты, которые относятся к определенным классам.
3.Доступ к объекту можно получить только через интерфейс класса,
экземпляром которого данный объект является.
4.Система АППАРАТНО контролирует соответствие кода который исполняется и данных
с которыми этот код работает.

Про способы реализации можно пофантазировать совместно

.

C edf;tybt

Наверх

Переход на страницу 1 2 3 ... 5 [6] 7 ... 13 14 15
Перейти: Наверх