Здравствуйте, WolfHound, Вы писали:

S>>Под это определение попадают также и предлагаемые тобой фильтры — поскольку они применяются не на уровне пользователя, а на уровне, скажем, приложения.
WH>Мои фильтры гораздо точнее попадают под capability-based_security
Ничего подобного. Про CBS у тебя вообще ничего нет. На всякий случай напомню, что СBS подразумевает, что вместе с дескриптором ресурса всегда передаются разрешения на его использование. В этой концепции нет ничего про фильтры и про ассоциации фильтров с приложениями.

Здравствуйте, DOOM, Вы писали:
DOO>Угу. Только вот выше было обсуждение, что не все так просто — либо арифметику урезать, либо каждый раз перед обращением проверку делать, что не очень-то хорошо скажется на производительности.
Это были утверждения, высосанные из пальца. Никаких реальных тестов производительности сингулярити, подтверждающих ее проигрышь традиционным ОС, приведено не было. (в отличие от тестов, подтверждающих обратное).
WH>>Она везьде.
DOO>Да как это везде! Опять же выше уже говорили, что никто не собирается делать ОС, в которой все будет JIT'ится — будут уже готовые бинарники, т.е. всё — управляемость кончилась.
Почитай статьи. Всё предусмотрено. Бинарники получаются путем компиляции верифицируемого байткода.
DOO>Теперь вся надежда только на контроль целостности бинаря. В конце-концов, даже если JIT'ятся, то будет какой-то кэш для ускорения работы — тогда просто объект атаки (защиты) сужается до этого кэша.
DOO>Ну не верю я, что при таких условиях можно все сделать и нигде ничего не пропустить или ошибиться.
Есть очень небольшой фрагмент кода (несколько килобайт), который верифицируется вручную. Всё остальное (ядро, драйверы, и т.п.) проходит верификацию.
Это означает, что для того, чтобы осуществить атаку, тебе нужно иметь в системе код, который может попасть в нее только в результате другой успешной атаки. Потому что обычный верифицируемый код ничего подобного сделать не сможет. В частности, он не сможет поковыряться в кэше нативных имаджей — этот кэш вообще ненаблюдаем для прикладного кода.

Здравствуйте, Sinclair, Вы писали:

S>Ничего подобного. Про CBS у тебя вообще ничего нет. На всякий случай напомню, что СBS подразумевает, что вместе с дескриптором ресурса всегда передаются разрешения на его использование. В этой концепции нет ничего про фильтры и про ассоциации фильтров с приложениями.
Нет. CBS подразумевает, что для управления ресурсом используется capability, которая является привиллегированым ресурсом, непривиллегированый процесс не может сам создать capability.

В данном случае, у WolfHound'а такими capability просто будут объектные ссылки. А что там с ними дальше будет делаться и какие на них вешаются фильтры — вопрос десятый.

Здравствуйте, Cyberax, Вы писали:

C>Нет. CBS подразумевает, что для управления ресурсом используется capability, которая является привиллегированым ресурсом, непривиллегированый процесс не может сам создать capability.
Гм. Я вот читаю текст здесь, и первым делом там сказано:

Instead, in a system with capabilities, the mere fact that a user program possesses that capability entitles it to use the referenced object in accordance with the rights that are specified by that capability.

То есть capability уже включает в себя всю информацию не только об объекте, но и о действиях, которые с ним можно предпринять.
И вот уже далее:

Capabilities are typically stored by the operating system in a list, with some mechanism in place to prevent the program from directly modifying the contents of the capability (so as to forge access rights or change the object it points to).

Вот как раз этот механизм вполне описывается системой типов — у прикладного кода вообще нет никаких возможностей залезть "внутрь" capability, потому что он может только вызывать публичные методы.
А публичные методы у capability таковы, что ее содержимое в принципе immutable. Всё, что можно сделать — это получить копию capability с меньшими привилегиями.
C>В данном случае, у WolfHound'а такими capability просто будут объектные ссылки. А что там с ними дальше будет делаться и какие на них вешаются фильтры — вопрос десятый.
Как это десятый? Вот ты упомянул, что "непривилегированный процесс не может сам создать capability". А откуда берется информация о том, что процесс привилегированный?
WH утверждает, что будут какие-то фильтры. Про них в CBS ничего нету. Зато вот в CAS всё описано четко: есть описание политик, где прописано, какие требования предъявляются к коду, который пользуется "привилегированными" возможностями.

