[lm-sensors] [RFC] Support of chassis intrusion detection

[lm-sensors] [RFC] Support of chassis intrusion detection

[Jean Delvare]

Hi all,

A number of users have asked us to support the chassis intrusion
detection feature which some hardware monitoring chip have. I've
created a ticket for this:
http://www.lm-sensors.org/ticket/2370
Here is a proposal.

sysfs interface
=======
chassis_intrusion
		Chassis intrusion detection
		0: OK
		1: intrusion detected
		RW
		Writing 0 clears the detection flag.
		Writing other values is unsupported.

It's not totally clear whether clearing should be done by writing 0 or
1. 0 is more respectful of traditional sysfs semantics that you should
be able to read back what you just wrote, so it has my vote.

drivers
===
Drivers adm9240, w83792d and w83793 implement this feature in
non-standard ways. They should be converted to the new, standard
interface.

libsensors
=====

Either

SENSORS_FEATURE_CHASSIS_INTRUSION = 0x19
SENSORS_SUBFEATURE_CHASSIS_INTRUSION = SENSORS_FEATURE_CHASSIS_INTRUSION << 8

or rename SENSORS_FEATURE_BEEP_ENABLE to SENSORS_FEATURE_MISC and

SENSORS_SUBFEATURE_BEEP_ENABLE = SENSORS_FEATURE_MISC << 8
SENSORS_SUBFEATURE_CHASSIS_INTRUSION = (SENSORS_FEATURE_MISC << 8) + 1

sensors
===
Reading the value of the chassis intrusion detection subfeature is done
like for any other subfeature.

Writing, OTOH, can't be handled the same as writing limits, because we
certainly don't want to clear the flag automatically at lm_sensors
start or restart time. So we could add a dedicated flag to clear the
chassis intrusion detection flag (e.g. "sensors --clear-chassis").

If anyone has objections or comments, please speak up.

-- 
Jean Delvare

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] [RFC] Support of chassis intrusion detection

[Matt Roberds]

On Tue, 17 Feb 2009, Jean Delvare wrote:
> sysfs interface
> =======>
> chassis_intrusion
> 		Chassis intrusion detection

Will the full name be something like chassis_intrusion0 (or .0 or -0) by
default, with the possibility for more (...sion1 or .1 or -1) later?  As
far as I can remember, I've only ever seen one bit of chassis intrusion
detection per computer, but if it doesn't cost much, it might be nice to
allow for expansion.

> sensors
> ===>
> [...] So we could add a dedicated flag to clear the chassis intrusion
> detection flag (e.g. "sensors --clear-chassis").

Are there any security implications here?  I am talking more about
physical security (somebody stealing a stick of RAM) more than computer
security (somebody getting root).  Do we want to somehow limit who can
clear the chassis intrusion flag?  On the other hand, a malicious user
can cause damage with the current code by (for example) shutting down
or slowing the fans, or deliberately setting voltage limits too low or
too high (to cause a monitoring daemon to reboot the system or
whatever).  So letting someone reset the chassis intrusion flag may not
be that big a deal.

Do the APM or ACPI specs say anything about how software is supposed to
deal with chassis intrusion, or do they just say "a hardware chassis
intrusion flag exists", or do they not care?  I know lm-sensors is not
ACPI, but if there is already some kind of standard, it might be good to
follow it.

Are there any problems availability of this feature "early" in the boot
process?  Somebody who is really paranoid might want to stop booting, or
take some other action, if the intrusion flag is on.  I think that
people who care about this mostly do it before the regular OS kernel
starts to load, though.  Either they tell the BIOS to treat intrusion as
an error and require a password to get past the "error, hit F1 to
continue" prompt that the BIOS puts up, or maybe they network boot a
small program over PXE that looks at the intrusion flag, dispatches the
SWAT team if required, and then boots the regular OS from the local hard
drive.

With parallel ports going away, eventually somebody is going to use the
chassis intrusion flag as a one-bit, relatively low speed digital input
pin.  I don't think there is any action for lm-sensors here other to
recognize the question when somebody asks about it.

Matt Roberds


_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] [RFC] Support of chassis intrusion detection

[Jean Delvare]

Hi Matt,

