LINUX.ORG.RU

Си. Почему бы не запретить запись в стек?

 


1

4

Решил немного разобраться как работают уязвимости. Как я понял, весомая их часть модифицирует стек.

#include <stdio.h>

register long unsigned rsp asm("rsp");

void print_arg(int arg) {
    ((int*)rsp)[3] = 0xBADC0DE;
    printf("arg = %x\n", arg);
}

int main(int argc, char **argv) {
    print_arg(0xF00D);
    return 0;
}

Этот код отрабатывает и не выводит ошибкок с

-fhardened -fcf-protection=full

На мой взгляд выглядит небезопасно.

Почему бы не вставлять проверки на ассемблере при записи в память, на включаемость в регион стека? Если нужно записать что то в аргумент на стеке (int), то проверку можно не вставлять. При записи по указателю, уже обязательно вставлять. Если адрес стека то ошибка. В memset проверять пересечение двух диапазонов.

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

void read_file(const char *name)
{
        char buff[999];
        FILE *f = fopen(name, "rb");
        read_block(f, buff);
}

void read_block(FILE *f, char *buff)
{
        // тут компилятор должен вывести что len(buff) == 999
        fread(buff, 1, 9999, f);
}

Что бы все идеально работало, нужно будет:

  • Пометить libc функции
  • Если функция работает со стеком как у меня в верхнем примере, но это правильное поведение, пометить и ее
  • Перекомпилировать основные библиотеки, что бы не ломать ABI можно ввести экспорт двух прототипов, с доп.значениями для проверки диапазонов и без, дублирование прототипов понадобится для малого числа функций
★★★★

Последнее исправление: MOPKOBKA (всего исправлений: 2)

Ответ на: комментарий от MOPKOBKA

Насколько я понимаю правильная терминология: PT_LOAD из program header – это сегмент, а запись из section table – это секция. Секции используются только на этапе статической линковки. Во время загрузки и работы программы они не используются. Загрузкик ELF вызывает mmap() для каждой записи PT_LOAD.

X512 ★★★★★
()
Ответ на: комментарий от Forum0888

можно ли FPGA задействовать

зачем,если в проце и так всё уже есть?

Для дискуссии.

Ну например такой вариант: Делаем на FPGA кэш-контроллер. В качестве кэш-памяти используем обычную динамическую память, гигов так несколько,примерно как ОЗУ сейчас. А в качестве основной памяти - энергонезависимую флэш-память размером в сотни гигов,как SSD диски. Но флэш-память нужна с произвольным доступом,а не spi или еще что-нибудь последовательное.

При «инсталляции» программы она записывается в флэш с привязкой к адресам. А потом используется execute in place - как это сделано в некоторых встроенных системах.

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

Да и как таковые диски всё чаще и так флэш-памятью заменяются. А быстрая динамическая память в качестве кэша нужна чтобы код быстро исполнялся и флэш медленнее «протирался». Да и доступ на запись у флэша только блоками.

Сразу скажу - идея не лично моя, она возникла лет двадцать назад в переписке в какой-то из телеконференций. Но в те времена была абсолютно не реализуема для физлиц,тем более российских. А сейчас вобщем-то можно замахнуться. Хотябы с применением какого-нибудь «устаревшего» процессора попроще,под который сможет сделать системную плату одна из китайских фабрик,с физлицами работающая. И даже пример реализации контроллера кэша на ПЛИС доступен - например вот: https://github.com/omega-rg/Cache-Controller

Придумывали же раньше люди архитектуру компов чуть ли не в гаражах - а почему сейчас нельзя с этим экспериментировать. Сам я к сожалению никогда не работал с ПЛИС так что такое на VHDL не запрограммирую. В основном потому что не представляю как это отлаживать.

watchcat382
()
Последнее исправление: watchcat382 (всего исправлений: 1)
Ответ на: комментарий от watchcat382

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

а при модификации кода (какой-нить библиотеки или программы) придется «перепривязывать» всю вашу многогигабайтную память.

не трогайте вы загрузчики, они вас не трогают и вы их не трогайте

alysnix ★★★
()
Ответ на: комментарий от watchcat382

Экспромтом.

Добавляем в CPU два регистра, содержащие диапазон области памяти и
флаг на требование проверки операции доступа к ней.
При этом CPU для любой команды модифицирующей область должно
проверить не производится ли модификация памяти вне области.

Данные о сегментах есть.
Для реализации возможности проверки нужно добавить эту функциональность в кодогенератор компиляторов.
То бишь защита будет реализована лишь для того кода в котором компилятор умеет добавить, код для проверки в процессе кодогенерации.

