Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

IF* instructions have a reliability/security downside #39

Open
Zardoz89 opened this issue Jan 1, 2015 · 3 comments
Open

IF* instructions have a reliability/security downside #39

Zardoz89 opened this issue Jan 1, 2015 · 3 comments

Comments

@Zardoz89
Copy link
Member

Zardoz89 commented Jan 1, 2015

IF* instructions have a reliability/security downside. Malicious code may contain long sequences of IF* instructions and thus sabotage interrupt servicing. Non-malicious code can introduce jitter into interrupt handling. Texas Instruments' TMS320C54 series had the same issue with its repeated multiply-accumulate instructions (they are used to implement FIR filters and can be repeated up to some 512-1024 times). I'd rather avoid this. If you could at least impose a limit onto how many IF* instructions can appear one after the other or if you could allow interrupts after some number of IF* instructions, it would alleviate the problem. Still, it's not nice, IMO.

  • By Alexey (SmallerC author)

I think that imposing a limit onto how many IF* instructions could be chained would be ok. We could set a number like 5 or 6 chained IF*

@milesrout
Copy link
Member

Malicious code can just disable interrupts anyway.

@milesrout milesrout added security and removed bug labels Mar 19, 2015
@Zardoz89 Zardoz89 modified the milestone: v0.5.0 Mar 20, 2015
@milesrout
Copy link
Member

The if-state could be suspended when an interrupt arrives. Not sure if that would be practical on the physical level in a real implementation - I'm not sure if if-chaining would be practical either actually - but it would solve the problem nicely. It would mean that if-chains wouldn't suspend interrupts at all. That's even better.

@milesrout
Copy link
Member

Can close if we remove if-chaining.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants