pppd unaligned trap on Sparc/LEON3

[Cudmore, Alan P. (GSFC-5820)]

Hi Gedare,
I have a fix for the GetMask function. I will have to open a ticket and submit a patch.

I think the VxWorks BSP for the LEON processors provides a trap-and-emulate solution. While I hope that we can eliminate all possible unaligned traps, this would probably be worth adding to the Sparc/LEON BSPs as a safety net. Do any other architectures have this characteristic? RISC-V perhaps?

Thanks,
Alan


From: Gedare Bloom <gedare at rtems.org>
Date: Thursday, March 7, 2019 at 9:34 AM
To: Alan Cudmore <alan.p.cudmore at nasa.gov>
Cc: "rtems-devel at rtems.org" <devel at rtems.org>
Subject: Re: pppd unaligned trap on Sparc/LEON3

Hi Alan,

On Mon, Mar 4, 2019 at 2:34 PM Cudmore, Alan P. (GSFC-5820) <alan.p.cudmore at nasa.gov<mailto:alan.p.cudmore at nasa.gov>> wrote:
I’m trying to get PPP working on SPARC/LEON3. I’m currently using RTEMS 4.11, but plan on switching to 5.x soon.

While handshaking with a Linux PPP client, the LEON3 gets an unaligned memory trap in the GetMask function:
https://git.rtems.org/rtems/tree/cpukit/pppd/sys-rtems.c?h=4.11#n1299<https://urldefense.proofpoint.com/v2/url?u=https-3A__git.rtems.org_rtems_tree_cpukit_pppd_sys-2Drtems.c-3Fh-3D4.11-23n1299&d=DwMFaQ&c=ApwzowJNAKKw3xye91w7BE1XMRKi2LN9kiMk5Csz9Zk&r=mW-jVVDIxBn4bZU1jogCo9FDuDuPszsoVj1mqBvCXzw&m=a-5Jn4TUL71hPUF7ssGxSxyYDAOvUQ_1D8wccpyZGSw&s=YF0LtbDNlIH1_t9mK3JmmGTp0EfdlvBOfGCWLXC46PQ&e=>
The second network interface returned by the ioctl(SIOGIFCONF) call is not aligned on a 4 byte boundary, so the pointer de-reference causes the trap.

It looks like this was referenced in ticket 1401:
https://devel.rtems.org/ticket/1401<https://urldefense.proofpoint.com/v2/url?u=https-3A__devel.rtems.org_ticket_1401&d=DwMFaQ&c=ApwzowJNAKKw3xye91w7BE1XMRKi2LN9kiMk5Csz9Zk&r=mW-jVVDIxBn4bZU1jogCo9FDuDuPszsoVj1mqBvCXzw&m=a-5Jn4TUL71hPUF7ssGxSxyYDAOvUQ_1D8wccpyZGSw&s=M-C8KcV0uNFqCEid52etDmlQp2za5jDBKE0EGR-FjLM&e=>
NOTE: the caller, when unpacking the
sequence of ifreqs is likely to encounter
the same problem (see separate bug report
filed for pppd)

I could not find that ticket for pppd. Did anyone try to create a fix for this?
Is the best approach to try to fix the pppd GetMask function to avoid unaligned accesses?

Yes, the best approach would seem to be coercing the value into an aligned reference and then extracting the bits you want to get.

A general solution could also be to implement trap-and-emulate for unaligned data accesses. I started writing code like this (about 5 years ago!), it is about 20-30 hours of coding/testing to be confident about the result.  Existing code is available in netbsd for deriving the exception handler, so most of the effort is to extract, simplify, refactor, and test that code in rtems-sparc.

Gedare


Thanks,
Alan

_______________________________________________
devel mailing list
devel at rtems.org<mailto:devel at rtems.org>
http://lists.rtems.org/mailman/listinfo/devel<https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.rtems.org_mailman_listinfo_devel&d=DwMFaQ&c=ApwzowJNAKKw3xye91w7BE1XMRKi2LN9kiMk5Csz9Zk&r=mW-jVVDIxBn4bZU1jogCo9FDuDuPszsoVj1mqBvCXzw&m=a-5Jn4TUL71hPUF7ssGxSxyYDAOvUQ_1D8wccpyZGSw&s=IZvWcuM0TV7PLsirOiYGN1uWKG5co9mZWM21xvPfJt8&e=>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20190307/363aef48/attachment-0002.html>