linux-kernel - Re: [PATCH] RFC, watchdog: add generic wdt driver API

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:	Wed, 7 Dec 2011 17:23:11 +0000
From:	Alan Cox <alan@...rguk.ukuu.org.uk>
To:	hs@...x.de
Cc:	Wolfgang Denk <wd@...x.de>, Wolfram Sang <w.sang@...gutronix.de>,
	linux-watchdog@...r.kernel.org,
	devicetree-discuss@...ts.ozlabs.org, linux-kernel@...r.kernel.org,
	Stefan Roese <sr@...x.de>, Detlev Zundel <dzu@...x.de>
Subject: Re: [PATCH] RFC, watchdog: add generic wdt driver API

>   A chain can request to kill the registering process if the interval
>   elapses.  In this case a restarted process can register with the
>   driver giving the same identifier and reset the chain.  This is the
>   main reason why there is no association between chains and processes
>   or open device files.

How do genuinely unused chains get automatically cleaned up

>   Possible chain actions:
>   - ACTION_SIGNAL: sends a configurable signal to the process
>   - ACTION_KILL: sends the SIGKILL signal to the process

These two are the same (detail)

> starting point to integrate it? As this "chain API" would controlled
> through ioctl() calls maybe drivers/watchdog/watchdog_dev.c would be
> a good place... or a drivers/watchdog/watchdog_chain.c which gets the
> ioctl calls, watchdog_dev.c couldn't parse ...

It doesn't actually seem to have any connection at all with the kernel
watchdog drivers. I don't mean that as a criticism but what you are
describing seems to be some kind of software timer groups.

If you wanted to link it to a real watchdog presumably you'd just put the
watchdog pinging user space process in a group and set it to get killed
if the group triggered.

I'm not sure I understand why it can't be done cleanly in userspace
either.

If you have a daemon accepting unix domain connections then it can get
the pid of the other end and can kill it, or monitor incoming packets and
requests from it. If that process is also the one pinging the hardware
watchdog it can provide reboot protection against its own crashing. It
can also do much more flexible and interesting policy things like only
pinging the watchdog each time all the clients check in.

Alan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/