Здравствуйте, Sinclair, Вы писали:

S>Гм. Я вот читаю текст здесь, и первым делом там сказано:
S>

Instead, in a system with capabilities, the mere fact that a user program possesses that capability entitles it to use the referenced object in accordance with the rights that are specified by that capability.

S>То есть capability уже включает в себя всю информацию не только об объекте, но и о действиях, которые с ним можно предпринять.
Ну да. По сути, capability — это ссылка на объект. Как она там внутри себя реализует контроль отдельных действий — её личная проблема. Оно может использовать ACLи или тупо давать доступ только к определённым интерфейсам.

S>

Capabilities are typically stored by the operating system in a list, with some mechanism in place to prevent the program from directly modifying the contents of the capability (so as to forge access rights or change the object it points to).

S>Вот как раз этот механизм вполне описывается системой типов — у прикладного кода вообще нет никаких возможностей залезть "внутрь" capability, потому что он может только вызывать публичные методы.
Да, именно.

S>А публичные методы у capability таковы, что ее содержимое в принципе immutable. Всё, что можно сделать — это получить копию capability с меньшими привилегиями.
На самом деле, ещё обычно есть механизмы обмена capability. Т.е. процессы могут безопасно ими меняться, что тоже прекрасно ложится на систему типов.

C>>В данном случае, у WolfHound'а такими capability просто будут объектные ссылки. А что там с ними дальше будет делаться и какие на них вешаются фильтры — вопрос десятый.
S>Как это десятый? Вот ты упомянул, что "непривилегированный процесс не может сам создать capability". А откуда берется информация о том, что процесс привилегированный?
Очевидно, что привиллегированый процесс держит capability, позволяющую создавать другие capability Что тут непонятного?

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

S>WH утверждает, что будут какие-то фильтры. Про них в CBS ничего нету. Зато вот в CAS всё описано четко: есть описание политик, где прописано, какие требования предъявляются к коду, который пользуется "привилегированными" возможностями.
Фильтры — это вопрос отдельный.

Здравствуйте, Cyberax, Вы писали:
S>>То есть capability уже включает в себя всю информацию не только об объекте, но и о действиях, которые с ним можно предпринять.
C>Ну да. По сути, capability — это ссылка на объект. Как она там внутри себя реализует контроль отдельных действий — её личная проблема.
C>Оно может использовать ACLи или тупо давать доступ только к определённым интерфейсам.
Я так понял, что всё же нет. Фишка именно в том, что никаких ACL на стороне объекта не используется. ACL в природе существуют уже давно, но не отвечают потребностям безопасности.
Идея именно в том, что контроля как такового нет — раз у тебя есть capability, то ты имеешь право ее использовать.

S>>А публичные методы у capability таковы, что ее содержимое в принципе immutable. Всё, что можно сделать — это получить копию capability с меньшими привилегиями.
C>На самом деле, ещё обычно есть механизмы обмена capability.
На водку?
Ты наверное имел в виду, что capability могут маршалиться между процессами. С т.з. софтно-изолированной оси это частный случай более общего принципа универсальной маршализуемости, но с точки зрения безопасности ты совершенно прав: непередаваемые capability совершенно бесполезны.

C>Очевидно, что привиллегированый процесс держит capability, позволяющую создавать другие capability Что тут непонятного?
Непонятно, какова гранулярность этой capability. Вот простой пример: capability на доступ к файлу. Винда выделяет что-то вроде 12 привилегий для файлового объекта. Мне (непривилегированному) дают только готовый файловый хэндл, открытый, допустим, в режиме read-only. Его выдает кто-то, кто имеет на это право.
Ок, допустим у него был full access хэндл, он склонировал его с понижением привилегий до read-only. Это пока понятно. Непонятно, какие именно привилегии были у того, кто создал тот full access handle?
Даже это мне не вполне понятно как реализовать с помощью системы типов. Ну то есть если у нас набор допустимых операций над файлом однозначно определяется типом хэндла, то нужны 2^12 типов для хэндлов, с соответствующими правилами преобразования типов (так, чтобы нельзя было сконструировать высокопривилегированную ссылку из низкопривилегированной).


C>То есть, для того, чтобы открыть файл — ты должен иметь ссылку на драйвер устройства.
Ну нифига себе, это значит, что любой, получивший единственную ссылку на драйвер устройства, получает полный контроль над всеми файлами???
Какая-то фигня выходит, извините.
C>Чтобы получить создать ссылку на драйвер устройства — ты должен иметь ссылку на менеджер устройств. Чтобы иметь ссылку на менеджер устройств — ты должен иметь ссылку на внутреннюю реализацию ядра. А ей владеет, допустим, только начальный загрузчик.
И что, у нас единственный, кто имеет право открывать файлы — это начальный загрузчик? Какая-то фигня выходит, извините.

S>>WH утверждает, что будут какие-то фильтры. Про них в CBS ничего нету. Зато вот в CAS всё описано четко: есть описание политик, где прописано, какие требования предъявляются к коду, который пользуется "привилегированными" возможностями.
C>Фильтры — это вопрос отдельный.
Ок, вернемся к отдельным вопросам. Отдельный вопрос был про то, зачем нужен CAS. WH утверждает, что CAS — это членоудлинитель для тех, у кого нет какой-то развитой системы типов. При этом внятных пояснений про то, как добиться простых эффектов безопасности на основе только системы типов, не вводя аналога CAS, я пока не увидел.

Здравствуйте, Sinclair, Вы писали:

S>Ничего подобного. Про CBS у тебя вообще ничего нет. На всякий случай напомню, что СBS подразумевает, что вместе с дескриптором ресурса всегда передаются разрешения на его использование.
Ну да.
Дескриптор это ссылка.
В объекте на который она ссылается есть все разрешения.
Объект совершенно не прозрачен для клиентов.

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

S>В этой концепции нет ничего про фильтры и про ассоциации фильтров с приложениями.
Следи за руками:
Рутовый процесс владеет абсолютно превелигерованной ссылкой на глобальное пространство имен.
Далее он пинает по этой ссылке пространство имен чтобы оно создало еще одну ссылку по которой нельзя получить доступ к объектам HAL'а.
И передает ее процессу который занимается управлением процессами пользователей (UserManager).

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

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

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

Таким образом никакого анализа стека как в случае с File.Open делать не надо.
Если можно через полученную ссылку на пространство имен открыть файл с запрошенными привелегиями то его можно открыть. Если нельзя то нельзя.

Если получилось открыть то ты эту ссылку можешь передать кому угодно.

Как приложение может открыть любой файл:
Идем в пространство имен.
Получаем ссылку на сервис открытия файлов.
Передаем сервису capability на открытие диалога в одном из своих окон.
Сервис открывает диалог с контексте окна приложения.
Пользователь открывает файл используя пространство имен укоцанное с учетом прав пользователя.
Приложение от сервиса открытия файлов получает capability на работу с файлом.

Здравствуйте, Sinclair, Вы писали:

C>>Оно может использовать ACLи или тупо давать доступ только к определённым интерфейсам.
S>Я так понял, что всё же нет. Фишка именно в том, что никаких ACL на стороне объекта не используется. ACL в природе существуют уже давно, но не отвечают потребностям безопасности.
S>Идея именно в том, что контроля как такового нет — раз у тебя есть capability, то ты имеешь право ее использовать.
Да, именно. Но ACLи при этом параллельно никто не мешает использовать.

C>>На самом деле, ещё обычно есть механизмы обмена capability.
S>На водку?
Ага.