Кстати эту идейку можно проверить чисто программно.

Можно просто разработать API для проверки доступа к области памяти.

Forum0888
()
Последнее исправление: Forum0888 (всего исправлений: 4)
Ответ на: комментарий от alysnix

а при модификации кода (какой-нить библиотеки или программы) придется >«перепривязывать» всю вашу многогигабайтную память.

Модификация кода - явление не слишком частое. Загляните у себя на машине в /usr/lib и /usr/bin и посмотрите на даты модификации файлов. К тому же хранение можно организовать так,чтобы перепривязывать не «всю память»,а только тот файл что модифицировали.

не трогайте вы загрузчики, они вас не трогают и вы их не трогайте

Удивляюсь людям,которые готовы задавить любые обсуждения чего-то нетипичного. Тем более что основное достоинство предложенной организации памяти не в экономии работы загрузчика,а в отсутствии необходимости пересылки мегабайтов кода через последовательный интерфейс sata. Да и даже через параллельный интерфейс флэш-памяти пересылать в быструю динамическую память надо будет только то что реально исполняется. Не странно ли сохранять само понятие «диска» в компе в то время как никаких дисков в нем нет,а есть только разные типы памяти с разной скоростью доступа.

watchcat382
()
Ответ на: комментарий от watchcat382

Модификация кода - явление не слишком частое.

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

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

alysnix ★★★
()
Ответ на: комментарий от Forum0888

Добавляем в CPU два регистра, содержащие диапазон области памяти и флаг на требование проверки операции доступа к ней.

К сожалению, добавить что-то в CPU практически не реально. Я конечно знаю что существуют реализации CPU на ПЛИС но там CPU получаются только медленные и простые,что-то типа микроконтроллера. Потому и размышлял только о возможности сделать комп из существующих доступных микросхем но не похожий на массово существующие. И когда тут у нас разговор дошел до подключения ПЛИС между процом и памятью - как раз и вспомнилась та давняя дискуссия об избавлении от понятия «дисков» в компе где этих дисков физически нет. Когда-то эмулировали считыватель перфолент и магнитофон,потом от них избавились совсем,в том числе и в виде эмуляции. А в всяких встроенных системах от «дисков» отказались уже сейчас - execute in place не я же выдумал и тем более не сегодня. И в настольных компах уже давно есть несколько мегов перезаписываемой флэш-памяти в которой хранится bios. Так почему бы не продолжить идею и не поместить в флэш-память вообще всё? И не в виде аппаратной эмуляции диска,а с естественным для памяти параллельным доступом прямо из основного адресного пространства процессора,без необходимости пересчета в цилиндры,головки и секторы(которые и так уже давно не имеют ничего общего даже с организацией хранения данных на физических дисках).

watchcat382
()
Ответ на: комментарий от watchcat382

Sorry за повтор суждения.

Защита в основном нужна от некачественного кода.
Этого можно избежать, разработкой ЯП высокого уровня, которые
устранят возникновение такого рода проблем.

Forum0888
()
Ответ на: комментарий от watchcat382

К сожалению, добавить что-то в CPU практически не реально.

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

Вполне реальная задача.

Кстати вот 1С интересна тем, что она не даёт программисту быть
шибко умным и устраняет 99% ошибок, которые можно наваять в Си или C++.

Forum0888
()
Последнее исправление: Forum0888 (всего исправлений: 3)
Ответ на: комментарий от alysnix

как вы предлагаете запускать программу хоть, в случае ее инспекции и >отладки?

Так ведь флэш-память - перезаписываемая. Как сейчас вы перезаписываете программу при необходимости в флэш памяти в аппаратном эмуляторе диска - также можете перезаписывать её без этого эмулятора. Надо лишь сделать удобный формат хранения, что не сложнее нынешних файловых систем,используемых с дисками. Представьте идею подключения флэш-памяти в адресное пространство процессора как развитие идеи ram-диска,но не уничтожаемого при перезагрузке. Кстати, я читал что в истории существовали платы,втыкаемые в слот ISA и изображающие из себя ram-диск,но имеющие батарейку для сохранения данных при перезагрузке. Доступ к памяти на такой плате кстати был именно параллельным(в виде окна в адресном пространстве),а вовсе не в виде эмуляции ввода-вывода в порт IDE(или MFM) контроллера. А сейчас мы снова ставим в компы энергонезависимую память,но продолжаем обращаться к ней через дисковый контроллер. Более того, SSD-диски уже сейчас содержат некоторое количество быстрого ОЗУ,используемого именно как кэш для более медленной флэш-памяти. Так что лишняя деталь тут - именно контроллер,обеспечивающий традиционный дисковый механизм доступа.

