The problem of unsafe opcodes only happens in x86 and it's fabulous
risc design. We should move to arm or mips and make explicit that
suckless cant run on Intel hardware
On Jun 17, 2010, at 4:55 AM, David Tweed <david.tweed_AT_gmail.com> wrote:
> On Thu, Jun 17, 2010 at 3:32 AM, Kurt H Maier <karmaflux_AT_gmail.com>
> wrote:
>> On Thu, Jun 17, 2010 at 2:27 AM, David Tweed
>> <david.tweed_AT_gmail.com> wrote:
>>> "obviously safe machine code"
>>
>> hahahahahah
>
> Would you care to elaborate on this? The compilation problem is
> asymmetric: there's going to be lots of code sequences that are in
> fact innocuous which the verifier can't show to be innocuous, but I
> don't see any reason why it's not possible to have a compiler that can
> compile some code that it can show to be innocuous into safe machine
> code. (Ie, the compiler may be refuse to compile a given piece of
> code, but if it does compile it's as safe as running interpreted code
> -- ie, up to the level of undocumented chip errata could be exploited
> in either case.) I'm genuinely interested if there is a flaw in this
> reasoning, because I spend a lot of time writing numerical SIMD code
> that you can't access from languages where the semantics means values
> need to be "boxed". All I'm interested in are machine instructions for
> SIMD plus enough scalar operations and known address conditional jumps
> to implement marching through arrays of data. The compiler can refuse
> to compile any code containing any of the other instructions in the
> instruction set and I won't care. (Clearly I don't even need Turing
> completeness in the sections of the application that are compiled to
> native instructions.) Are you saying the NaCl-style verification
> approach cannot work in such a case?
>
> --
> cheers, dave tweed__________________________
> computer vision reasearcher: david.tweed_AT_gmail.com
> "while having code so boring anyone can maintain it, use Python." --
> attempted insult seen on slashdot
>
Received on Thu Jun 17 2010 - 07:02:35 UTC
This archive was generated by hypermail 2.2.0 : Thu Jun 17 2010 - 07:12:02 UTC