IRC logs for #openrisc Monday, 2012-03-05

juliusbr0 is probably writable in any mode00:14
derRichardthat's not good00:15
derRichardif r0 is really writeable in any mode linux has to save/restore r0 upon context switch00:16
juliusbno, but the ABI says it's not00:18
juliusbphysically it probably is bus a) no ASM code will write it and b) no GCC-emitted code will write it00:18
derRichardso, r0 is in fact _not_ writable?00:19
juliusbthere's a difference between what the ABI says and what teh hardware lets you do, right?00:20
juliusbthe ABI says it's not writable, you shouldn't write it and it should read as zero00:20
derRichardcan i change r0 using some black magic asm?00:20
derRichardthat's the question00:20
juliusbyes, in all the HW that's available it's writable00:21
derRichardif my bad task changes r0 to 1 the kernel will do some fancy shit after the next context switch. because the kernel seem not to save/restore r000:22
juliusbbut your bad task is then fundamentally corrupt and misusing the architecture00:22
juliusblike doing l.jalr r4; l.ori r9,r0,0x10000:23
derRichardjuliusb: so what? this way a unprivileged user cann corrupt the kernel00:23
juliusbthat's not allowed - changint he link register in the delay slot00:23
derRichardthat's a security bug00:23
juliusbsure probably00:23
juliusbin that regard, I believe OR1k has a few floors00:23
derRichardnot nice, not nice :(00:25
juliusbprobably not, but in that regard, something screwing with the link register in the delay slot might also be a security floor00:26
juliusb(not sure, though, probably not actually)00:26
derRichardjonibo_: shouldn't EXCEPTION_ENTRY in kernel/entry.S save r0 and RESTORE_ALL restore r0? AFAIK a unprivileged task can change r0 and currupt the kernel and/or other tasks00:29
juliusbi'm not certain it's a security risk but it's probably a risk to functionality00:36
derRichardjuliusb: if a unprivileged task can corrupt other tasks it is00:36
derRichardbut maybe jonas took already care of this case.00:37
stekernwhy save and restore it?05:06
stekernwhy not just write 0 to it while restoring the other registers?05:07
jonibo_hmmm... interesting discussion.07:12
jonibo_it's not so much that r0 _is_ writable, it's that it _might_ be... it's an implementation detail07:12
jonibo_the arch spec does, however, say that r0 may _not_ be written to07:13
stekernyeah, that's the fussy thing ;)07:13
jonibo_so GCC will never cause a write to r0 to happen07:13
stekernif you're going to interpret that strictly, you're not allowed to write 0 to it neither07:14
jonibo_stekern: exactly...07:14
jonibo_that said, derRichard makes an interesting point: if somebody makes a rogue application that does write to r0, and that particular implementation contains writable memory for that register, then that's a security flaw (or floor, as juliusb writes... will have to check if that's an australian spelling ;) )07:16
jonibo_so, yes, r0 should certainly be overwritten with a 0 on exception entry and return07:16
jonibo_juliusb: anything that is a "risk to functionality" is a security risk because you can cause a denial-of-service situation07:17
jonibo_and just because I know derRichard is going to ask: yes, r0 should be explicitly cleared at startup (it currently isn't)...07:22
axxlq1Hello. I'm using altera virtual jtag and adv_debug_sys software. But I can't connect to the de0-nano board with or32-elf-gdb. Is that real? I found some manual at But it doesn't help. What can I do?08:56
stekerntry using ft245 instead of the usbblaster option09:02
axxlq1thanks, I will09:08
derRichardjonibo_: okay. i'll send you two patches. 1. which sets r0 to zero on each entry and 2.which sets r0 to 0 at the very beginning11:31
jonibo_derRichard: just make that one patch... those are related changes12:40
derRichardjonibo_: okay12:42
derRichardi'll send it later. currently i'm busy with $DAYJOB12:42
jonibo_me too!12:50
derRichardhas or1k a comapre and exchane operation?20:44
jessica1Hi. I'd tried to build linux(that downloaded from git://, but it fails with folow error21:28
jessica1"arch / openrisc / kernel / signal.c: 308:10: error: 'struct pt_regs' has no member named 'syscallno'"21:28
jessica1what is this?21:29
derRichardjonibo_: see:
derRichardups, i meant jessica1, not jonibo_  :)21:29
jessica1I understand :)21:30
derRichardjonibo_: are you here?22:34
derRichardEXCEPTION_ENTRY(_tng_kernel_start) sets r0 already to 0 but only _after_ jumping to _start. i'd move the l.addi r0,r0,0 in front of the l.jal _start22:36
stekernuse l.movhi r0, 0 instead of l.addi when you're in there22:41
derRichardis it faster? what about l.xor r0,r0,r0?22:41
stekernit doesn't use r0 as a source register (it's only matters when you are simulating the verilog code)22:42
stekernl.xor and l.andi might work too due to the rules of logic arithmetics on 'x'22:43
stekernbut l.movhi is still clearer22:44
stekernactually, I'm not sure l.xor would work after all22:45
derRichardwhy not?22:45
derRichardx86 is using this trick all the time22:45
stekernwhats '1' xor 'x' and '0' xor 'x'?22:46
derRichardr0 is 0 or non-0. so we get r0 = 0 xor 0 _or_ r0 = non-0 xor non-0. which will result in both cases in 022:47
stekernyeah, it'll work in hardware, no problem, it's just when you run simulations, r0 will contain 'x' on startup22:49
stekernyes the question should have been, what is 'x' xor 'x', you're right22:49
derRichardsorry, i really don't care about simulations.22:50
derRichardif you have to change the real thing to make the simulation work somthing is really broken...22:50
stekernwell, speedwise they are the same, som you might as well use the l.movhi...22:51
stekernl.addi might not work on the real thing even22:52
olofkIt's not just simulation. It's bad ASIC practice too, even if that is probably taken care of earlier on22:54
stekernif r0 isn't zero r0 will not end up as zero22:55
derRichardstekern: ups, i meant l.andi. not addi22:55
stekernl.andi is fine, even in simulations22:56
derRichardl.andi r0,r0,022:56
stekernsince '0' and 'x' is '0'22:56
_franck_stekern: I think you tried the dbg_if with openocd23:01
_franck_did you use the default config of dbg_if in your git repo ?23:01
_franck_ok just to be sure23:01
_franck_vjtag is almost working but I have a 1 bits shift on some results...23:02
_franck_received CRC (0xc5264102) not same as calculated CRC (0x62932081)23:02
_franck_I'll continue to work on it :)23:03
stekernyeah, I bleieve I saw something like that too when I did my half-arsed try to mix-match vjtag and old dbg_if23:03
_franck_ok interesting23:04
olofkThere was a bug with dbg_if that shifted it one bit. It was fixed in the orpsocv2 version23:04
stekernolofk: recently?23:04
_franck_what about the version on opencores website ?23:04
olofkA few years ago23:04
stekernwell, then probably that fix is in there ;)23:05
stekern_franck_: orpsocv2 is on opencores23:05
_franck_ok :( I'd love to update dbg_if at see things works :)23:05
olofkI filed a bug against the upstream version23:06
_franck_ah I understand...because those individual project are not yours...23:06
olofk_franck_: Which one are you using? The one in orpsoc, or the upstream version?23:07
_franck_the one in stekern repo :)23:07
stekernwhich is orpsoc23:07
olofkThat is the orpsoc version. Then there is also the possibility that the upstream version was correct all along, and the change in orpsocv2 was compensating for another bug23:08
_franck_ok I'll try to understand how it works then I'll experiment with quartus tcl interface which is very useful to work on vjtag23:09
_franck_we'll see who is correct :)23:10
_franck_however if it works with the version in orpsoc and openocd it should work with my modified version on openocd using the vjtag23:12
olofkMay the best version win23:12
olofkThis will help me deciding if I should add a patch to orpsocv3 too23:13
_franck_not easy to debug with leds :)23:13
olofkIt's harder without them :)23:13
_franck_enough for tonight23:14
_franck_see you23:14
stekernleds are the best debug tools ever!23:14

Generated by 2.15.2 by Marius Gedminas - find it at!