On Wed, 18 Feb 2009 07:20:34 -0600 (CST), Matt Roberds wrote:
> On Tue, 17 Feb 2009, Jean Delvare wrote:
> > sysfs interface
> > =======> >
> > chassis_intrusion
> > 		Chassis intrusion detection
> 
> Will the full name be something like chassis_intrusion0 (or .0 or -0) by
> default, with the possibility for more (...sion1 or .1 or -1) later?  As
> far as I can remember, I've only ever seen one bit of chassis intrusion
> detection per computer, but if it doesn't cost much, it might be nice to
> allow for expansion.

This is a good point, I've been thinking about it. The question is,
what point would there be in having more than one chassis intrusion
detector? If the case has been opened, you can't trust the system, no
matter how it has been opened. So even if there are several sensors,
merging them into a single information bit (either in hardware or
software) seems to make sense.

The only situation where this could make a difference is if a computer
case has several internal compartments, isolated from each other, so
depending on what exactly was opened, the intruder would have access to
different parts. But honestly, I've never seen any computer case like
this, and I fail to see the point of building such cases. So at this
point I don't think we have to handle multiple chassis_intrusion
entries in sysfs.

> 
> > sensors
> > ===> >
> > [...] So we could add a dedicated flag to clear the chassis intrusion
> > detection flag (e.g. "sensors --clear-chassis").
> 
> Are there any security implications here?  I am talking more about
> physical security (somebody stealing a stick of RAM) more than computer
> security (somebody getting root).  Do we want to somehow limit who can
> clear the chassis intrusion flag?

Of course we want. Only root will be allowed to run "sensors
--clear-chassis". Same as "sensors -s" today.

>                                   On the other hand, a malicious user
> can cause damage with the current code by (for example) shutting down
> or slowing the fans, or deliberately setting voltage limits too low or
> too high (to cause a monitoring daemon to reboot the system or
> whatever).

No, users can't do that, thankfully. Unless the admin is stupid enough
to suid the sensors binary, but then what can we do...

>             So letting someone reset the chassis intrusion flag may not
> be that big a deal.
> 
> Do the APM or ACPI specs say anything about how software is supposed to
> deal with chassis intrusion, or do they just say "a hardware chassis
> intrusion flag exists", or do they not care?  I know lm-sensors is not
> ACPI, but if there is already some kind of standard, it might be good to
> follow it.

APM is so old that I doubt we want to care about it at all. I couldn't
even find a PDF of the specification, only a RTF, that says a lot
doesn't it? And I'm not sure why a power management specification would
have anything to do with chassis intrusion.

ACPI v2 doesn't say anything about chassis intrusion as far as I can
see.

> Are there any problems availability of this feature "early" in the boot
> process?  Somebody who is really paranoid might want to stop booting, or
> take some other action, if the intrusion flag is on.  I think that
> people who care about this mostly do it before the regular OS kernel
> starts to load, though.  Either they tell the BIOS to treat intrusion as
> an error and require a password to get past the "error, hit F1 to
> continue" prompt that the BIOS puts up, or maybe they network boot a
> small program over PXE that looks at the intrusion flag, dispatches the
> SWAT team if required, and then boots the regular OS from the local hard
> drive.

In the typical case of modular drivers, we can't provide the feature
before the lm_sensors service is started, which is by definition late
in the boot process (root file system is already mounted.)
Distributions may still want to check it at this point in time and for
example fallback to runlevel 2 if an intrusion has been detected. But I
agree that anyway this is something that should be checked earlier,
before the OS is started.

> With parallel ports going away, eventually somebody is going to use the
> chassis intrusion flag as a one-bit, relatively low speed digital input
> pin.  I don't think there is any action for lm-sensors here other to
> recognize the question when somebody asks about it.

Whatever you drink in the morning... please consider changing that ;)

Thanks,
-- 
Jean Delvare

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] [RFC] Support of chassis intrusion detection

[Jean Delvare]

Hi Fred,

Once again I would like to ask you to reply to the list and not to me
only. This is especially important for a RFC!

On Wed, 18 Feb 2009 00:33:40 +0100, Fred . wrote:
> I am very pleased to see that you wrote a RFC. Good job.
> I am not qualified enough to state in my opinion, but it looks pretty
> good to me.
> 0 to clear the detection flag seems good to me.
> 
> A (not necessarily good) idea. If you could trigger the detection by writing to
> the file, then people who do not own a case which supports chassis intrusion,
> could still write and test scripts that works with lm-sensors.

