• State Resolved
  • Locked Locked
  • Replies 8 replies
  • Subscribers 30 subscribers
  • Views 234 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

TMS570LC4357: Protecting from nullptr read/writes via MPU on TMS570 series of MCUs

phitastic
Prodigy 65 points
Part Number: TMS570LC4357
Other Parts Discussed in Thread: HALCOGEN

Tool/software:

Hi TI gurus,

I recently came across this article: NULL pointer protection with ARM Cortex-M MPU.  It outlines a clever way to protect from reads/writes to address 0x00 (nullptr) by setting up an MPU region at 0x00 where the MPU prevents all read/writes.  The article describes this nullptr protection for Cortex-M but it should hold similarly for Cortex-R, as well as the VIM-based HW interrupt dispatching method implemented on the TMS570. One interesting aspect is that it works on the Cortex-M without moving the vector table (see subheading "What About the Vector Table?" in the article above), which makes it attractive for the TMS570 where the vector table can't be moved.

To port to the TMS570, I set up a MPU region from 0x00 - 0x20 (since the interrupt vector is only 32 bytes when using VIM), and declared it as MPU_PRIV_NA_USER_NA_NOEXEC and NORMAL_OINC_NONSHARED.

My hope was that this is sufficient to avoid nullptr read/writes, but unfortunately it does not work immediately on the TMS570LC4357 -- I end up with the red ERROR LED and the debugger breaking on or before prefetchEntry in sys_intvecs.asm.  

Would anyone know if this method can in fact be ported to the TMS570 and how?

Thanks!
 

  • 0
    TI__Guru 58640 points

    Hi ,

    The default configuration generated from HALCoGen for any new project will always prevent the null pointer write.

    As you can see the first 4MB of the flash is configured for read only in both privilege and user modes, but we just keep the execution for first 4MB. So same configuration will also applicable for VECTORS as well because they also from 0x0 to 0x20. So, no null pointer writes will takes place here.

    phitastic said:
    To port to the TMS570, I set up a MPU region from 0x00 - 0x20 (since the interrupt vector is only 32 bytes when using VIM), and declared it as MPU_PRIV_NA_USER_NA_NOEXEC and NORMAL_OINC_NONSHARED.

    This might be the issue in your case, maybe we should not keep the No execution (NOEXEC) for vectors because the starting address of the flash that is resetEntry(0x0) will only point to the code starting address in this case _c_int00.

    So, the VECTORS should execute the 0x0 to move the execution to the code. So, we might not keep the no execution for VECTORS.

    --
    Thanks & regards,
    Jagadish.

  • 0 in reply to jagadish gundavarapu
    Prodigy 65 points

    Thanks, -- adding the EXEC flag fixes the problem!  We now have both nullptr write & read protection, similar to the method in the article linked previously (NULL pointer protection with ARM Cortex-M MPU).

    One issue I am seeing is when the SafeTI tests are enabled.  It looks like those perform reads of the vector table (and thus cause an MPU failure):

    56                b   svcEntry
00000000:   ???? Target failed to read 0x00000000 [code=0x1]
57        prefetchEntry
00000004:   ???? Target failed to read 0x00000004 [code=0x1]
58                b   prefetchEntry
00000008:   ???? Target failed to read 0x00000008 [code=0x1]
59        dataEntry
0000000c:   ???? Target failed to read 0x0000000C [code=0x1]
60                b   dataEntry
00000010:   ???? Target failed to read 0x00000010 [code=0x1]
61                b   phantomInterrupt
00000014:   ???? Target failed to read 0x00000014 [code=0x1]
62                ldr pc,[pc,#-0x1b0]
00000018:   ???? Target failed to read 0x00000018 [code=0x1]
63                ldr pc,[pc,#-0x1b0]
0000001c:   ???? Target failed to read 0x0000001C [code=0x1]

    I moved flashBadECC1 and flashBadECC2 away from the 0x00 region but am still seeing the issue above.  Would you perhaps have an idea which of the self tests may be performing those reads and thus conflict with the MPU read protection at 0x00 - 0x20? 

    Thanks!

  • 0 in reply to phitastic
    TI__Guru 58640 points

    Hi ,

    phitastic said:
    I moved flashBadECC1 and flashBadECC2 away from the 0x00 region but am still seeing the issue above.  Would you perhaps have an idea which of the self tests may be performing those reads and thus conflict with the MPU read protection at 0x00 - 0x20? 

    You are correct flashBadECC1 and flashBadECC2 will use this vector table locations. But i am unable to recall what other tests can use this area.

    And also i am suspecting IRQ and FIQ interrupts have also dependency with this area:

    I am thinking maybe it is not good idea to disable read permission to this VECTORS location. At least read permission might be required to execute any applications seamlessly.

    --
    Thanks & regards,
    Jagadish.

  • 0 in reply to jagadish gundavarapu
    Prodigy 65 points

    Thanks, .  It's interesting-- in the original article it points out that for normal exception handling, the MCU uses different instructions than LDR/STR, and "Apparently, the MPU does not check access to the region by instructions other than LDR/STR, such as reading the vector address during the Cortex-M exception entry.".  So if the Cortex-R behaves similarly, it should be OK to have read access disabled in the VECTORS location.  In my tests, that does work fine with non-SafeTI builds (I haven't tested that exhaustively, though).

  • 0 in reply to phitastic
    TI__Guru 58640 points

    Hi Phitastic,

    Can you please elaborate it further. I don't get it.

    --
    Thanks & regards,
    Jagadish.

  • 0 in reply to jagadish gundavarapu
    Prodigy 65 points

    Per the article I linked, locking the vector table with `PRIV_NA_USER_NA` should work fine, since the MPU only guards against LDR/STR in that region, but the interrupt stuff uses different instructions. That is indeed the case for non-SafeTI builds.  When I use the SafeTI library with its set of startup tests, some of the tests cause an abort, which has been very hard to pinpoint. I assume there are some side effects of some of the tests (Ecc?) that effectively cause a read from that 0x00 - 0x20 region.  

  • +1 in reply to phitastic
    TI__Guru 58640 points
    phitastic said:
    I assume there are some side effects of some of the tests (Ecc?) that effectively cause a read from that 0x00 - 0x20 region

    You are correct, this could happen.

    I cannot pinpoint exact tests, but some tests might have VECTORS dependency. SafeTI diagnostic library is a huge library it took lot of time to figure out exactly which tests have this dependency.

  • 0 in reply to jagadish gundavarapu
    Prodigy 65 points

    Thanks .  I'll mark this issue closed for now given the difficulty pinpointing the VECTORS dependency in the SafeTI library.