Opened 8 years ago

Closed 7 years ago

#1193 closed task (fixed)

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@…
Blocked By: Blocking:
Deployments affected: Action Needed:
Verified: no

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 (21)

comment:1 follow-up: Changed 8 years ago by garysu

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

comment:2 in reply to: ↑ 1 Changed 8 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.

comment:3 Changed 8 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


comment:4 Changed 8 years ago by holger

  • Cc holger added
  • Verified unset

comment:5 Changed 8 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?

comment:6 follow-up: Changed 8 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?

comment:7 in reply to: ↑ 6 Changed 8 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.

comment:8 Changed 8 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.

comment:9 Changed 8 years ago by rsmith

  • Milestone changed from BTest-4 to Trial-2

comment:10 Changed 7 years ago by jg

  • Cc rsmith wmb@… added; holger removed

Richard? Where are we with this?

comment:11 Changed 7 years ago by jg

  • Milestone changed from Trial-2 to Trial-3

comment:12 follow-up: 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.

comment:13 in reply to: ↑ 12 ; follow-up: 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.

comment:14 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.

comment:15 Changed 7 years ago by jg

  • Milestone changed from Trial-3 to MP Start
  • Owner changed from rsmith to wmb@…


comment:16 follow-up: 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.

comment:17 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?

comment:18 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.

comment:19 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).

comment:20 Changed 7 years ago by wmb@…

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

comment:21 Changed 7 years ago by wmb@…

  • Resolution set to fixed
  • Status changed from new to closed

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

Note: See TracTickets for help on using tickets.