основная часть хранимого на всяких там дисках - не программы, а данные. и >в основном гоняют их с диска и на диск,

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

watchcat382
()
Последнее исправление: watchcat382 (всего исправлений: 2)
Ответ на: комментарий от Forum0888

Защита в основном нужна от некачественного кода.

Согласен.

Этого можно избежать, разработкой ЯП высокого уровня, которые устранят возникновение такого рода проблем.

Всё что можно выжать из чисто программных методов - уже реализовано в компиляторе языка Ada и его runtime библиотеке. Так что можно просто брать готовое давно отлаженное и пользоваться. А вот часть защит перепоручить железу - это вполне актуальная задача. Особенно учитывая что в интеловских процессорах всё необходимое для этого есть уже тридцать лет как. Просто в линуксе не используется надлежащим образом.

watchcat382
()
Ответ на: комментарий от watchcat382

Не, речь не об системах ИИ, а типа ТЗ (техническое задание).
Мы формируем ЯП лишь задачу, а он пусть думает как её решить.
Такого рода ЯП вполне реально разработать.

Когда говорю о своих разработках, то многие воспринимаю это как хвастовство.
На самом деле посты о том, что не «диванный теоретик».

Опубликую, но рановато СТО ПУДОВ.

Forum0888
()
Последнее исправление: Forum0888 (всего исправлений: 2)
Ответ на: комментарий от Forum0888

Мы формируем ЯП лишь задачу, а он пусть думает как её решить.

А в каком виде мы будем описывать эту задачу? По всей видимости писать придется в виде выражений,соответствующих некоей формальной грамматике. Иначе как наши хотелки до компа донести? То есть фактически это будет тоже какой-то [мета]язык программирования. Попытки уже были - Prolog например. Но что-то я не встречал чего-нибудь работоспособного,созданного с использованием Пролога.

Когда говорю о своих разработках, то многие воспринимаю это как >хвастовство.

Нифига подобного! Хвастовством это не выглядит. А выглядит как результаты деятельности человека, не ограниченного «общепринятыми» догмами и не считающего что если «ведущие производители» чего-то не сделали то это никому не надо и делать не следует. Не будь таких людей как вы и финский студент - мы бы по сей день вынуждены были сидеть в виндах. И не дай Бог пытаться что-то в них переделать - запрещено же:)

watchcat382
()
Ответ на: комментарий от watchcat382

Мы формируем ЯП лишь задачу, а он пусть думает как её решить.

Иначе как наши хотелки до компа донести?

С помощью волшебного API, очевидно же.

Когда говорю о своих разработках, то многие воспринимаю это как >хвастовство.

Нифига подобного! Хвастовством это не выглядит. А выглядит как результаты деятельности человека, не ограниченного «общепринятыми» догмами и не считающего что если «ведущие производители»

Эксперты, которых мы заслужили.

anonymous
()
Ответ на: комментарий от anonymous

Кстати вот 1С интересна

Прими таблетки.

1С,в том виде как она есть сейчас,а не два десятка лет назад, вполне неплохая вещь для своей весьма специфической предметной области. Если бы еще ее язык программирования был не на основе кусков русских слов,а на основе общепринятого в программировании английского - то она вызывала бы еще меньше отторжения при взгляде со стороны. А так-то - ну интерпретируемый ЯП с хорошо приспособленным для предметной области рантаймом - штука в мире вовсе не экзотическая. Например есть специальные языки для программирования PLC (контроллеров управления промышленным оборудованием). Кто работает в этой области - вполне ими пользуются,а вне ее о таких языках как LD или FBD мало кто слышал. На них конечные автоматы(finite state machine) очень удобно писать.

watchcat382
()
Ответ на: комментарий от watchcat382

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

if  Число( LinkНаселённыйПункт.Код ) = 252   Then
 ...
endif;

Нет смысла с анонимом вести диалог.
Он как уколется начинает всем клоунов раздавать.

Forum0888
()
Последнее исправление: Forum0888 (всего исправлений: 1)
Ответ на: комментарий от anonymous

не исключено что вы уже под веществами и на этой волне слетаетесь в этот >тред.

Не нравится - не читайте. Вас же не заставляют. Мы тут поговорить собрались о том что нам интересно,а Вы зачем?