I see your point, but I don't think I want to allow this. If the
intrusion alarm can be triggered in software, this opens the door to
false positives and exploits. This would also require extra code in all
drivers, because the sysfs file will reflect the value of a hardware
bit, which can typically be cleared by software but _not_ set by
software. Making each driver more complex only for testing purposes
doesn't sound right.

If people want to test the functionality without the hardware, the
right way to do that is using the i2c-stub driver together with an
i2c-based hwmon driver which implements the feature in question. This
is already in place and should work nicely.

> To play the devils advocate, one may argue that since temperature sensors
> are called temp1, temp2, etc and not cpu_temp, gpu_temp, then it ought to
> be called just 'intrusion' instead of 'chassis_intrusion'.

Good point. Now, the question is, is there anything else than the
chassis that can suffer from intrusion? Racked hard disks maybe? I
don't have access to high-end server hardware so I admit I don't really
know.

If we want to be really generic then we should consider that the
chassis intrusion detectors are merely micro-switches used for a
specific function. So we might as well go with switch0, switch1...
However, intrusion detection switches have semantics attached to them
(in particular the fact that they are set by hardware and cleared by
software.) They also need to be handled differently from other sensor
inputs, as discussed with Matt. "sensors --clear-chassis" (or maybe
--clear-intrusion would be preferable?) must know which chip feature it
has to access, something which being too generic will make impossible.

> You earlier mentioned keeping in mind extendibility, such as multple sensors,
> in which case it ought to be named chassis_intrusion0, chassis_intrusion1, etc.

See my reply to Matt.

> Though, I do agree with you that a 'chassis_intrusion' is a good name.
> It is very simple, clear and non confusing.
> 
> Realistically speaking, no case is ever likely to have more than one sensors,
> also I don't think any Super-I/O supports more than one sensor.

That's what I think too.

> Though, theoretically someone might have a third-party sensor on a PCI card,
> or on a USB device.

For an internal device the limitation is the number of switches on the
case itself. So I guess such a device would replace, not add to, the
one already present on the motherboard (if any).

Chassis intrusion detection on an external device is, hmm... Not
technically impossible, but I'm not sure what sense it makes from the
system's point of view. The intruder could connect the device to
another system, reset the intrusion alarm, and reconnect the device.

> Either way, I think your RFC is "down to earth" and it looks good.

Thanks,
-- 
Jean Delvare

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] [RFC] Support of chassis intrusion detection

[Hans de Goede]

Jean Delvare wrote:
> Hi all,
> 
> A number of users have asked us to support the chassis intrusion
> detection feature which some hardware monitoring chip have. I've
> created a ticket for this:
> http://www.lm-sensors.org/ticket/2370
> Here is a proposal.
> 
> sysfs interface
> =======> 
> chassis_intrusion
> 		Chassis intrusion detection
> 		0: OK
> 		1: intrusion detected
> 		RW
> 		Writing 0 clears the detection flag.
> 		Writing other values is unsupported.
> 
> It's not totally clear whether clearing should be done by writing 0 or
> 1. 0 is more respectful of traditional sysfs semantics that you should
> be able to read back what you just wrote, so it has my vote.
> 
> drivers
> ===> 
> Drivers adm9240, w83792d and w83793 implement this feature in
> non-standard ways. They should be converted to the new, standard
> interface.
> 
> libsensors
> =====
> 
> Either
> 
> SENSORS_FEATURE_CHASSIS_INTRUSION = 0x19
> SENSORS_SUBFEATURE_CHASSIS_INTRUSION = SENSORS_FEATURE_CHASSIS_INTRUSION << 8
> 
> or rename SENSORS_FEATURE_BEEP_ENABLE to SENSORS_FEATURE_MISC and
> 
> SENSORS_SUBFEATURE_BEEP_ENABLE = SENSORS_FEATURE_MISC << 8
> SENSORS_SUBFEATURE_CHASSIS_INTRUSION = (SENSORS_FEATURE_MISC << 8) + 1
> 
> sensors
> ===> 
> Reading the value of the chassis intrusion detection subfeature is done
> like for any other subfeature.
> 
> Writing, OTOH, can't be handled the same as writing limits, because we
> certainly don't want to clear the flag automatically at lm_sensors
> start or restart time. So we could add a dedicated flag to clear the
> chassis intrusion detection flag (e.g. "sensors --clear-chassis").
> 
> If anyone has objections or comments, please speak up.
> 

