2012/4/8 Ouabache Designworks <[email protected]> > > > On Sat, Apr 7, 2012 at 11:07 PM, Richard Herveille > <[email protected]>wrote: > >> Somehow I thought this was always the case, or always the intended >> behaviour. This is what was agreed with Damjan 10years ago. >> First action of the bootup code is to clear R0 and invalidate the MMU and >> Cache registers. After that the CPU should be ready for normal >> bootup-sequence. >> > > The issue is that you can reset the cpu so that it always powers up with a > 0 in R0 and the caches and mmus invalidated with very little cost or > effort. You are putting a critical requirement on the firmware designer > that is non-obvious and hard to debug. Our goal is to make this cpu easy > to use. Spending a few hours chasing a problem that turned out to be that > you forgot to clear R0 is not going to help anyone. > > Likewise we should not deal with every problem by simply putting in a > status bit that describes how the cpu behaves. Do you really expect that > firmware will load in two sets of drivers and only use one of them based on > the value that it reads from the status register? > > Don't put in options unless you know how setting them and reporting there > status will get passed between hardware and software designers. Getting > that wrong is a big problem in the design world. > > > >> >> R0 is an always 0 register, it is not null (as in the big iggy-bin). As a >> result it can be used as a source register, but it should never be used as >> a destination register (exception first instr of boot sequence). >> >> >> > Root kit developers love the word "should". They go into your design and > find out what happens when they do things that they shouldn't. > > > John Eaton > > > _______________________________________________ > OpenRISC mailing list > [email protected] > http://lists.openrisc.net/listinfo/openrisc > > Yes, the "should" part is what I am worried about too for the same reasons. For me it seems trivial to write an exploit that takes advantage of that. It seems however like the majority is for having it treated as the other GPRs so I won't make a fuss about it, but this also means it's very important to update the spec so everyone knows about this
-- Olof Kindgren ______________________________________________ ORSoC Website: www.orsoc.se Email: [email protected] ______________________________________________ FPGA, ASIC, DSP - embedded SoC design
_______________________________________________ OpenRISC mailing list [email protected] http://lists.openrisc.net/listinfo/openrisc
