video call on February 22
Tim Newsome
Tim Newsome
Megan Wachs
Debug Call Feb 22
Attendees — see slides
Spec — same as before, on github. Continues to be updated a lot.
Reset — some reading and discussing on the mailing list. What exactly do we need to talk about?
Alex — question about halt state after reset. Debug from the very first instruction. Is that currently supported, or does there need to be language added for that?
Tim — in my mind it’s currently supported. The idea is that the debug controls a halt signal and a global reset. So it can hold all the halt signals high, then assert and dessert the global reset. So they can all go into halt mode as they they come out of reset.
Alex — ok I’ll look and see if we need to tidy up the doc.
Richard — question. If you want to debug the hart as it comes out of reset e.g. at the second instruction. Does it specify that the triggers are all reset upon reset, or do they keep their value?
Tim — it doesn’t say, but the triggers are CSRs so it seems likely they would be reset.
Richard — so how could you do it a few instructions in?
Tim — assert halt, toggle reset, then set triggers and let it resume from there.
Richard — OK that would work. But would GDB handle the sequence? Reset hart, set this halt signal, release breakpoint, release halt sequence.
Tim — nothing automatically does this.GDB doesn’t really know about reset. OpenOCD could do this. It does not currently. It doesn’t seem like an unreasonable thing to ask opened to do.
Oubache — can you change where the first instruction will be fetched from out of reset?
Tim — yes, you can do anything in halt mode, first instruction is not special.
Megan — explains dmactive bit.
General agreement that dmactive makes sense.
Tim — any more reset? There had been a little discussion of resetting individual harts, and what does that even mean?
Stefan — technical question, does that even make sense? Resetting a program counter for multi-hart cores makes sense.
Richard — if every hart executes a different thread or different program it could make sense.
Tim — you could also say then you just change the PC back to the initial value, change priv level back, etc.
Stefan — yeah, that’s my understanding.
Richard — well, if you do a reset like that, there might be a lot of garbage hanging around, which would open up security holes.
Being able to debug from an actual reset is from some sort of “what I think reset is” and you miss what actually causes your problem.
Tim -- So no one is arguing that we need per-hart reset signals in the debug spec?
Richard — can we leave the provision there so we can put it in later?
Tim — well, it was removed. We could add more bits to DMCONTROL register, but this could be optional to implement?
Vyacheslav — so we are going to make per-hart reset as optional?
Tim — we’re not specifying it right now, maybe in the future we will specify it. I suppose that is similar. We could specify the bit now and then make it optional…
Vyacheslav — but it would be useful.
Bradley — has anyone ever implemented such a thing?
no one says yes
Bradley — so, seems like we’d need an experienced implementation, otherwise there would be unknown practical issues.
Tim — it would definitely not be a requirement.
Megan — how would you enumerate that
Tim — you could just write 1 and then read back and see if 1 is set. SHouldn’t add anything to implementations that don’t support it.
Vyacheslav — I think we should introduce it in an optional form. Such a possibility seems useful for those who likes it.
Bradley — is there a tech report for thing we should be on a standard roadmap but aren’t currently understood enough to be put in the standard? Like put it in an appendix?
Tim — so you think it shouldn’t be added as an option until someone goes and implements it.
Bradley — yeah, premature standardization is a bugbear.
(someone agrees).
Tim — what I’m thinking is we just specify a bit, So when someone does implement it they know what bit to use for it.
Bradley — nothing wrong with that, as long as we have a high confidence that it’s not going to be a terrible idea in general, and then we have bits reserved that we could have been used for something else.
Vyacheslav — I think in this concrete case resetting is a very fundamental thing and I think we should allocate a placeholder for it.
Bradley — I don’t have enough about it to have an opinion, I don’t really disagree. Just pointing out the risk.
PoWei — I vote optional. It shouldn’t be a barrier. If we require per-hart reset to be required it will be a barrier. So I really want it to be optional.
Tim — yeah, no one thinks it should be required.
Alex — reserve the bit, but leave the semantics undefined (or if someone knows about it, they can write the more detailed proposal).
Bradley — that’s basically the tech report option.
Ok, Tim will reserve the field in the register, with undefined semantics.
Vyacheslav — what about resetting other partial submodes controlled by debug module? Heard some ideas in email threads?
Megan — As a system designer, if it was important to reset something separately I’d probably have some sort of platform control for it (like a register that can be written).
Vyacheslav — what about other debug components, e.g. system bus? Does it need a separate bit? Is it necessary to reset and keep and reset some subset of those debug submodules?
Usage scenario : I’m going to carry out a series of instruction supply, but not in this debug session am I going to work with the system bus interface. So I disable the system bus mechanism.
Richard — it seems it would become very implementation dependent then… what if you put the bus in reset and other harts are running?
Tim — do we need to supply additional reset bits for unspecified devices?
Richard — then can’t you just have a register that you write that particular memory location.
Tim — yeah, not sure we can really enumerate in the debug spec everything you’d want to do. This sounds quite implementation specific.
Security:
Tim — Some discussion on the mailing list, but it kind of petered out. Seems like the handful of registers specified might not be enough, so suggested a serial protocol
Megan — serial protocol sounded good to me.
Don — yes, I suggested serial interface. What I think is most important is to create a formulation for how people should implement best practices so whatever people do implement it. WE dont need to actually put them in the spec, we should be able to just point to other best-practice recommendations from established national bodies.
Claiming in this specification of how many bits people use would limit the life of this specification and would be an error.
Tim — Ok should I just put the serial protocol in the spec
Don — I’d be happy to look over the protocol, seems like it would be good with other people who are familiar with existing debuggers to also take a look.
Tim — if you have time to pointers to any implementations or standards, that would be great. I don’t know much about this.
Don — suggest reach out to OpenOCD project lead and get his thoughts on how that could be maintained in OpenOCD so that it would be easy to work with in OpenOCD and similar applications, easy to maintain.
Tim (grepping OpenOCD) — at least there is a thing called “passwords” in OpenOCD. These are generally used to unlock scary features like erasing flash banks.
Don — yeah, it really is for unlocking extra features. It’s not the proposal we have here at all.
Tim — can you write a more “security” part for the spec.? I’ll write up the simple transport.
Don — sure, I will use this as a basis for moving forward. I’ll have an alpha version ready for next week.
Vyacheslav — request for clarification. Does deactivation of debug module reset authentication state?
Tim — that makes sense to me, but it does not explicitly say so.
Vyacheslav — is it necessary some way to authenticate what the source of the transactions are? What if there are several masters accessing the debug module, is it necessary to authenticate the correspondent?
Tim — I think whatever security protocol you implement would handle that (e.g. PK techniques). Sure, there is an issue that if serial registers are all on a bus, people can snoop…?
Don — this can all be accomplished in the protocol itself. You can do ECDH or perfect forward security so that a unique key is created per-session. It would be more complex for the implementation, but if it’s just a simple serial protocol passing things back and forth across.
The only caveat there is only how does the debug module retrieve the information, to decrypt and encrypt information.
Tim — you’re talking about all traffic going across a serial interface. What we have speced now is that there is some way to unlock it, then all this functionality is available to whoever has access to that bus.
Don — if you’re paranoid about this security model, the only way to correctly do it is to pass all information through the authentication module first. But in my opinion this is kind of unnecessary, you should be working in a SCIF. I don’t know if this is realistic to worry about this scenario. This is sort of an outlier and this is not what this should be built for. For the purposes you could say something like all traffic would go through the authentication module.
Tim — so then you would say there is a different Debug Transport Module which is more like the serial thing you described which performs all the encryption/decryption.
Tim — I don’t want to spec a more complicated serial protocol to support this case.
Don — we could put a recommendation. IF this is something you really care about, here’s a theoretical model which might satisfy your concerns. But we’re not going to spec this.
Tim -- Makes sense. Probably won't put this in the spec for now.
Vyacheslav — sounds good. i just like raising interesting questions so we know what our opinion on them is.
Mailing list discussion —
Tim — Just a high level point that we should be continuing discussion on the mailing list. If there is something you care about, please raise discussion on the list, or email and include on the slides. If you don’t do it, odds are no one will. General call for participation and contribution.
Tim Travel —
Tim will be gone for 3 months in South America. In that time Megan will talk at meetings when everyone else is quiet.
Other —
Megan — calling attention to implementations that are in progress. Tim Adding to Spike and OpenOCD, this is basically working. (debug-0.13 branch of Spike). Megan working on rocket-chip Debug Module / DTM implementation.
AIs:
All — read and discussion next weeks topics: Triggers and Serial Ports
Tim to add the optional per-hart reset bit to the definition of the register with undefined semantics.
Tim to add serial transport for authentication
--
You received this message because you are subscribed to the Google Groups "RISC-V Debug Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to debug+unsubscribe@groups.riscv.org.
To post to this group, send email to de...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/debug/.
To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/debug/CAGDihemDCGgGYi3eP3BQnDSOt2UcTtYB%3D%2BH5edcd9XoUW6j5oQ%40mail.gmail.com.
Tim Newsome
To unsubscribe from this group and stop receiving emails from it, send an email to debug+un...@groups.riscv.org.
To post to this group, send email to de...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/debug/.
To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/debug/CAGDihemDCGgGYi3eP3BQnDSOt2UcTtYB%3D%2BH5edcd9XoUW6j5oQ%40mail.gmail.com.