watchcat382
()
Ответ на: комментарий от Forum0888

LinkНаселённыйПункт

Вот именно подобные штуки и вызывают отторжение при взгляде со стороны. Так-то чисто технически и в микрософтовском виндовом сишном компиляторе можно подобные названия переменных в исходник засунуть. Но никто кроме отдельных маргиналов это не делает. И еще меньше желающих потом этот код читать.

watchcat382
()
Ответ на: комментарий от watchcat382

Мы тут поговорить собрались о том что нам интересно,а Вы зачем?

Написать вам, что вы флудеры, нахваливающие друг друга на пустом месте. Не нравится - не читайте.

anonymous
()
Ответ на: комментарий от watchcat382

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

Более того 1С предоставляет возможность использовать английские
названия: объектов, функций, ..., которые имеются в технологической платформе,

Forum0888
()
Последнее исправление: Forum0888 (всего исправлений: 4)
Ответ на: комментарий от watchcat382

Не странно ли сохранять само понятие «диска» в компе в то время как никаких дисков в нем нет,а есть только разные типы памяти с разной скоростью доступа.

Чтобы такое реализовать нужно уже отходить от классических OS, попытки такие уже есть например - Фантом ОС.

anonymous
()
Ответ на: комментарий от watchcat382

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

Тут мешает то, что должен обеспечиваться равномерный износ ячеек флеш памяти, так что или контролер аппаратный или сама OS должна обязательно это обеспечить, иначе моментально протрется. В общем тут все-равно нужен доступ отличный от доступа к обычному ОЗУ выкинуть можно будет только имитацию диска.

anonymous
()
Ответ на: комментарий от watchcat382

Ныне можно реализовать чисто программную защиту областей памяти.
Два пути:
- доработка компилятора;
или
- доработка линкера, который сможет «на лету» добавить код для проверки.

Проще всего - разработка API для управления памятью, которое в т.ч. будет уметь защитить области памяти.

Forum0888
()
Последнее исправление: Forum0888 (всего исправлений: 1)
Ответ на: комментарий от watchcat382

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

Сначала разработка core, содержащего API для работы с знаниями.
Ёмкая, но супер интересная и нужная задача.

Forum0888
()
Ответ на: комментарий от anonymous

Чтобы такое реализовать нужно уже отходить от классических OS, попытки >такие уже есть например - Фантом ОС.

Это хорошо что есть попытки. Вот только нужно сохранять совместимость с прикладным софтом, который всё-таки расчитывает на классический POSIX. Новая революционная ОС но без возможности собрать под нее общеупотребительный прикладной софт - так и останется в ряду всяких экзотических узкоспециальных разработок. Так что совсем уж революционных шагов лучше бы избегать и совершенствовать ОС поэтапно, сохраняя по возможности совместимость с линуксовым прикладным софтом,либо ограничиваясь требованиями минимальной его модификации при переносе,типа удаления всякого рода «хакерских трюков» из кода.

Кстати, имя автора Фантом ОС мне знакомо - он присутствовал в той очень давней дискуссии о совершенствовании операционных систем,которую я упоминал выше.

watchcat382
()
Ответ на: комментарий от anonymous

Тут мешает то, что должен обеспечиваться равномерный износ ячеек флеш >памяти,

С обеспечением равномерности износа ячеек вполне справляются маленькие и дешевые контроллеры,стоящие внутри «флэшек». Не вижу какой-либо особой сложности дописать нужную функциональность в VHDL-код вышеупомянутого «кэш-контроллера на ПЛИС». Пусть при мофикации содержимого блока(страницы) пишет его не на прежнее место,а на другое. Некоторой трансляцией адресов ему всё равно придется заниматься, ну будет побольше работы. Главное что доступ к памяти будет естественный для нее параллельный,а не через дисковый контроллер как сейчас.

watchcat382
()
Ответ на: комментарий от Forum0888

Ныне можно реализовать чисто программную защиту областей памяти.

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

доработка компилятора;

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

доработка линкера, который сможет «на лету» добавить код для проверки.

Лучше бы он не код добавлял,а использовал возможности железа. Работало же это в OS/2 и некоторых дос-экстендерах. При использовании дос-экстендеров именно что можно было из одних и тех же объектных файлов собрать или обычный исполныемый файл под DOS или файл для исполнения в защищенном режиме под дос-экстендером. Сборка отличалась только линкером.

watchcat382
()
Ответ на: комментарий от watchcat382