looks good to me, but I wonder if we should not prepare for the case where an 
IC has more then one chasis intrusion detection pin.

Regards,

Hans

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] [RFC] Support of chassis intrusion detection

[Jean Delvare]

On Thu, 19 Feb 2009 10:37:33 +0100, Hans de Goede wrote:
> Jean Delvare wrote:
> > Hi all,
> > 
> > A number of users have asked us to support the chassis intrusion
> > detection feature which some hardware monitoring chip have. I've
> > created a ticket for this:
> > http://www.lm-sensors.org/ticket/2370
> > Here is a proposal.
> > 
> > sysfs interface
> > =======> > 
> > chassis_intrusion
> > 		Chassis intrusion detection
> > 		0: OK
> > 		1: intrusion detected
> > 		RW
> > 		Writing 0 clears the detection flag.
> > 		Writing other values is unsupported.
> > 

Having thought about it some more, I suspect this won't be sufficient.
This feature is like an alarm flag, which suggests that chips which
support beeping may have a beep control bit for it too. So maybe we
should define:

chassis_intrusion_alarm
chassis_intrusion_beep

I didn't look at all the datasheets yet to find out whether any chip
actually implements this, but this doesn't sound unreasonable.

> > It's not totally clear whether clearing should be done by writing 0 or
> > 1. 0 is more respectful of traditional sysfs semantics that you should
> > be able to read back what you just wrote, so it has my vote.
> > 
> > drivers
> > ===> > 
> > Drivers adm9240, w83792d and w83793 implement this feature in
> > non-standard ways. They should be converted to the new, standard
> > interface.
> > 
> > libsensors
> > =====
> > 
> > Either
> > 
> > SENSORS_FEATURE_CHASSIS_INTRUSION = 0x19
> > SENSORS_SUBFEATURE_CHASSIS_INTRUSION = SENSORS_FEATURE_CHASSIS_INTRUSION << 8
> > 
> > or rename SENSORS_FEATURE_BEEP_ENABLE to SENSORS_FEATURE_MISC and
> > 
> > SENSORS_SUBFEATURE_BEEP_ENABLE = SENSORS_FEATURE_MISC << 8
> > SENSORS_SUBFEATURE_CHASSIS_INTRUSION = (SENSORS_FEATURE_MISC << 8) + 1
> > 
> > sensors
> > ===> > 
> > Reading the value of the chassis intrusion detection subfeature is done
> > like for any other subfeature.
> > 
> > Writing, OTOH, can't be handled the same as writing limits, because we
> > certainly don't want to clear the flag automatically at lm_sensors
> > start or restart time. So we could add a dedicated flag to clear the
> > chassis intrusion detection flag (e.g. "sensors --clear-chassis").
> > 
> > If anyone has objections or comments, please speak up.
> > 
> 
> looks good to me, but I wonder if we should not prepare for the case where an 
> IC has more then one chasis intrusion detection pin.

The same question has been raised by other reviewers already. I am
shared between simplicity (we've never seen a system with more than
one, and there is no obvious scenario) and completeness (who knows...)

The point which makes me reluctant to go for multiple inputs is how we
are going to handle clearing them with "sensors". Should "sensors
--clear-intrusion" clear them all? Or do we need to provide a parameter
specifying which intrusion detector needs to be cleared? The latter
seems somewhat overkill in the usual case of a single chassis intrusion
detector. If we go for the former, we have less control but then
supporting multiple intrusion detectors is cheap.

-- 
Jean Delvare

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] [RFC] Support of chassis intrusion detection

[Matt Roberds]

On Wed, 18 Feb 2009, Jean Delvare wrote:
> On Wed, 18 Feb 2009 07:20:34 -0600 (CST), Matt Roberds wrote:

> The question is, what point would there be in having more than one
> chassis intrusion detector?

This is only hypothetical - I haven't seen a case with more than one
switch.  Having said that: I *have* used a rackmount server case that had
a lockable door on the front that covered the drive bays.  If you wanted
to add or remove hardware, though, you had to slide the case out of the
rack on its rails, and remove the top of the case.  I could see somebody
wanting to have two switches: one on the drive bay door and one on the
top.  In normal operation, maybe somebody comes along every so often and
swaps a CD/DVD or something, so you want a notification or maybe a
warning when the drive bay door is open.  But nobody is supposed to be
taking the top off of the case, so you want to scream and stop the world
when the top of the case is open.  (On the other hand, who switches
disks anymore?  Get your updates from the network, and have a backup
server instead of local backups.)