S>Ты наверное имел в виду, что capability могут маршалиться между процессами. С т.з. софтно-изолированной оси это частный случай более общего принципа универсальной маршализуемости, но с точки зрения безопасности ты совершенно прав: непередаваемые capability совершенно бесполезны.
Да, в capability-based системах должен быть безопасный способ передачи (копирования и swap'а) capability.

S>Ок, допустим у него был full access хэндл, он склонировал его с понижением привилегий до read-only. Это пока понятно. Непонятно, какие именно привилегии были у того, кто создал тот full access handle?
"Привиллегий" как таковых у него не было, а была capability, которая позволяет создавать файлы.

S>Даже это мне не вполне понятно как реализовать с помощью системы типов. Ну то есть если у нас набор допустимых операций над файлом однозначно определяется типом хэндла, то нужны 2^12 типов для хэндлов, с соответствующими правилами преобразования типов (так, чтобы нельзя было сконструировать высокопривилегированную ссылку из низкопривилегированной).
Зачем? Ты можешь банально в конструкторе указать canRead, canWrite... и проверять их в соответствующих методах. Это как раз пример, когда ACLи (в простой форме) используются для реализации capability.

C>>То есть, для того, чтобы открыть файл — ты должен иметь ссылку на драйвер устройства.
S>Ну нифига себе, это значит, что любой, получивший единственную ссылку на драйвер устройства, получает полный контроль над всеми файлами???
Да.

S>Какая-то фигня выходит, извините.
Почему? В ядре системы сейчас всё точно так же — если ты получил доступ до ядерного пространства, то можешь делать что угодно. В случае с capabilities мы это "что угодно" существенно уменьшаем. Т.е. сетевой драйвер хоть и может отослать все твои секретные данные в NSA, но вот до файловой системы доступа у него не будет.

C>>Чтобы получить создать ссылку на драйвер устройства — ты должен иметь ссылку на менеджер устройств. Чтобы иметь ссылку на менеджер устройств — ты должен иметь ссылку на внутреннюю реализацию ядра. А ей владеет, допустим, только начальный загрузчик.
S>И что, у нас единственный, кто имеет право открывать файлы — это начальный загрузчик? Какая-то фигня выходит, извините.
Нет, единственный, кто может открыть файлы, — это сервер файловой системы, которыей получает ссылку на файловый драйвер. На самом деле, тут разницы с существующими ОС тоже мало.

S>Ок, вернемся к отдельным вопросам. Отдельный вопрос был про то, зачем нужен CAS. WH утверждает, что CAS — это членоудлинитель для тех, у кого нет какой-то развитой системы типов. При этом внятных пояснений про то, как добиться простых эффектов безопасности на основе только системы типов, не вводя аналога CAS, я пока не увидел.
Мне так интуитивно кажется, что какая-то система типа CAS всё равно понадобится для практической реализации всего этого. Но в очень упрощённом виде, скорее всего.

Здравствуйте, WolfHound, Вы писали:

S>>В этой концепции нет ничего про фильтры и про ассоциации фильтров с приложениями.
WH>Следи за руками:
WH>Рутовый процесс владеет абсолютно превелигерованной ссылкой на глобальное пространство имен.
WH>Далее он пинает по этой ссылке пространство имен чтобы оно создало еще одну ссылку по которой нельзя получить доступ к объектам HAL'а.
WH>И передает ее процессу который занимается управлением процессами пользователей (UserManager).

WH>При логине пользователя UserManager пинает по своей ссылке с уже установленной фильтрацией чтобы она создала еще более урезанную ссылку по которой можно получить только то что причетается пользователю
Вот тут вот: откуда берется информация о том, что причитается пользователю?
WH>и передает эту ссылку процессу который отвечает за этого пользователя.

WH>При старте приложения процесс пользователя смотрет на прова приложения
Вот тут вот: куда именно смотрит процесс пользователя на права приложения?
WH> и просит пространство имен еще больше ужесточить фильтрацию и передает ссылку на еще более жестокий фильтр приложению.

Здравствуйте, Pzz, Вы писали:

Pzz>Здравствуйте, Cyberax, Вы писали:

Pzz>>>Но как, видя байткод, а не синтаксическое дерево, сделать data flow analysis или вынос инварианта из цикла, я ума не приложу.
C>>А какие проблемы? Строим дерево и делаем анализ. Байткод для этого вполне адекватен.

Pzz>Байткод это ассемблер некоторой абстрактной машины. К тому времени, когда программа стала байткодом, много существенной информации об исходном коде уже утеряно.

Как правило, утерянная информация — это имена локальных переменных. Иногда еще компилятор вставляет минимальные оптимизации(типа конкатенации строк через стингбуферы). Из по-дефолту скомпиленного кода восстанавливается 99% инфы, причем этот 1% — инфа, не нужная оптимизатору никаким боком. Говорю про java.

Пример:

Маленький класс на java, чита.щий инфу из ком порта(писал для чтения дебаг-инфы с некоего девайса):

import easysoft.device.io.FileSerialPort;
import easysoft.device.io.SerialPortParameter;
import java.io.FileOutputStream;
import java.io.InputStream;


public class ComReader {
    public static void main(String[] args) throws Throwable {
        FileOutputStream fileOut = new FileOutputStream("e:\\dbg");
        new SerialPortParameter() {
            protected void applyForWindows(String portName) {
                exec("portparams.exe " + portName + " speed=115200 databits=8 parity=0", true);
            }
        }.apply("com1");
        FileSerialPort port = new FileSerialPort("com1");
        InputStream in = port.getInputStream();
        int read;
        while(true) {
            if ((read = in.read()) == -1) {
                Thread.sleep(10);
                continue;            
            }
            fileOut.write(read);
            if (read == 10) {
                System.out.println();
                continue;
            }
            System.out.print((char)read);
        }
    }
}

Скомпилил дефолтным эклипсовым компайлером, получил ComReader.class и ComReader$1.class.

Потом:

E:\temp\_tmp\decompiled>jad.exe ComReader.class
Parsing ComReader.class...Parsing inner class ComReader$1.class... Generating ComReader.jad

Найдите 10 отличий:
[ComReader.jad]

// Decompiled by Jad v1.5.8g. Copyright 2001 Pavel Kouznetsov.
// Jad home page: http://www.kpdus.com/jad.html
// Decompiler options: packimports(3) 
// Source File Name:   ComReader.java

import easysoft.device.io.FileSerialPort;
import easysoft.device.io.SerialPortParameter;
import java.io.*;

public class ComReader
{

    public ComReader()
    {
    }

    public static void main(String args[])
        throws Throwable
    {
        FileOutputStream fileOut = new FileOutputStream("e:\\dbg");
        (new SerialPortParameter() {

            protected void applyForWindows(String portName)
            {
                exec((new StringBuilder("portparams.exe ")).append(portName).append(" speed=115200 databits=8 parity=0").toString(), true);
            }

        }
).apply("com1");
        FileSerialPort port = new FileSerialPort("com1");
        InputStream in = port.getInputStream();
        do
        {
            int read;
            while((read = in.read()) == -1) 
                Thread.sleep(10L);
            fileOut.write(read);
            if(read == 10)
                System.out.println();
            else
                System.out.print((char)read);
        } while(true);
    }
}

Здравствуйте, Pzz, Вы писали:


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

Да никто и не позиционировал ту же джаву как идеальное средство обработки мультимедиа.
Больше всего java сейчас на серверах. Те самые энтерпрайз системы. Где масса работы со строками, но почти нет никаких хитрых вычислений. Множество объектов создается, чтобы жить пару милисекунд. Здесь управляемый код рулит. Мало вычислений, но много выделения памяти для короткоживущих объектов(так как нужны они до отправки ответа пользователю, потом их благополучно можно собрать). Операции создания и удаления короткоживущих объектов в управляемых языках дешевы.

Мы используем как клиентское приложение на терминалах самообслуживания(из соображений мультиплатформенности + удобство написания). Но такое использование java нетипично. Впрочем, в производительность мы не упирались ни разу, хотя никто не парился с предварительными оптимизациями.

Здравствуйте, Pzz, Вы писали:

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

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

Здравствуйте, Sinclair, Вы писали:

S>Вот тут вот: откуда берется информация о том, что причитается пользователю?
Примерно из тех же мест что в венде, линухе итп.

S>Вот тут вот: куда именно смотрит процесс пользователя на права приложения?
Примерно также как с пользователями.
Как при заведении пользователя ему выставляют права так и при инсталяции приложения ему выставляют права.

Здравствуйте, Cyberax, Вы писали:

C>Мне так интуитивно кажется, что какая-то система типа CAS всё равно понадобится для практической реализации всего этого. Но в очень упрощённом виде, скорее всего.
А зачем?

Здравствуйте, WolfHound, Вы писали:
S>>Вот тут вот: откуда берется информация о том, что причитается пользователю?
WH>Примерно из тех же мест что в венде, линухе итп.
Ок, предположим, это работает.
WH>Как при заведении пользователя ему выставляют права так и при инсталяции приложения ему выставляют права.
Ну то есть опять имеем CAS — code access security.

Здравствуйте, Sinclair, Вы писали:

WH>>Как при заведении пользователя ему выставляют права так и при инсталяции приложения ему выставляют права.
S>Ну то есть опять имеем CAS — code access security.
Нет. Это application access security.
Привилегии не зависят от кода как такового.
При проверках не используется анализ стека.

Собственно говоря по логике вещей нужно делать код отдельно приложение отдельно.
Те весь код лежит в подписанных сборках.
А приложение это грубо говоря подписанный XML в котором прописанно какие сборки этому приложению нужны.
В какой сборке и как завут точку входа.
И какие привилегии это приложение хочет.

При установке смотрим в XML и читаем от туда привилегии.
Спрашиваем у юзера хочет ли он дать эти привилегии этому приложению.
Если приложение много хочет то говорим про это пользователю.
Пользователь выберает какие привилегии этому приложению дать.
Далее ОСь ищет сборки. Как вариант скачивает из интернета. В том числе через p2p.
Если все сборки прошли верификацию то приложение установлено.
Все!

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

Здравствуйте, Eugeny__, Вы писали:

E__>Да никто и не позиционировал ту же джаву как идеальное средство обработки мультимедиа.
E__>Больше всего java сейчас на серверах. Те самые энтерпрайз системы. Где масса работы со строками, но почти нет никаких хитрых вычислений. Множество объектов создается, чтобы жить пару милисекунд. Здесь управляемый код рулит. Мало вычислений, но много выделения памяти для короткоживущих объектов(так как нужны они до отправки ответа пользователю, потом их благополучно можно собрать). Операции создания и удаления короткоживущих объектов в управляемых языках дешевы.

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

Здравствуйте, Eugeny__, Вы писали:

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

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

Проверка границ массивов — это другое, это просто оптимизация, которая семантику программы гарантированно (т.е это строго доказуемо) не меняет.

Здравствуйте, WFrag, Вы писали:

WF>Вообще-то, наоборот. Код, собранный нормальным компилятором верификации не требует
Требует.
Ибо мы не знаем чем его соберали и не хакнули ли его по дороге.
А вот когда проверифицируем тогда и узнаем.

Здравствуйте, Pzz, Вы писали:

Pzz>На серверах ява в определенных (довольно типичных в реальной жизни) случаях могла бы сильно обгонять средней наивности код, написанный на Си. Например за счет более оптимизации обращений к базе данных. Скажем, собирая записи в базу кучками в транзакцию, и откатываясь автоматически по коду назад, если транзакция не прошла. С не-managed языком так не сделаешь, а руками такое городить тоже сил не хватит. Не знаю, впрочим, реализовал ли кто-нибудь уже эту идею на практике. Но ясно, что рано или поздно реализуют.

Если я правильно тебя понял, то у Майкрософт лет 15 назад был такой проект (Warp OS кажется). В общем это была исследовательская ОС, которая могла ход выполнения программы менять на противоположный и обратно в любой момент времени. Сейчас они хотят включить те наработки в CLR.