Disable CPU access to EC RAM and I/O

[wmb@…]

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.

[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.

[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

[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?

[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?

[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.

[rsmith]

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

[jg]

Richard? Where are we with this?

[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.

[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.

[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.

[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.

[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?

[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.

[wmb@…]

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

[wmb@…]

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

[wmb@…]

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