>> Do the APM or ACPI specs say anything about how software is supposed
>> to deal with chassis intrusion, or do they just say "a hardware
>> chassis intrusion flag exists", or do they not care?
>
> APM is so old that I doubt we want to care about it at all.

ISA dates to 1980-1981 and we still have to look for sensors there.  :)

> And I'm not sure why a power management specification would have
> anything to do with chassis intrusion.

As far as I remember, power management stuff started showing up in the
BIOS / on motherboards at around the same time as chassis intrusion
detection did.  I thought maybe that was because intrusion was part of
the specification.

In a later message, you wrote:

> The point which makes me reluctant to go for multiple inputs is how
> we are going to handle clearing them with "sensors". Should "sensors
> --clear-intrusion" clear them all? Or do we need to provide a
> parameter specifying which intrusion detector needs to be cleared?

Is it possible for sensors to know how many there are?  That way, if
there's just one, "sensors --clear-intrusion" just clears that one,
but if there's more than one, it says "error: which one do you want?"
Or maybe --clear-intrusion, by default, always clears the "first"
sensor found, only clearing a different one if given an argument.
(This might lead to surprises if the sensors get enumerated in a
different order with a reboot or new driver or whatever.)

Back to the first message:

>> With parallel ports going away, eventually somebody is going to use
>> the chassis intrusion flag as a one-bit, relatively low speed digital
>> input pin.
>
> Whatever you drink in the morning... please consider changing that ;)

I tried to get something stronger, but the guy at the store mumbled
something about azeotropes.  Not sure what the problem is there.  :)

Matt Roberds


_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] [RFC] Support of chassis intrusion detection

[Jean Delvare]

Hi Matt,

On Thu, 19 Feb 2009 07:00:23 -0600 (CST), Matt Roberds wrote:
> On Wed, 18 Feb 2009, Jean Delvare wrote:
> > On Wed, 18 Feb 2009 07:20:34 -0600 (CST), Matt Roberds wrote:
> 
> > The question is, what point would there be in having more than one
> > chassis intrusion detector?
> 
> This is only hypothetical - I haven't seen a case with more than one
> switch.  Having said that: I *have* used a rackmount server case that had
> a lockable door on the front that covered the drive bays.  If you wanted
> to add or remove hardware, though, you had to slide the case out of the
> rack on its rails, and remove the top of the case.  I could see somebody
> wanting to have two switches: one on the drive bay door and one on the
> top.  In normal operation, maybe somebody comes along every so often and
> swaps a CD/DVD or something, so you want a notification or maybe a
> warning when the drive bay door is open.  But nobody is supposed to be
> taking the top off of the case, so you want to scream and stop the world
> when the top of the case is open.  (On the other hand, who switches
> disks anymore?  Get your updates from the network, and have a backup
> server instead of local backups.)

That's an interesting scenario, thanks for pointing it out. This
probably justifies that we go for intrusion0_alarm instead of
chassis_intrusion_alarm.

> (...)
> > The point which makes me reluctant to go for multiple inputs is how
> > we are going to handle clearing them with "sensors". Should "sensors
> > --clear-intrusion" clear them all? Or do we need to provide a
> > parameter specifying which intrusion detector needs to be cleared?
> 
> Is it possible for sensors to know how many there are?

Yes, with a non-trivial amount of code. Currently, sensors processes
inputs on the fly. If we want to change its behavior based on the
number of inputs of a given type, we either have to do two passes, or
we have to store the values first, then decide, and then do something
with the values.

> (...) That way, if
> there's just one, "sensors --clear-intrusion" just clears that one,
> but if there's more than one, it says "error: which one do you want?"

We could indeed do that. We would have to come up with a way to
uniquely identify each inputs, but this can be done (and would be
needed for other reasons anyway.)

> Or maybe --clear-intrusion, by default, always clears the "first"
> sensor found, only clearing a different one if given an argument.

I am not a big fan of optional arguments to command line parameters.
These tend to make command lines ambiguous.

> (This might lead to surprises if the sensors get enumerated in a
> different order with a reboot or new driver or whatever.)

