On 1/24/2018 8:31 PM, Mike Franklin wrote:
> On Thursday, 25 January 2018 at 04:01:47 UTC, Mike Franklin wrote:
>> "The initial stack pointer and the address of the reset handler must be located at 0x0 and 0x4 respectively." 
> http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dai0179b/ar01s01s01.html 


"These values are then loaded into the appropriate CPU registers at reset."

This implies a ROM must be located there. Else how do initial values get there?

On Thursday, 25 January 2018 at 04:45:34 UTC, Walter Bright wrote:

> This implies a ROM must be located there. Else how do initial values get there?

I'm not sure what you mean.  When you upload your firmware to the MCU, it writes the initial stack pointer to address 0x00 and the address of the reset handler to 0x04.  It is up the developer to set these values properly in the linker script (a.k.a scatter file).

Mike

On Thursday, 25 January 2018 at 04:45:34 UTC, Walter Bright wrote:

> This implies a ROM must be located there. Else how do initial values get there?

Yes, ROM is at address 0.  Address 0 contains the initial stack pointer.  So you read address 0, dereference it, and then do your damage.

Mike

On Thursday, 25 January 2018 at 04:59:55 UTC, Mike Franklin wrote:

> Yes, ROM is at address 0.  Address 0 contains the initial stack pointer.  So you read address 0, dereference it, and then do your damage.

Keep in mind too that the ROM, on these devices, is actually reprogrammable from the firmware itself, so one could do some clever exploitation of that feature to insert whatever they want into the product's firmware.

Mike

On 1/24/2018 9:04 PM, Mike Franklin wrote:
> On Thursday, 25 January 2018 at 04:59:55 UTC, Mike Franklin wrote:
> 
>> Yes, ROM is at address 0.  Address 0 contains the initial stack pointer.  So you read address 0, dereference it, and then do your damage.

This is from the "what were they thinking" school of CPU design. Blargh.


> Keep in mind too that the ROM, on these devices, is actually reprogrammable from the firmware itself, so one could do some clever exploitation of that feature to insert whatever they want into the product's firmware.

I've posted online many times that people creating embedded systems should put the firmware in ROM, so malware will not survive a reset.

The riposte I get is the firmware must be rewritable from the internet in order to fix malware written to it from the internet :-)

On Wednesday, January 24, 2018 18:46:38 Walter Bright via Digitalmars-d wrote:
> On 1/23/2018 7:22 PM, Jonathan M Davis wrote:
> > We need to do that anyway for the overly large
> > objects (and unfortunately don't last I heard).
>
> I put a limit in at one time for struct/class sizes to prevent this issue, but got a lot of pushback on it and it was reverted.
>
> Perhaps we can revisit that - and have large struct/classes be allow only in non-@safe code.
>
> In general, though, if you don't have struct/class object sizes larger than the protected memory at null, you're safe with null dereferences.

Yes, but we need to do _something_ about the overly large structs/classes if we want @safe to be bulletproof like it's supposed to be (barring misuse of @trusted, of course). I'd be inclined towards adding extra null-checks in those cases just because you'd end up with a balooning of @system code in your code if we made dereferencing pointers/references to them @system, but regardless, the important thing is that we do something with them (whatever that may be) so that we don't have code that the compiler claims to be @safe and then goes and does something naughty with memory. Right now, those types are a lot like dynamic arrays with -noboundscheck except that the programmer didn't knowingly choose to be unsafe.

Personally, I doubt that I've ever written code with types that large, but I really have no idea, because I don't know what the boundary is. I just know that I don't usually have really large types. But right now, it probably wouldn't be all that hard to shoot yourself in the foot by having a particularly large static array, and most folks would probably have no idea that they were making it so that they wouldn't get segfaults on null. The only reason that I know that that's possible is because of previous discussions on the topic here in the newsgroup, and I'm sure that plenty of other folks are in the same boat except that they haven't read those discussions and so still have no clue about it.

- Jonathan M Davis

On 1/24/18 9:46 PM, Walter Bright wrote:
> On 1/23/2018 7:22 PM, Jonathan M Davis wrote:
>> We need to do that anyway for the overly large
>> objects (and unfortunately don't last I heard).
> 
> I put a limit in at one time for struct/class sizes to prevent this issue, but got a lot of pushback on it and it was reverted.
> 
> Perhaps we can revisit that - and have large struct/classes be allow only in non-@safe code.
> 
> In general, though, if you don't have struct/class object sizes larger than the protected memory at null, you're safe with null dereferences.

You don't need to ban them from @safe code, what you need to do is determine if the field itself is beyond the zero page (which causes a segfault), and if so, either read from the first byte of the struct (to cause the segfault if it's in there), or verify the struct's address is not within the zero page.

We recently removed an assert for null this from all functions. Perhaps for structs that are large, in @safe code add that check back.

-Steve

On Wednesday, 24 January 2018 at 09:35:44 UTC, lobo wrote:

> And I'm broken after using D, going back to C++ is awful and Rust just has too much friction to be enjoyable.

Yep, I know exactly what you mean.

On Fri, Jan 26, 2018 at 01:08:10AM +0000, Mike Franklin via Digitalmars-d wrote:
> On Wednesday, 24 January 2018 at 09:35:44 UTC, lobo wrote:
> 
> > And I'm broken after using D, going back to C++ is awful and Rust just has too much friction to be enjoyable.
> 
> Yep, I know exactly what you mean.

Me Too (tm).  After having gotten used to D, working with C/C++ (or just about any other language, really) is just extremely painful. Unfortunately, I have no choice because my day job requires C/C++.  D has officially ruined my life. :-D


T

-- 
Notwithstanding the eloquent discontent that you have just respectfully expressed at length against my verbal capabilities, I am afraid that I must unfortunately bring it to your attention that I am, in fact, NOT verbose.

On Thursday, January 25, 2018 17:20:21 H. S. Teoh via Digitalmars-d wrote:
> On Fri, Jan 26, 2018 at 01:08:10AM +0000, Mike Franklin via Digitalmars-d
wrote:
> > On Wednesday, 24 January 2018 at 09:35:44 UTC, lobo wrote:
> > > And I'm broken after using D, going back to C++ is awful and Rust just has too much friction to be enjoyable.
> >
> > Yep, I know exactly what you mean.
>
> Me Too (tm).  After having gotten used to D, working with C/C++ (or just about any other language, really) is just extremely painful. Unfortunately, I have no choice because my day job requires C/C++.  D has officially ruined my life. :-D

Well at least you don't have to program in Java. :)

Unless something has changed in one of the recent versions, you can't even write a swap function in Java. :|

It's definitely painful to have to program in C++ after programming in D, but I still find C++ to be more pleasant than the alternatives other than D.

- Jonathan M Davis