FW16 Intrusion detection no workie

[tacsist]

Device Information

System Model or SKU

• Framework Laptop 13 (11th Gen Intel® Core™)
• Framework Laptop 13 (12th Gen Intel® Core™)
• Framework Laptop 13 (13th Gen Intel® Core™)
• Framework Laptop 13 (AMD Ryzen™ 7040 Series)
• Framework Laptop 13 (Intel® Core™ Ultra Series 1)
• Framework Laptop 16 (AMD Ryzen™ 7040 Series)

BIOS VERSION

3.05

DIY Edition information

Memory: FW 2x16gb
Storage: Samsung 970 EVO Plus

Standalone Operation

Are you running your mainboard as a standalone device. Is standalone mode enabled in the BIOS?

• Yes
• No

Describe the bug

The intrusion detection seems to not work/not be implemented. I have never gotten a password prompt and the EC is clueless as well. I have def enabled the detection before (it is still on) and have disassembled the laptop when I was applying the mail-in keyboard stand-offs/pads.

Steps To Reproduce

1. Enable intrusion detection in UEFI (or don't, i think the EC should still pick it up)
2. Open the laptop and remove the midplate
3. Put everything back in its place
4. Observe no reaction

Expected behavior

Intrusion switch gets triggered upon opening the laptop innards, prompting uefi password and showing it in EC output

Operating System (please complete the following information):

Linux tacsist-fw 6.12.7-arch1-1 #1 SMP PREEMPT_DYNAMIC Fri, 27 Dec 2024 14:24:37 +0000 x86_64 GNU/Linux

Logs

sudo framework_tool --driver cros-ec --intrusion
Chassis status:
  Coin cell ever removed:   false
  Chassis currently open:   false
  Chassis ever opened:      false
  Chassis opened:           0 times
  Chassis opened while off: 0 times

Additional context

None really, enabled the uefi setting way back, got surprised it did nothing, forgot about it until now when i was checking EC params/tools which report that either I am a master in physical hacking or that the sensor doesn't work. Would be funny if the switch actually doesn't exist on FW16

[JohnAZoidberg]

Would be funny if the switch actually doesn't exist on FW16

The switch does exist on all our platforms.
On the Framework 16 it is triggered when you remove the midplate. And if you boot with the midplate remove it will show a warning during boot, regardless of intrusion setting.

If all power is removed from the system, the intrusion details are cleared.
But usually the battery is installed before the chassis is closed again.
If I do that, I see:

  Coin cell ever removed:   false
  Chassis currently open:   false
  Chassis ever opened:      true
  Chassis opened:           0 times
  Chassis opened while off: 1 times

You could try booting with the midplate removed to see if it tells you about it.
And then you could boot into Linux and run framework_tool again. You can toggle the switch with your finger and make sure that the "Chassis opened" number increases and "Chassis currently open" is accurate, to make sure that your switch is working correctly.

[lattera]

One thing that's confusing to me is that to perform a BIOS reset on FW13, the chassis intrusion switch is supposed to be pressed ten times in succession. I can't seem to find any instructions pertinent to FW16. I cannot find the chassis intrusion switch on the FW16. Can Framework Computer please provide an image of where the chassis intrusion switch is and how to activate it on the FW16? (Or, alternatively, concrete directions for performing a UEFI BIOS reset via hardware.) It's quite possible I'm missing something.

[tacsist]

@JohnAZoidberg, so after a long hiatus I have tried to disassemble my FW16 again.

And wouldn't you know it, it worked, the framework_tool reported the "Chassis opened while off".
I afterwards tried booting without the midplate and it didn't stop me, but it did report "Chassis currently open: true". I later realised that at 1 point I have reset the bios, so I didn't have the BIOS option of intrusion password.

BUT, today I had to look at the mainboard again, so I disassembled my laptop, took off the midplate and then put it all back together. And nothing happened, no bios password, nor framework_tool reporting additional opening. The former disassembly I had taken out the dGPU as well for cleaning.

My thinking right now is that, a) there is some problem in the EC logic b) the keyboard deflection kit might be interfering with the intrusion switch if it exists.

P.S.: "Chassis currently open:" always reports false unless "Chassis currently open:" is true, and here is a pic of booting without the midplate.