On 2011-05-10 16:36, Dave Howorth wrote:
> PsychoGTI wrote:
>> robin_listas;2337270 Wrote:

>> So, the fact that /dev/.udev/watch is being opened is causing watchdog
>> to expect some data input. Thereby causing the reboot. I did explain to
>> them that this version of AVG seems to work well in older Suse versions,
>> but they seemed to ignore that.

Perhaps because the watchdog code was not there, or not started by default.

> This has piqued my interest, because it seems very fragile. I'd like to
> discover the *facts*. For example, in Greg KH's first response to the
> bugzilla, he says:
>> Looks like this program doesn't know what it is doing at all, randomly
>> running through all the stuff in the device tree and opening it up.
>> That's broken.

That is true. The scanner should not open files marked as devices. This is
a huge error on the part of AVG. Unbelievable.

>> Please file a bug with the virus program, not much we can do here if a
>> root program decides to open all devices in a system and randomly
>> write to them.

I don't think it writes anything.

> Now I have huge respect for Greg, and I know next to nothing in this
> area, but:
> (1) Is it really policy that you're not allowed to open devices
> (read-only)? And that doing so can crash the machine?

Policy, policy... the policy will depend, IMO, on the particular device.
You would have to read its documentation in the kernel code.

> (2) I haven't seen any evidence that AVG is *writing* to devices, and I
> wouldn't expect any virus scanner to write to the filesystem it is
> scanning! Have I missed something somewhere or is that FUD?

No, he probably doesn't know that antivirus do not write when scanning. Not
his field ;-)

> His second response says:
>> On the contrary, if a userspace program opens a watchdog device node,
>> and doesn't write the proper data to it, at the proper time intervals,
>> then the watchdog will trigger, that is how the kernel driver is
>> supposed to work.

That does make sense.

>> So it looks like the kernel is actually working properly here, and
>> again, the virus code needs to be fixed to not do this.

> The first para describes very fragile behaviour, since the consequence
> of innocent misbehaviour is a crash. It would seem pretty easy to define
> the interface so that either or both:
> (a) opening for reading didn't take possession of the watchdog
> (b) opening for writing requires an initial write of some value to show
> the correct protocol is understood and being followed, and results in an
> error being logged if not so.

Probably the watchdog code interface is simple. Opening the field
activates, then you are supposed to write periodically. Two operations
supported only.

Otherwise, you could complicate things with writing control codes
"somewhere" to start the watchdog. I don't know how this is done, if you
can write control things to the same device, or you need another device for
control, different than the one for data. That's out of the scope of my
educated guesses :-)

You know the saying that everything in Linux is a file - but that has
limitations. You can read and write to a file. Also position the pointer.
Not much more. So the watchdog apparently has two operations: open: start.
Write, to reload the counter. And probably close, to stop it.

Anything done to a device file is not "innocent" :-)

It isn't, and AVG is at fault here. They should not open ANY device at all.

> So I'd like to find some answers to my puzzlement. I've found
> <http://git.kernel.org/?p=linux/kernel/git/wim/linux-2.6-watchdog.git;a=blob_plain;f=drivers/watchdog/iTCO_wdt.c;hb=HEAD>
> <http://download.intel.com/design/chipsets/applnots/29227301.pdf>
> <http://www.mjmwired.net/kernel/Documentation/watchdog/watchdog-api.txt>

Hummm, too busy to read that lot now...

> But I still fail to understand what happens. One system I have is
> running iTCO_wdt: Intel TCO WatchDog Timer Driver v1.05 but it doesn't
> have a /dev/watchdog, just lots of non-existent links in
> /dev/.udev/watch (as seen in the error messages from the AVG scanner).
> But I daren't probe those links as root (it's an operational server!)
> and probing them as non-root hasn't caused any problems so far.

No no, don't :-)

> Does anybody know of any other documentation that explains things?

My educated guess is that Greg is right.

Cheers / Saludos,

Carlos E. R.
(from 11.2 x86_64 "Emerald" at Telcontar)