Comments 4
Еще одной заковыркой в работе CDS является то, что разделяемые архивы проецируются на память с фиксированными адресами (обычно начиная с 0x800000000). Само по себе это не плохо, но поскольку в большинстве операционных систем по умолчанию включена рандомизация назначения адресов (Address Space Layout Randomization (ASLR)), требуемый диапазон памяти может оказаться частично занят
(Отвечая на выделенную часть) Ну как сказать — кому-то, наверное, не плохо. Думаю, разные писатели вирусов будут просто в восторге от возможности подменять классы в shared metaspace, особенно учитывая что адрес один и тот же. Или я что-то упускаю?
Возможно, какое-то упрощение это привнесет, да. Однако, во-первых, известность базового адреса не особо проливает свет на структуру и формат остальной разделяемой области, ведь спецификация на JSA-файлы остается закрытой, что делает подмену классов в них не такой уж тривиальной. Во-вторых, даже если структура файла будет выведена эмпирически (типа реверс-инижинирингом), сам доступ нему, тем более на запись, должен остаться серьезным препятствием, потому что этот файл наверняка хранится примерно также, как исполняемые файлы приложения (JAR-архивы, например).
Другими словами, защита разделяемого архива от зловредных модификаций, на мой взгляд, должна производиться средствами другого уровня, нежели манипуляцией адресами после считывания архива. Тем более, что релокация указателей может обходиться довольно дорого, см. замеры в JDK-8231610.
Я по этой ссылке вижу совсем другое:
- динамическая адресация архива стоит на 20% дороже по сравнению со статической адресацией, но также на ~35% дешевле чем если архива нет совсем
- кроме того, заявляется, что если из кода который читает архив убрать проверки доступности, то итоговая деградация производительности системы может быть ниже 20% за счёт меньшего числа ветвлений.
Ну а полагаться на то, что структура файла закрытая не приходится, я считаю. Код-то в OpenJDK, а значит открыт.
Согласен, всерьез полагаться на "закрытость" формата архива не стоит. Равно как и не стоит (по крайней мере, пока) ожидать от него встроенных средств защиты от модификаций. Поэтому, повторюсь, я считаю, что защищать архив нужно средствами другого уровня, и в фиксированной адресации внутри него действительно нет ничего плохого.
Что касается приведенной ссылки, то мы увидели одно и то же: "динамическая" адресация оставляет заметный негативный отпечаток на производительности CDS в целом, поэтому JVM будет избегать ее по возможности. Сравнение с вариантом без CDS здесь нерелевантно, так как этот вариант сейчас вне нашего фокуса.
Спасибо, что обратили внимание на вопрос безопасности; как обычно, он важен, но не очевиден.
Сборка чугунного скорохода на Spring Boot и AppCDS