Open FritzX6 opened 4 years ago
Hey @FritzX6,
Do you know what build version for Catalina 10.15.1 is running on those notebooks?
I am currently mobile, so don't have access to a computer, but will look into it when I do.
I also still don't have access to T2 hardware, and I have yet to upgrade machines to 10.15, so I will need your help debugging it. Do you mind pasting your /usr/libexec/remotectl dumpstate
output? (Feel free to redact/DM me if it contains sensitive information).
(Also, have you tried the query with root privileges?)
Hi @sharvilshah,
Same results with root / regular user.
I don't have a T2 enabled laptop (just the iMac Pro) but have asked @blaedj to paste the output of his /usr/libexec/remotectl dumpstate
for us:
Found localbridge (bridge)
State: connected (connectable)
UUID: REDACTED
Product Type: iBridge2,3
OS Build: 3.6 (16P6571)
Messaging Protocol Version: 1
Heartbeat:
Last successful heartbeat sent 13.649s ago, received 13.645s ago (took 0.004s)
28981 heartbeats sent, 0 received
Properties: {
AppleInternal => false
ChipID => 32786
EffectiveProductionStatusSEP => true
HWModel => J680AP
HasSEP => true
LocationID => REDACTED
RegionInfo => LL/A
EffectiveSecurityModeAp => true
FDRSealingStatus => true
SigningFuse => true
BuildVersion => 16P6571
OSVersion => 3.6
BridgeVersion => 16.16.6571.0.0,0
SensitivePropertiesVisible => true
ProductType => iBridge2,3
BoardRevision => 1
Image4CryptoHashMethod => sha2-384
SerialNumber => REDACTED
BootSessionUUID => 5X30XXX-9XX8-458F-94A5-C1C50X7X68CE
BoardId => 11
EffectiveProductionStatusAp => true
EffectiveSecurityModeSEP => true
UniqueChipID => REDACTED
UniqueDeviceID => REDACTED
RemoteXPCVersionFlags => 72057594037927942
CertificateSecurityMode => true
CertificateProductionStatus => true
ModelNumber => MR942LL/A
RegionCode => LL
InterfaceIndex => 8
HardwarePlatform => t8012
Image4Supported => true
}
Services:
com.apple.sysdiagnose.stackshot.remote
Properties: {
UsesRemoteXPC => true
}
com.apple.nfcd.relay.uart
Properties: {
UsesBridgeXPC => false
}
com.apple.powerchime.remote
Properties: {
UsesRemoteXPC => true
}
com.apple.xpc.remote.multiboot
Properties: {
UsesRemoteXPC => true
}
com.apple.bridgeOSUpdated
Properties: {
UsesRemoteXPC => true
}
com.apple.osanalytics.logTransfer
Properties: {
UsesRemoteXPC => true
}
com.apple.private.avvc.xpc.remote
Properties: {
UsesRemoteXPC => true
}
com.apple.multiverse.remote.bridgetime
com.apple.corecaptured.remoteservice
Properties: {
UsesRemoteXPC => true
}
com.apple.corespeech.xpc.remote.record
Properties: {
UsesRemoteXPC => true
}
com.apple.logd.remote-daemon
com.apple.mobileactivationd.bridge
Version: 1
Properties: {
ServiceVersion => 1
UsesRemoteXPC => true
}
com.apple.corespeech.xpc.remote.control
Properties: {
UsesRemoteXPC => true
}
com.apple.eos.LASecureIO
com.apple.aveservice
Properties: {
UsesRemoteXPC => true
}
com.apple.sysdiagnose.remote
Properties: {
UsesRemoteXPC => true
}
com.apple.internal.xpc.remote.kext_audit
Properties: {
UsesRemoteXPC => true
}
com.apple.eos.BiometricKit
Properties: {
UsesRemoteXPC => false
}
com.apple.icloud.findmydeviced.bridge
Version: 1
Properties: {
ServiceVersion => 1
UsesRemoteXPC => true
}
com.apple.nfcd.relay.control
Properties: {
UsesBridgeXPC => false
}
note that the above output comes from a laptop running macOS 10.14.6
What parts of this table / iBridge information are important? If it is the case that T2 information is difficult to retrieve, I want to make sure we're focused on a real use case.
For example, if the only important information is that the machine has T2, this is simple. If you need the firmware version, it may be significant effort.
Thanks @FritzX6 and @blaedj!
Are you aware if this is this an issue on T2 machines running 10.14, or just on 10.15? Trying to narrow it down.
In any case, I will try to carve out sometime over the weekend to look into this.
@theopolis That is a good compromise, if we can't make any progress.
The version information is important. For example, we've encountered issues with devices which are running beta versions of Bridge OS, such as from an early Catalina beta, when running an older operating system like 10.14.6. Finding these outliers with a table like this makes debugging much easier!
I read https://duo.com/labs/research/apple-t2-xpc and browsed all of the ioreg
properties on my T2 macbook last night and did not see an alternative to querying the firmware version. This is what makes me weary.
we've encountered issues with devices which are running beta versions of Bridge OS, such as from an early Catalina beta, when running an older operating system like 10.14.6. Finding these outliers with a table like this makes debugging much easier!
That's a good use case. In this scenario @keeleysam could the OS version (10.14.6) have been an indicator or were there multiple iBridge firmware versions on 10.14.6 and you needed to hone in on one?
We tried it with 4.0.2, and got the same Cannot get EmbeddedOS properties
error. (I think 4.0.2 used the older SDK)
We tried it with 4.0.2, and got the same
Cannot get EmbeddedOS properties
error. (I think 4.0.2 used the older SDK)
Since experimental
the SDK used is 10.14, because pre-built libraries are built with that.
I read https://duo.com/labs/research/apple-t2-xpc and browsed all of the
ioreg
properties on my T2 macbook last night and did not see an alternative to querying the firmware version. This is what makes me weary.we've encountered issues with devices which are running beta versions of Bridge OS, such as from an early Catalina beta, when running an older operating system like 10.14.6. Finding these outliers with a table like this makes debugging much easier!
That's a good use case. In this scenario @keeleysam could the OS version (10.14.6) have been an indicator or were there multiple iBridge firmware versions on 10.14.6 and you needed to hone in on one?
I will continue to investigate a way to query bridge properties (though a bit hamstrung by lack of T2 device), but if we just want the version, we can check whether /System/Library/CoreServices/BridgeVersion.plist
exists and parse that as a fall back.
I am not yet sure if /S/L/CoreServices/BridgeVersion.plist
exists in 10.15, but that should be relatively easy to find out.
Caveat: I am not quite sure yet if BridgeProductBuildVersion
or BridgeVersion
in the plist is the actual firmware version.
Does that sound like a decent middle ground? Thoughts?
Thanks @sharvilshah!
Here is an example of that plist:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>BridgeBuildGroup</key>
<string>0</string>
<key>BridgeProductBuildVersion</key>
<string>17P1081</string>
<key>BridgeVersion</key>
<string>17.16.11081.0.0</string>
<key>IsSeed</key>
<string>NO</string>
<key>SEPEpoch</key>
<dict>
<key>Major</key>
<integer>1</integer>
<key>Minor</key>
<integer>0</integer>
</dict>
</dict>
</plist>
Thanks @theopolis!
I noticed some inconsistencies with /System/Library/CoreServices/BridgeVersion.plist
:
On my T1 machine, the contents of that plist is the same as the one you posted, but every apple tool (system_profiler SPiBridgeDataType
, remotectl
, IOKit (and by extension current table implementation) mentions the version as 14Y906
On T2 machine (at least the one at local apple store), the content of that plist (which is same as above) and that reported by apple tools matches up.
What parts of this table / iBridge information are important? If it is the case that T2 information is difficult to retrieve, I want to make sure we're focused on a real use case.
For example, if the only important information is that the machine has T2, this is simple. If you need the firmware version, it may be significant effort.
With this issue, is it still possible to just determine whether or not the machine has T2? I ran into this same issue while trying to write a query that would indicate whether a system has a T2 controller or not.
The use case is determining whether or not /usr/libexec/firmwarecheckers/eficheck/eficheck --integrity-check
is supported (it is NOT support on T2 chips).
Just commenting to add that getting the firmware version is helpful, but just determining whether a machine has T2 is also a valuable use case.
Bug report
What operating system and version are you using?
macOS 10.15.1 Catalina
What version of osquery are you using?
osquery 4.1.1 / 4.0.2
What steps did you take to reproduce the issue?
Running a query against the ibridge_info table I discovered that results are only returned for T1 MacBook Pro's.
What did you expect to see?
I expected to see results from T2 devices similar to @keeleysam's output testing the original PR (https://github.com/osquery/osquery/pull/5166):
What did you see instead?
Instead, I see no rows for T2 devices. @sharvilshah mentioned in his original PR(https://github.com/osquery/osquery/pull/5203) that lack of results was a known issue for Desktop devices (https://github.com/osquery/osquery/pull/5203#issuecomment-521663431) but it is also failing to return results for T2 MacBook Pro's. Additionally, on these devices I see an error related to EmbeddedOS:
I realize this table was significantly rewritten to use EmbeddedOS (https://github.com/osquery/osquery/pull/5707), Wondering if @sharvilshah, @keeleysam, @terracatta might have input on the possible causes for the issue.