Well, there are two different possibilities here: two chips each with
one intrusion detection input, and one chip with two intrusion
detection inputs. In the former case, the order might indeed change,
which is why I mentioned the need for a way to uniquely identify
inputs. In the latter case, the order will never change for a given
chip, however it could change from one chip to the next, which could be
inconvenient for admins.

All in all this discussion tends to underline the lack of uniform way
to query sensor information from one board to the next. But this is a
vast problem, to be solved later.

Note that my idea of "sensors --clear-intrusion" is what came out of my
mind first, but this might not be the best idea. Maybe we instead want
to have a dedicated tool for reporting and clearing intrusions. Or have
both: "sensors --clear-intrusion" clears all flags and is meant for the
simple cases, and if we need something finer-grained we write a
dedicated tool.

-- 
Jean Delvare

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors

Re: [lm-sensors] [RFC] Support of chassis intrusion detection

[Hans de Goede]

Jean Delvare wrote:
> On Thu, 19 Feb 2009 10:37:33 +0100, Hans de Goede wrote:
>> Jean Delvare wrote:
>>> Hi all,
>>>
>>> A number of users have asked us to support the chassis intrusion
>>> detection feature which some hardware monitoring chip have. I've
>>> created a ticket for this:
>>> http://www.lm-sensors.org/ticket/2370
>>> Here is a proposal.
>>>
>>> sysfs interface
>>> =======>>>
>>> chassis_intrusion
>>> 		Chassis intrusion detection
>>> 		0: OK
>>> 		1: intrusion detected
>>> 		RW
>>> 		Writing 0 clears the detection flag.
>>> 		Writing other values is unsupported.
>>>
> 
> Having thought about it some more, I suspect this won't be sufficient.
> This feature is like an alarm flag, which suggests that chips which
> support beeping may have a beep control bit for it too. So maybe we
> should define:
> 
> chassis_intrusion_alarm
> chassis_intrusion_beep
> 
> I didn't look at all the datasheets yet to find out whether any chip
> actually implements this, but this doesn't sound unreasonable.
> 
>>> It's not totally clear whether clearing should be done by writing 0 or
>>> 1. 0 is more respectful of traditional sysfs semantics that you should
>>> be able to read back what you just wrote, so it has my vote.
>>>
>>> drivers
>>> ===>>>
>>> Drivers adm9240, w83792d and w83793 implement this feature in
>>> non-standard ways. They should be converted to the new, standard
>>> interface.
>>>
>>> libsensors
>>> =====
>>>
>>> Either
>>>
>>> SENSORS_FEATURE_CHASSIS_INTRUSION = 0x19
>>> SENSORS_SUBFEATURE_CHASSIS_INTRUSION = SENSORS_FEATURE_CHASSIS_INTRUSION << 8
>>>
>>> or rename SENSORS_FEATURE_BEEP_ENABLE to SENSORS_FEATURE_MISC and
>>>
>>> SENSORS_SUBFEATURE_BEEP_ENABLE = SENSORS_FEATURE_MISC << 8
>>> SENSORS_SUBFEATURE_CHASSIS_INTRUSION = (SENSORS_FEATURE_MISC << 8) + 1
>>>
>>> sensors
>>> ===>>>
>>> Reading the value of the chassis intrusion detection subfeature is done
>>> like for any other subfeature.
>>>
>>> Writing, OTOH, can't be handled the same as writing limits, because we
>>> certainly don't want to clear the flag automatically at lm_sensors
>>> start or restart time. So we could add a dedicated flag to clear the
>>> chassis intrusion detection flag (e.g. "sensors --clear-chassis").
>>>
>>> If anyone has objections or comments, please speak up.
>>>
>> looks good to me, but I wonder if we should not prepare for the case where an 
>> IC has more then one chasis intrusion detection pin.
> 
> The same question has been raised by other reviewers already. I am
> shared between simplicity (we've never seen a system with more than
> one, and there is no obvious scenario) and completeness (who knows...)
> 
> The point which makes me reluctant to go for multiple inputs is how we
> are going to handle clearing them with "sensors". Should "sensors
> --clear-intrusion" clear them all? Or do we need to provide a parameter
> specifying which intrusion detector needs to be cleared? The latter
> seems somewhat overkill in the usual case of a single chassis intrusion
> detector. If we go for the former, we have less control but then
> supporting multiple intrusion detectors is cheap.
> 

IMHO: Just make it clear all, if someone really wants to clear only one he can 
use echo 0 > /sys/....

Regards,

Hans

_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors