Ticket #1193 (closed task: fixed)

Opened 7 years ago

Last modified 6 years ago

Disable CPU access to EC RAM and I/O

Reported by: wmb@… Owned by: wmb@…
Priority: high Milestone: MP Start
Component: embedded controller Version:
Keywords: Cc: rsmith, wmb@…
Action Needed: Verified: no
Deployments affected: Blocked By:
Blocking:

Description

It is currently possible for the main CPU to access arbitrary EC RAM and I/O resources via the 381,382,383 I/O port dance. For security reasons, we need to disable that and provide EC commands to access specific information that we currently get via that path.

Here are some things that we current access via ports 381..383. Please add to this list as necessary:

a) Polling for game key presses in fast-boot firmware (if a game key is pressed, the interactive boot path is used)

b) Controlling write-protect for the SPI FLASH

c) Turning the keyboard controller functionality on and off for the purpose of programming SPI FLASH (there may be a new command for this already)

d) Programming the SPI FLASH.

e) Controlling the keyboard LEDs (which are going away, so this is probably moot)

f) Resetting the wireless LAN module

g) Accessing battery state information

h) Bit-banging the 1-wire battery status line for recovering bricked batteries

We may want to leave direct access available to the firmware at early system firmware startup, and then turn it off when we latch on the SPI FLASH write protect. That would let the system firmware perform SPI reflashing using the current direct access method.

Change History

follow-up: ↓ 2   Changed 7 years ago by garysu

  • owner changed from ray.tseng@… to David.Lin

in reply to: ↑ 1   Changed 7 years ago by rsmith

Replying to garysu:

David,

Please make sure you don't do this until after we get all the EC commands in place. I have a growing list of commands to add and I will send you the list via email as well.

  Changed 7 years ago by David.Lin

wmb: I make sure we don't do this. But we are doing the EC commands instead of 381, 382 and 383 port in next version.

Command port: 0x6C Data port: 0x68 New commands: 1. 0x80, read the mailbox address 2. 0x81, write the mailbox address 3. 0x82, read the mailbox data 4. 0x83, write the mailbox data 5. 0x88, read transform 6. 0x89, write transform

Read/Write EC RAM Procedure: 1. Read Procedure:

out 0x6c, 0x81 // write the mailbox address out 0x68, EC RAM address (High) out 0x68, EC RAM address (Low) out 0x6c, 0x88 // read transform out 0x6c, 0x82 // read the mailbox data in 0x68 // EC RAM (High) in 0x68 // EC RAM (Low)

2. Write Procedure:

out 0x6c, 0x81 // write the mailbox address out 0x68, EC RAM address (High) out 0x68, EC RAM address (Low) out 0x6c, 0x83 // write the mailbox data out 0x68, Data (High) out 0x68, Data (Low) out 0x6c, 0x89 // write transform

  Changed 7 years ago by holger

  • cc holger added
  • verified unset

  Changed 7 years ago by ruby

I have a question on the subject. I am trying to learn how to write code for the EC, and I cannot find the code that enables I/O indexing, and which sets the ports to 381/382/383. I don't have the sources ofcourse, but im looking at a disassembly of vc13 and older versions. Is it the right place to ask such questions?

follow-up: ↓ 7   Changed 7 years ago by David.Lin

Mitch: I will disable index port but I find the OFW can't flash EC or OFW when I disable index port. Whether the *flash* command use the 38x port or not, can you check?

in reply to: ↑ 6   Changed 7 years ago by rsmith

Replying to David.Lin:

I will disable index port but I find the OFW can't flash EC or OFW when I disable index port. Whether the *flash* command use the 38x port or not, can you check?

David:

Please don't disable the Indexed IO in the EC. We decided it will be much better to just let Openfirmware decide when to disable this. It is a very useful debugging tool. On production roms we will disable the Indexed IO right before write protecting the SPI flash.

  Changed 7 years ago by rsmith

  • owner changed from David.Lin to rsmith
  • type changed from defect to task

I'll take on resposibility this gets disabled in OFW at the proper time.

  Changed 7 years ago by rsmith

  • milestone changed from BTest-4 to Trial-2

  Changed 7 years ago by jg

  • cc rsmith, wmb@… added; holger removed

Richard? Where are we with this?

  Changed 7 years ago by jg

  • milestone changed from Trial-2 to Trial-3

follow-up: ↓ 13   Changed 7 years ago by wmb@…

This is contingent upon #978 ( http://dev.laptop.org/ticket/978 ).

We cannot disable indexed I/O access to the EC until the (secure) automatic firmware reprogramming is implemented, because indexed I/O is necessary for SPI reflashing.

in reply to: ↑ 12 ; follow-up: ↓ 14   Changed 7 years ago by rsmith

Replying to wmb@firmworks.com:

This is contingent upon #978 ( http://dev.laptop.org/ticket/978 ). We cannot disable indexed I/O access to the EC until the (secure) automatic firmware reprogramming is implemented, because indexed I/O is necessary for SPI reflashing.

I was going to have OFW disable the indexed IO at the same time it write protects the ROM and leave it enabled in the EC permanently.

in reply to: ↑ 13   Changed 7 years ago by wmb@…

Replying to rsmith:

I was going to have OFW disable the indexed IO at the same time it write protects the ROM and leave it enabled in the EC permanently.

I agree, that is a good approach.

  Changed 7 years ago by jg

  • owner changed from rsmith to wmb@…
  • milestone changed from Trial-3 to MP Start

follow-up: ↓ 17   Changed 7 years ago by wmb@…

It was suggested (via IRC, in the weekly meeting) that we should turn off indexed I/O just prior to jumping into Linux.

One result would be that, in order to use the "flash" command afterwards, you would have to remove power from the machine to cause a cold-start of the EC. Once indexed I/O is off, it remains off across warm reboots and power-button off/on cycles, because they do not cause the EC to turn off.

in reply to: ↑ 16   Changed 7 years ago by rsmith

Replying to wmb@firmworks.com:

power from the machine to cause a cold-start of the EC. Once indexed I/O is off, it remains off across warm reboots and power-button off/on cycles, because they do not cause the EC to turn off.

Perhaps we should make it conditional on the MP flag then?

  Changed 7 years ago by wmb@…

Indexed I/O turn-off is essentially equivalent to setting the write-protect latch. In fact it might be strong enough that the write-protect latch is essentially redundant.

The right time to turn off indexed I/O is when we have our ducks in a row with regard to secure firmware auto-updates, so yes, it needs to be contingent on the WP tag, but we can't do it until the firmware update thing is solid.

  Changed 7 years ago by wmb@…

Indexed I/O turn off is now contingent upon, and blocked by, #4128 (remove kernel uses of indexed I/O).

  Changed 7 years ago by wmb@…

The blocker has been removed. We need to decide when to make the cutover...

  Changed 6 years ago by wmb@…

  • status changed from new to closed
  • resolution set to fixed

Fixed by svn 687. The fix will be in q2d02. The test version is q2d01g.

Note: See TracTickets for help on using tickets.