On Fri, Jun 18, 2021 at 09:15:31AM -0600, Todd C. Miller wrote:
> On Tue, 15 Jun 2021 20:22:53 -0500, Scott Cheloha wrote:
>
> > After that is committed, I'm unclear whether alarm(3) can fail anymore
> > on OpenBSD. The only remaining plausible failure case I can see is
> > EFAULT. But I'm unsure if that's possible. Can we get an EFAULT if
> > both arguments point to stack memory?
>
> I don't think it is possible for alarm(3) to fail in this case.
> The only way I see it failing is if the stack gets corrupted. I
> think we can just initialize oitv to { 0 } and ignore the setitimer()
> return value.
Can we abort if setitimer(2) fails? Or is that too extreme? I know
we're not supposed to leave land mines in libc, but in this case we're
be saying "if this fails then the program state is very screwed up".
I know we do that in a couple spots in libc.
... at minimum we can remove the pointer itp from the stack. It
doesn't serve any purpose.
Index: alarm.c
===================================================================
RCS file: /cvs/src/lib/libc/gen/alarm.c,v
retrieving revision 1.9
diff -u -p -r1.9 alarm.c
--- alarm.c 28 Jun 2019 13:32:41 -0000 1.9
+++ alarm.c 18 Jun 2021 18:06:54 -0000
@@ -29,19 +29,20 @@
*/
#include <sys/time.h>
+
+#include <stdlib.h>
#include <unistd.h>
unsigned int
alarm(unsigned int secs)
{
- struct itimerval it, oitv;
- struct itimerval *itp = ⁢
+ struct itimerval itv, oitv;
- timerclear(&itp->it_interval);
- itp->it_value.tv_sec = secs;
- itp->it_value.tv_usec = 0;
- if (setitimer(ITIMER_REAL, itp, &oitv) == -1)
- return ((unsigned int) -1);
+ timerclear(&itv.it_interval);
+ itv.it_value.tv_sec = secs;
+ itv.it_value.tv_usec = 0;
+ if (setitimer(ITIMER_REAL, &itv, &oitv) == -1)
+ abort();
if (oitv.it_value.tv_usec)
oitv.it_value.tv_sec++;
return (oitv.it_value.tv_sec);