Лучше бы он не код добавлял,а использовал возможности железа.

ИМХО ещё не поздно этими вопросами заняться.

Ныне у меня более приоритетны другие задачи.
Чуть далее придётся всё же в линкер добавить поддержку
динамических объектов, использующих метаданные, но ныне это не приоритетно.

Что ныне разрабатываете?

Forum0888
()
Последнее исправление: Forum0888 (всего исправлений: 2)
Ответ на: комментарий от Forum0888

ИМХО ещё не поздно этими вопросами заняться.

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

Что ныне разрабатываете?

Старый я уже,уже полтора десятка лет в деревне живу, а в порядке хобби пытаюсь приделать автопилот к своей лодке:)

watchcat382
()
Ответ на: комментарий от watchcat382

Старый я уже,уже полтора десятка лет в деревне живу

Дружище, в твоих руках помолодеть на сорок лет.
Бывает, что семнадцатилетние - «глубокие старики».
Старит человека не возраст!

Forum0888
()
Последнее исправление: Forum0888 (всего исправлений: 1)
Ответ на: комментарий от watchcat382

Представьте идею подключения флэш-памяти в адресное пространство процессора как развитие идеи ram-диска,но не уничтожаемого при перезагрузке.

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

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

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

alysnix ★★★
()
Ответ на: комментарий от watchcat382

без необходимости пересчета в цилиндры,головки и секторы

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

arkhnchul ★★
()
Ответ на: комментарий от arkhnchul

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

Важно не то, в какие именно цифры приходится пересчитывать адреса,а то,что этот пересчет приходится делать вообще. Если в аппаратном эмуляторе диска стоит флэш-память с параллельным доступом,а перед ней еще и обычная память в качестве кэша - то и обращаться к ней надо как к памяти. «блочное устройство» тут становится лишним. Как и сам аппаратный эмулятор диска,подключаемый через дисковый контроллер.

watchcat382
()
Ответ на: комментарий от watchcat382
  1. рядом(или вместо) с твердотельным накопителем может стоять обычный. который является блочным по определению.

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

  3. ну и наконец - сам чип ssd - блочное устройство.

alysnix ★★★
()
Ответ на: комментарий от alysnix

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

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

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

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

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

А так-то да - причину что-нибудь НЕ делать найти можно всегда :) И самая стандартная - «никому это не надо». Но нередко бывало что если кто-то всё же делал - то выяснялось что оно вполне надо.

watchcat382
()
Ответ на: комментарий от watchcat382

Причина - как минимум упрощение электроники и соответствующее сокращение энергопотребления.

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

А так кэшом для флэш-памяти станет основное озу.

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

alysnix ★★★
()
Ответ на: комментарий от alysnix

получение блока данных с внешнего устройва и потом побайтовое чтение этих >данных пограммой существенно быстрее, чем побайтовое чтение с внешнего >устройства.

Так и предлагается именно что упразднить диск как внешнее устройство и заменить его флэш-памятью, подключенной в адресное пространство процессора. Как это в микроконтроллерах сделано. Вот я это пишу с компа, у которого рядом с вставленными в разъемы DIMM-модулями также вставлен «диск» ssd в типоразмере M2. Но к DIMM доступ у процессора прямой,а к тем микросхемам флэш-памяти что стоят на этом «диске» - через контроллер sata и второй контроллер на самом «диске». Какой смысл этой конструкции из двух контроллеров кроме «так исторически сложилось»? Вон,в микроконтроллерах «не сложилось» и ничего, работают. Почему также не может работать десктоп?

watchcat382
()
Последнее исправление: watchcat382 (всего исправлений: 1)
Ответ на: комментарий от watchcat382

Почему также не может работать десктоп?

Потому что внешние накопители медленные, на разных принципах работы. Вон в том-же SSD некоторые ячейки могут хранить 1 бит информации для быстрой записи а затем уже ужатие до 3 битов, как ты себе представляешь эту концепцию на адресное пространство накладывать? Если так HDD подключить то что будет при попытке чтения, программа будет висеть пока данные не скачаются из диска? Нахрена тогда оно такое нужно?

V1KT0P ★★
()
Ответ на: комментарий от watchcat382

Почему также не может работать десктоп?

потому что ваш dimm имеет существенно меньшее время доступа, чем все эти флеш чипы. время записи там вообще аховое.

в микроконтроллерах стоит прямоадресуемая nor флешпамять, а в ssd - nand. nand вообще блочная.

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

alysnix ★★★
()
Ответ на: комментарий от alysnix

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

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

у вас упадет общая производительность

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

развитие идет по пути усложнения электроники

Развитие идет по пути выбивания денег из покупателей. Если для этого требуется усложнение - будут усложнять. Если для повышения прибыли можно что-нибудь упростить - будут упрощать.

А уж нынешняя архитектура десктопных компов - это большое нагромождение костылей в угоду совместимости с не самыми удачными техническими решениям из IBM PC XT,который изначально не рассматривался фирмой IBM как «настоящий серьезный» компьютер.

В итоге используем ОС родом из начала 90х(которая кстати тоже не рассматривалась автором как нечто серьезное) на компе родом из начала 80х. И многие почему-то уверены что иные технические решения будут обязательно хуже.

В порядке любопытства,интересно, возможно ли технически изготовить на китайской фабрике работающей с заказами от физлиц (типа JLCPCB и подобных) системную плату собственного дизайна под 486 процессор (потому что чипсеты под него уже умели шину PCI)? Понятно что под современные процы с гигагерцовыми частотами - точно нет. А вот 486 или даже первый Пентиум - под вопросом. Тем более что для экспериментального образца можно с габаритами платы особо не ужиматься. Были же в 90х платы размером чуть ли не с лист формата А3 и ничего,работали. Попробовал немного погуглить - но что-то картинок самодельных системных плат не видно. Хотя у меня тут медленный интернет по радио - может быть просто не находятся.

watchcat382
()
Последнее исправление: watchcat382 (всего исправлений: 1)
Ответ на: комментарий от alysnix

если обращения к памяти от процессора будут задерживаться операциями с >неповоротливой (в сравнении в обычной ram) флеш памятью - все застрянет.

Естественно я это знаю. И поэтому не предлагается подключать флэш-память напрямую к процессору. При первом обращении в пределах страницы флэш-памяти надо копировать всю эту страницу в быструю память на основе dimm. По мере накопления необходимости - асинхронно переписывать страницы из dimm в флэш. Аналогично тому как и сейчас кэш работает между быстрой статической памятью существенно более медленными dimm. Почему и упоминал ссылку на готовую реализацию кэш-контроллера на ПЛИС.

nand вообще блочная.

Что весьма неплохо сочетается с страничной организацией памяти у x86.

watchcat382
()
Ответ на: комментарий от V1KT0P

Вон в том-же SSD некоторые ячейки могут хранить 1 бит информации для >быстрой записи а затем уже ужатие до 3 битов, как ты себе представляешь >эту концепцию на адресное пространство накладывать?

Никто и не говорит что подключать к процессору надо именно такую хитрую память. Флэш есть и с обычной прямой адресацией (на чтение). Вот пишется он блоками - так для этого перед ним нужно «обычное» ОЗУ с страничной организацией,как раз как у х86. При обращении в пределах страницы - она вся переписывается в ОЗУ. По мере накопления изменений - страницы пишутся обратно в флэш. Но всё это посредством естественной для памяти параллельной прямой адресации, а не через бутылочное горлышко sata интерфейса.

watchcat382
()
Ответ на: комментарий от MOPKOBKA

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

anonymous
()
Ответ на: комментарий от arkhnchul

емнип nvme умеет в такой режим с прямым маппингом

Судя по «научно-популярным» описаниям - там тоже обращение командами, как в sata. Разве что система команд упрощена (всего 13 команд) и увеличено число параллельно работающих их очередей. Там же пишут что и задержка всего примерно вдвое меньше чем у «обычного» ssd.

То есть вот просто так,командой mov с заданного адреса там тоже данные не достать.

Хотя я всё же добыл китайскую карточку,позволяющую воткнуть nvme накопитель формата M2 в слот PCIe. Хочу поэкспериментировать как только сам накопитель достану. Они хотя и внешне одинаковые М2 но одни умеют nvme,а другие только sata. У меня их два есть но оба без поддержки nvme к сожалению.

Ну и замечу,что шина,по которой проц общается с ОЗУ - работает быстрее чем шина PCIe. Поэтому даже если будет возможен маппинг в адресное пространство то через PCIe это медленнее.

watchcat382
()
Ответ на: комментарий от watchcat382

Судя по «научно-популярным» описаниям - там тоже обращение командами, как в sata

это описание похоже было про собственно режим эмуляции SATA.

Поэтому даже если будет возможен маппинг в адресное пространство то через PCIe это медленнее.

ну так там и не в шину затык, именно чтение с флеша - оно еще медленнее.

arkhnchul ★★
()