He states the fundamental problem is he wants to muck with hardware he
does not own! Sorry after having once had the terrible experience of
trying to track down a bug which turned out to be not in my drivers, but
because a firm created crap like this, I for one never want to see
people pull this shit.
> Hmm … OK, it looks like the fundamental problem you’re trying to solve is that your HW doesn’t like to be touched unless it’s ready to be touched [smile] … > > Rather than fiddle with the OS to try to halt any/ all accesses (which will cause all manner of other problems with the other parts of the OS and any other hardware that’s less sensitive than yours) I’d suggest instead seeing if there’s something to be done with your hardware, specifically using a kind of call gate approach … > > For instance, suppose that there is a state engine in HW that runs that can’t handle any activity until the state engine completes. For a simple call gate mechanism, designate one register as Hardware, another register as Driver and a third register as OperationPending. These act as gates: when the HW is ready to do something then then HW sets H, D and OP low. When the driver (which is the only device capable of accessing the HW on the bus, yes?) wants to start the HW state engine then it checks to see if D and OP are low, if they are then it sets D and waits for the HW to set OP high and D low. Once the driver sees that OP is high then the driver touches the sensitive parts of the HW and things progress until the HW is back to it’s comfortable place and clears the OP register. The reverse is also true; when the HW wants to communicate with the driver then it sets the H register high and the driver sets OP high when it’s ready to talk to HW. Sensitive parts are touched, the driver sets H low and the HW then sets the OP register low … > > This way HW is protected from multiple partners touching it, you don’t cripple the rest of the ecosystem and all is well … > > As Doron mentioned, is this the problem you’re attempting to solve? If not, then what? > > Cheers!
a) I agree, fiddling with someone elses HW is a *bad* thing, b) there’s nothing that can really be done to prevent that once you’re at driver level and c) he might be using the declarative noun “their” rather than the nominative form you’re thinking of.
Fundamentally, if the OP is attempting to fiddle with someone elses HW then that’s something doomed to fail, period – I can write a driver that will attach to my Broadcom HW, maybe get some BAR’s in the resource list and a few interrupts, but then what? Start poking addresses and see what happens? [smile]
If anything, the OP’s question poses an interesting challenge for HW – how *do* you verify that that thing talking to your BAR is your driver and not some spoofer? What I think I’ll do in my designs is have a simply challenge/ response: given the serial number in the device (all of my devices, USB or PCIe, have unique serials) have the driver apply a transform to this number upon startup and write the result to a specific location in the BAR. When the HW gets an operation from the driver that could be bad it checks this transformed number and if it’s the right value then the write goes through, otherwise the HW rejects it … hmm, to the lab!
I agree with you, it could over write the registers what the other process has configured, but i have some mechanism to handle this stuff and most of the case the device status/busy status are read before writing anything to it and stuff like that.
But what i am stuck is, or what i wanted to know is, by using keIpiGeneric call, can i implement some thing like,
the current running CPU will call keIpiGeneric call and this will cause all other processors other than the current running processor to spin on an atomic variable. The variable which will be controlled by the current processor such that it will be made available after the critical section of my application.
But that has a terrible impact on performance. The RIGHT way to do this
is to protect the resource itself. That is, faithfully grab a spinlock
before you access the resource. That way, the only time processors need
to block is when two of them try to access the resource at the same time.
I know it is possible to do similar things in Linux, if not possible with KeIpiGenericCall, is there any other mechanism to do this?
Many things that are possible in Linux are implemented in the wrong
way. The scheme you’re talking about does not scale. I’m doing
telemetry on a machine with 24 cores. I don’t ever want you to bring
the whole machine to a complete halt.
–
Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.
Unless you have some kind of PKI implementation in your hardware, it’s
always going to be trivial to spoof. Not that there’s any monetary
incentive to spoof it, which is often the motivation for figuring out how to
spoof it. It would certainly prevent whatever nonsense the OP seems to want
to achieve, as long as he was just blindly poking and peeking registers.
You might want to ensure that your state machine is unaffected by someone
doing what the OP wants to do, or there’s a potential for DOS attack.