search

openlcb / documents

The OpenLCB specification: standards, recommended practices and other documentation.
3 stars 7 forks source link

Memory Configuration Standard: Does it really require that the top-three memory spaces be available? #98

Closed bobjacobsen closed 2 weeks ago

bobjacobsen commented 5 months ago

Section 4.2 of the Memory Configuration Standard says in relevant part:

Of the 256 unique address spaces, those that follow are required to be implemented by any node that implements this Standard (these may or may not have content on a particular node); the following address space numbers can only be used for the specified purpose, and if the corresponding information is available, it must be accessible by these address space selectors (in addition to any others the designer might provide): • (space=0xFF, control bits=0b0000011) Configuration definition – A read-only space containing the Configuration Description Information for this node, if any. • (space=0xFE, control bits=0b00000010) All memory – This special space provides access to all memory in the device, where “all” is defined by the designer. • (space=0xFD, control bits=0b00000001) Configuration – A writable basic configuration space, with the structure of the 32-bit space defined by the designer.

Several types of node now in the field respond to a Get Address Space Information Command (section 4.15) for space 0xFE with Address Space Not Present.

I think the language in the Standard is ambiguous here. It says both "are required to be implemented" on one hand, and 'these may or may not have content on a particular node" and "if the corresponding information is available" on the other.

I would prefer that this be reworded to remove the "are required" clause:

Of the 256 unique address spaces, the following address space numbers can only be used for the specified purpose, and if the corresponding information is available (these may or may not have content on a particular node) it must be accessible by these address space selectors (in addition to any others the designer might provide): ...

balazsracz commented 5 months ago

The particular problem here is that accessing "all memory" is a major security and safety issue for any production device. While it is very well defined what "all memory" means for a 32-bit processor / SoC, giving access to it externally brings absolutely no value to the user, but makes it possible to do great damage:

I support the new wording. I would put a comma after the first parenthesized subclause.

I don't actually think having "all memory" as 0xFE in this list is very productive. Maybe we should remove it. I don't really have a suggestion on what else we should put there, so maybe this is not urgent.

dpharris commented 5 months ago

0xFE "all memory" could be of use to nodes on a private bus, say for development, where the owner does want to change any part of memory. I guess the counter to that is: if that use-case is required, it can be assigned any unused address-space.

David

On Tue, Feb 13, 2024 at 2:06 PM Balazs Racz @.***> wrote:

The particular problem here is that accessing "all memory" is a major security and safety issue for any production device. While it is very well defined what "all memory" means for a 32-bit processor / SoC, giving access to it externally brings absolutely no value to the user, but makes it possible to do great damage:

  • Accessing memory mapped peripherals can cause malfunctions, including defeating safety-relevant features of the product such a short circuit protection. Ultimately this is a fire risk.
  • Accessing code space allows theft of IP, and producing counterfeit products with very little engineering effort.
  • Accessing "all memory" can be used to extract cryptographic keys that were shipped with the product.

I support the new wording. I would put a comma after the first parenthesized subclause.

I don't actually think having "all memory" as 0xFE in this list is very productive. Maybe we should remove it. I don't really have a suggestion on what else we should put there, so maybe this is not urgent.

— Reply to this email directly, view it on GitHub https://github.com/openlcb/documents/issues/98#issuecomment-1942720097, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAEDQSVQRSIF6YHLUO2WH6TYTPPXFAVCNFSM6AAAAABDHHSNMKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNBSG4ZDAMBZG4 . You are receiving this because you are subscribed to this thread.Message ID: @.***>

balazsracz commented 5 months ago

I understand that this "sounds cool" and there is a "whynot" effect, but... has anybody ever actually done that? I mean do debugging with remote memory access via openlcb?

I have developed quite a few things via openlcb, and I debugged a lot. I find that if I have to debug something, I will use the tools that were designed to do that. They connect to the processor using dedicated ports (e.g. jtag/swd), and they have all the tools setup for this communication and interaction (e.g. gdb).

Doing debugging without the actual debug tools is really really miserable.