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]
Message-ID: <20111207172311.37b3358a@lxorguk.ukuu.org.uk>
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/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