Prev: The next recall
Next: cop labor monopoly
From: Larry G on 22 Apr 2010 10:02 On Apr 21, 11:17 pm, Scott in SoCal <scottenazt...(a)yahoo.com> wrote: > Last time on rec.autos.driving, Clark F Morris > <cfmpub...(a)ns.sympatico.ca> said: > > Clark, > > Thanks for you reply, but I already know the answer. I just wanted to > watch Larry hem and haw as he tried to come up with something. :) > > Larry, take note: it is the HARDWARE that supports this buffer overrun > protection. Without the right support from the hardware, there's > virtually nothing the OS can do to prevent overruns in user buffers. I admitted early on that I did not know the exact details.. but I do know that OS can be (or not be written) to deal with buffer overflow issues (or I though so).. so it sounds like it's not the OS but the hardware? or did you mean firmware?
From: Larry G on 23 Apr 2010 06:02 On Apr 23, 12:29 am, "Floyd Rogers" <fbloogy...(a)hotmail.com> wrote: > "Larry G" <gross.la...(a)gmail.com> wrote > > >Scott in SoCal <scottenazt...(a)yahoo.com> wrote: > >> Larry, take note: it is the HARDWARE that supports this buffer overrun > >> protection. Without the right support from the hardware, there's > >> virtually nothing the OS can do to prevent overruns in user buffers. > > >I admitted early on that I did not know the exact details.. but I do > >know that OS can be (or not be written) to deal with buffer overflow > >issues (or I though so).. so it sounds like it's not the OS but the > >hardware? or did you mean firmware? > > No. The actual hardware, usually implemented on the processor > chip, which has bits for memory access rights on a per-page basis. > Attempts to write beyond the end of a page or writing to a read- > only page generates a page fault which is then handled by the OS. > > But that's only a bare outline. bring this back to cars and "by-wire" functionality...
From: Larry G on 23 Apr 2010 06:03 On Apr 23, 12:43 am, Scott in SoCal <scottenazt...(a)yahoo.com> wrote: > Last time on rec.autos.driving, Larry G <gross.la...(a)gmail.com> said: > > >> Larry, take note: it is the HARDWARE that supports this buffer overrun > >> protection. Without the right support from the hardware, there's > >> virtually nothing the OS can do to prevent overruns in user buffers. > > >I admitted early on that I did not know the exact details.. but I do > >know that OS can be (or not be written) to deal with buffer overflow > >issues (or I though so).. so it sounds like it's not the OS but the > >hardware? or did you mean firmware? > > Well, the BEST way to prevent buffer overruns is to use good > programming practices. However, the most efficient way to verify that > you're really doing is right is to run your code on hardware that has > memory protection features. Tools like Purify and Bounds Checker > leverage this hardware support to detect overruns, memory leaks, and > the like. The reason you have to buy tools like Purify and Bounds > Checker is because the OS *doesn't* do those things. :) okay.. let's bring this back to software that controls "by-wire" auto functions
From: Larry G on 23 Apr 2010 11:04 On Apr 23, 10:49 am, Scott in SoCal <scottenazt...(a)yahoo.com> wrote: > Last time on rec.autos.driving, Larry G <gross.la...(a)gmail.com> said: > > >> Well, the BEST way to prevent buffer overruns is to use good > >> programming practices. However, the most efficient way to verify that > >> you're really doing is right is to run your code on hardware that has > >> memory protection features. Tools like Purify and Bounds Checker > >> leverage this hardware support to detect overruns, memory leaks, and > >> the like. The reason you have to buy tools like Purify and Bounds > >> Checker is because the OS *doesn't* do those things. :) > > >okay.. let's bring this back to software that controls "by-wire" auto > >functions > > We never left. :) > > Embedded systems in cars are certainly vulnerable to these sorts of > problems, and need good programming practices just as much. > -- I thought it was a hardware issue....
From: gpsman on 22 Apr 2010 01:12
On Apr 21, 11:17 pm, Scott in SoCal <scottenazt...(a)yahoo.com> wrote: > Last time on rec.autos.driving, Clark F Morris > <cfmpub...(a)ns.sympatico.ca> said: > > Clark, > > Thanks for you reply, but I already know the answer. I just wanted to > watch Larry hem and haw as he tried to come up with something. :) Sure. The only thing you've ever previously posted that you know is who is in your way, why, what they are thinking, and traffic code that you misapply to your ROW. ;) > The MFFY Litmus Test: > If your maneuver forces another driver who has the right-of-way > to alter course or speed, what you did was probably MFFY. A litmus test for MFFY suggests the obvious. ----- - gpsman |