| juliusb | r0 is probably writable in any mode | 00:14 |
|---|---|---|
| derRichard | that's not good | 00:15 |
| derRichard | if r0 is really writeable in any mode linux has to save/restore r0 upon context switch | 00:16 |
| juliusb | no, but the ABI says it's not | 00:18 |
| juliusb | physically it probably is bus a) no ASM code will write it and b) no GCC-emitted code will write it | 00:18 |
| derRichard | so, r0 is in fact _not_ writable? | 00:19 |
| juliusb | there's a difference between what the ABI says and what teh hardware lets you do, right? | 00:20 |
| juliusb | the ABI says it's not writable, you shouldn't write it and it should read as zero | 00:20 |
| derRichard | can i change r0 using some black magic asm? | 00:20 |
| derRichard | that's the question | 00:20 |
| juliusb | yes, in all the HW that's available it's writable | 00:21 |
| derRichard | if 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 r0 | 00:22 |
| juliusb | but your bad task is then fundamentally corrupt and misusing the architecture | 00:22 |
| juliusb | like doing l.jalr r4; l.ori r9,r0,0x100 | 00:23 |
| derRichard | juliusb: so what? this way a unprivileged user cann corrupt the kernel | 00:23 |
| juliusb | that's not allowed - changint he link register in the delay slot | 00:23 |
| derRichard | that's a security bug | 00:23 |
| juliusb | sure probably | 00:23 |
| juliusb | in that regard, I believe OR1k has a few floors | 00:23 |
| derRichard | not nice, not nice :( | 00:25 |
| juliusb | probably not, but in that regard, something screwing with the link register in the delay slot might also be a security floor | 00:26 |
| juliusb | (not sure, though, probably not actually) | 00:26 |
| derRichard | jonibo_: 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 tasks | 00:29 |
| juliusb | i'm not certain it's a security risk but it's probably a risk to functionality | 00:36 |
| derRichard | juliusb: if a unprivileged task can corrupt other tasks it is | 00:36 |
| derRichard | but maybe jonas took already care of this case. | 00:37 |
| stekern | why save and restore it? | 05:06 |
| stekern | why 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 detail | 07:12 |
| jonibo_ | the arch spec does, however, say that r0 may _not_ be written to | 07:13 |
| stekern | yeah, that's the fussy thing ;) | 07:13 |
| jonibo_ | so GCC will never cause a write to r0 to happen | 07:13 |
| stekern | if you're going to interpret that strictly, you're not allowed to write 0 to it neither | 07: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 return | 07:16 |
| jonibo_ | juliusb: anything that is a "risk to functionality" is a security risk because you can cause a denial-of-service situation | 07: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 |
| axxlq1 | Hello. 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 https://github.com/lgeek/orpsoc. But it doesn't help. What can I do? | 08:56 |
| stekern | try using ft245 instead of the usbblaster option | 09:02 |
| axxlq1 | thanks, I will | 09:08 |
| derRichard | jonibo_: 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 beginning | 11:31 |
| jonibo_ | derRichard: just make that one patch... those are related changes | 12:40 |
| derRichard | jonibo_: okay | 12:42 |
| derRichard | i'll send it later. currently i'm busy with $DAYJOB | 12:42 |
| jonibo_ | me too! | 12:50 |
| derRichard | has or1k a comapre and exchane operation? | 20:44 |
| jessica1 | Hi. I'd tried to build linux(that downloaded from git://openrisc.net/jonas/linux), but it fails with folow error | 21:28 |
| jessica1 | "arch / openrisc / kernel / signal.c: 308:10: error: 'struct pt_regs' has no member named 'syscallno'" | 21:28 |
| jessica1 | what is this? | 21:29 |
| derRichard | jonibo_: see: http://lists.openrisc.net/pipermail/linux/2012-March/000247.html | 21:29 |
| jessica1 | thanks | 21:29 |
| derRichard | ups, i meant jessica1, not jonibo_ :) | 21:29 |
| jessica1 | I understand :) | 21:30 |
| derRichard | jonibo_: are you here? | 22:34 |
| derRichard | EXCEPTION_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 _start | 22:36 |
| stekern | use l.movhi r0, 0 instead of l.addi when you're in there | 22:41 |
| derRichard | is it faster? what about l.xor r0,r0,r0? | 22:41 |
| stekern | it doesn't use r0 as a source register (it's only matters when you are simulating the verilog code) | 22:42 |
| stekern | l.xor and l.andi might work too due to the rules of logic arithmetics on 'x' | 22:43 |
| stekern | but l.movhi is still clearer | 22:44 |
| stekern | actually, I'm not sure l.xor would work after all | 22:45 |
| derRichard | why not? | 22:45 |
| derRichard | x86 is using this trick all the time | 22:45 |
| stekern | whats '1' xor 'x' and '0' xor 'x'? | 22:46 |
| derRichard | r0 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 0 | 22:47 |
| stekern | yeah, it'll work in hardware, no problem, it's just when you run simulations, r0 will contain 'x' on startup | 22:49 |
| stekern | yes the question should have been, what is 'x' xor 'x', you're right | 22:49 |
| derRichard | sorry, i really don't care about simulations. | 22:50 |
| derRichard | if you have to change the real thing to make the simulation work somthing is really broken... | 22:50 |
| stekern | well, speedwise they are the same, som you might as well use the l.movhi... | 22:51 |
| stekern | l.addi might not work on the real thing even | 22:52 |
| derRichard | why? | 22:54 |
| olofk | It's not just simulation. It's bad ASIC practice too, even if that is probably taken care of earlier on | 22:54 |
| stekern | if r0 isn't zero r0 will not end up as zero | 22:55 |
| derRichard | stekern: ups, i meant l.andi. not addi | 22:55 |
| derRichard | sorry | 22:56 |
| stekern | l.andi is fine, even in simulations | 22:56 |
| derRichard | l.andi r0,r0,0 | 22:56 |
| stekern | since '0' and 'x' is '0' | 22:56 |
| derRichard | yeah | 22:57 |
| _franck_ | stekern: I think you tried the dbg_if with openocd | 23:01 |
| _franck_ | did you use the default config of dbg_if in your git repo ? | 23:01 |
| stekern | yes | 23:01 |
| _franck_ | ok just to be sure | 23: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 |
| stekern | yeah, I bleieve I saw something like that too when I did my half-arsed try to mix-match vjtag and old dbg_if | 23:03 |
| _franck_ | ok interesting | 23:04 |
| olofk | There was a bug with dbg_if that shifted it one bit. It was fixed in the orpsocv2 version | 23:04 |
| stekern | olofk: recently? | 23:04 |
| _franck_ | what about the version on opencores website ? | 23:04 |
| olofk | A few years ago | 23:04 |
| stekern | well, then probably that fix is in there ;) | 23:05 |
| stekern | _franck_: orpsocv2 is on opencores | 23:05 |
| _franck_ | ok :( I'd love to update dbg_if at see things works :) | 23:05 |
| olofk | I filed a bug against the upstream version | 23: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 |
| stekern | which is orpsoc | 23:07 |
| olofk | That 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 bug | 23: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 vjtag | 23: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 vjtag | 23:12 |
| olofk | May the best version win | 23:12 |
| olofk | This will help me deciding if I should add a patch to orpsocv3 too | 23:13 |
| _franck_ | not easy to debug with leds :) | 23:13 |
| olofk | It's harder without them :) | 23:13 |
| _franck_ | sure | 23:13 |
| _franck_ | enough for tonight | 23:14 |
| _franck_ | see you | 23:14 |
| stekern | leds are the best debug tools ever! | 23:14 |
| _franck_ | :) | 23:14 |
Generated by irclog2html.py 2.15.2 by Marius Gedminas - find it at mg.pov.lt!