Berkeley CSUA MOTD:Entry 33348
Berkeley CSUA MOTD
 
WIKI | FAQ | Tech FAQ
http://csua.com/feed/
2025/04/04 [General] UID:1000 Activity:popular
4/4     

2004/9/4-6 [Computer/HW/CPU, Computer/SW/Security] UID:33348 Activity:moderate
9/3     Thinking about getting an opteron? If security is your concern,
        maybe you should think again: http://csua.org/u/8x7
        \_ Erm, maybe I'm missing something, but that page argues that
           if someone can gain root access and flash the system with
           malicious microcode, they can in the future gain full access
           through mere userspace privilege.  True, but wouldn't that apply
           to any box where you can flash the bios as root?  -John
           \_ on the PC, linux for example bypasses the BIOS except for
              initial bootstrapping.  modifying processor microdoce gives
              a more persistent hook, as would modifying firmware of
              any DMA-master capable device that is not reprogrammed
              by the OS.  this isn't the end of the world, but surely
              adds to the "security is hard" mountain.
        \_ Very few places need to be this concerned about security.  The
           financial industry, for example.  The finance and high security
           government facilities I'm aware of would be no more or less
           freaked out by this than the idea that someone got root in the
           first place.  If they take a gun to your sysadmin's head at a
           party they'll get access, too.  So, if you're thinking about
           hiring sysadmins who might show at a party maybe you should
           think again.
                 \- hello, it is interesting to talk to people in the
                    financial world about some of the "attacks" they
                    face, for example organized crime infiltrating the
                    mail room. also you have problems like say how to
                    not let the backup staff read the data. ok tnx.
                    \_ Yes, that is what I was getting at with the sysadmin
                       at a party line.  There are lots of easier ways to
                       do nasty things that don't involve updating micro-code
                       or anything high tech at all.
           \_ Wow, someone who actually knows something. Thank you for
              showing up.
              \_ That's why I avoid parties.  It has helped me land better
                 jobs.  :-)
ERROR, url_link recursive (eces.Colorado.EDU/secure/mindterm2) 2025/04/04 [General] UID:1000 Activity:popular
4/4     

You may also be interested in these entries...
2012/3/29-6/4 [Computer/HW/Memory, Computer/HW/CPU, Computer/HW/Drives] UID:54351 Activity:nil
3/29    A friend wants a PC (no mac). She doesn't want Dell. Is there a
        good place that can custom build for you (SSD, large RAM, cheap video
        card--no game)?
        \_ As a side note: back in my Cal days more than two decades ago when
           having a 387SX made me the only person with floating-point hardware,
           most machines were custom built.
	...
2009/8/6-14 [Computer/SW/OS/OsX] UID:53250 Activity:moderate
8/5     Why is Mac OS 10.6 $29 and 10.5.6 $129? Is it a typo?
        \_ $29 for existing users.
           \_ it doens't even support ppc does it.
              \_ who cares about ppc anymore? Everything is Intel based
                 \_ I have a PPC mini at home that I use.
                 \_ I have a quad core G5 ppc.
	...
2009/6/1-3 [Computer/HW/CPU] UID:53068 Activity:high
5/31    History of winners and losers by *popularity*:
        VHS > Beta Max
        USB2 > Firewire
        x86 > PowerPC > Everything Else > DEC Alpha > Itanium
        BlueRay > HDDvd
        \_ It's too early to tell RE: "Blue"Ray. They may both turn out to be
	...
2009/5/26-30 [Computer/HW/CPU] UID:53045 Activity:nil
5/26    Engineering is HOT man! Super hot co-inventor of USB at Intel:
        http://www.youtube.com/watch?v=jqLPHrCQr2I
	...
2009/1/16-23 [Computer/HW/CPU] UID:52404 Activity:nil
1/16    AMD to layoff 9%, suspend 401(k) match, cut engineer salaries 10%
        \_ Awwww, too bad                                       -Intel
           \_ My heart bleeds for you. --transmeta.
              \_ Wait, another sodan worked there? --ex-transmeta
                 \_ Hello transmeta-coward, meet another transmeta-coward.
  http://www.theregister.co.uk/2009/01/16/amd_q1_2009_job_cuts_wage_reductions
	...
2008/12/4-10 [Computer/HW/CPU, Computer/HW/Drives] UID:52163 Activity:nil
12/4    A question to you old crufy alumni: So lately we've suggested
        VMs, and been asked why it's necessary. We've suggested top-of-the-line
        hardware and been told we don't need that much power. So I'd like to
        ask -- what exactly do you think the CSUA is supposed to _be_?
        \_ Noone said VMs weren't needed.  They suggested you use the
        \_ No one said VMs weren't needed.  They suggested you use the
	...
2013/10/24-11/21 [Computer/Companies/Apple] UID:54747 Activity:nil
9/19    "No, A Severed Finger Will Not Be Able to Access a Stolen iPhone 5S"
        http://mashable.com/2013/09/15/severed-finger-iphone-5s
        I'm sure the Apple QA department has tested extensively that a severed
        finger will not be able to access a stolen iPhone 5S.
        \_ It doesn't matter whether or not a severed finger can be used.  It
           matters whether or not a robber thinks that a severed finger can be
	...
2013/6/6-7/31 [Politics/Foreign/Asia/China, Computer/SW/Security] UID:54690 Activity:nil
6/6     Wow, NSA rocks. Who would have thought they had access to major
        data exchangers? I have much more respect for government workers,
        crypto experts, mathematicans now than ever.
        \_ flea to Hong Kong --> best dim-sum in the world
           \_ "flee"
        \_ The dumb ones work for DMV, the smart ones for the NSA. If you
	...
2012/8/26-11/7 [Computer/SW/Security] UID:54465 Activity:nil
8/26    Poll: how many of you pub/priv key users: 1) use private keys that
        are not password protected 2) password protect your private keys
        but don't use ssh-agent 3) use ssh-agent:
        1) .
        2) ..
        3) ...
	...
2012/8/29-11/7 [Computer/SW/Security] UID:54467 Activity:nil
8/29    There was once a CSUA web page which runs an SSH client for logging
        on to soda.  Does that page still exist?  Can someone remind me of the
        URL please?  Thx.
        \_ what do you mean? instruction on how to ssh into soda?
           \_ No I think he means the ssh applet, which, iirc, was an applet
              that implemented an ssh v1 client.  I think this page went away
	...
2012/9/20-11/7 [Computer/SW/Unix, Finance/Investment] UID:54482 Activity:nil
9/20    How do I change my shell? chsh says "Cannot change ID to root."
        \_ /usr/bin/chsh does not have the SUID permission set. Without
           being set, it does not successfully change a user's shell.
           Typical newbie sys admin (on soda)
           \_ Actually, it does: -rwsr-xr-x 1 root root 37552 Feb 15  2011 /usr/bin/chsh
	...
2012/8/7-10/17 [Computer/SW/Security] UID:54455 Activity:nil
8/6     Amazon and Apple have lame security policies:
        http://www.wired.com/gadgetlab/2012/08/apple-amazon-mat-honan-hacking/all
        "First you call Amazon and tell them you are the account holder, and
         want to add a credit card number to the account. All you need is the
         name on the account, an associated e-mail address, and the billing
         address. "
	...
Cache (8192 bytes)
csua.org/u/8x7 -> www.realworldtech.com/forums/index.cfm?action=detail&PostNum=2527&Thread=1&entryID=35446&roomID=11
com) 7/22/04 Opteron Exposed: Reverse Engineering AMD K8 Microcode Updates Summary This document details the procedure for performing microcode updates on the AMD K8 processors. It also gives background information on the K8 microcode design and provides information on altering the microcode and loading the altered update for those who are interested in microcode hacking. Source code is included for a simple Linux microcode update driver for those who want to update their K8's microcode without waiting for the motherboard vendor to add it to the BIOS. The latest microcode update blocks are included in the driver. Background Modern x86 microprocessors from Intel and AMD contain a feature known as "microcode update", or as the vendors prefer to call it, "BIOS update". Essentially the processor can reconfigure parts of its own hardware to fix bugs ("errata") in the silicon that would normally require a recall. This is done by loading a block of "patch data" created by the CPU vendor into the processor using special control registers. Microcode updates essentially override hardware features with sequences of the internal RISC-like micro-ops (uops) actually executed by the processor. They can also replace the implementations of microcoded instructions already handled by hard-wired sequences in an on-die microcode ROM. AMD's US Patent 6438664 ("Microcode patch device and method for patching microcode using match registers and patch routines") goes into substantial detail on this. Typically microcode update blocks are stored in the BIOS flash ROM and loaded into the processor as the system boots. for instance, Linux contains a microcode device driver for Intel chips. AMD recently released a "BIOS fix" to motherboard makers to address Errata 109, in which REP MOVS instructions caused subsequent instructions to be skipped under specific pipeline conditions. Previously it was not clear if and how AMD even supported microcode updates in the K8 family until this announcement. After analyzing a number of BIOS images, it appears that AMD has secretly used the microcode update facility on several occasions over the past few years, but obviously avoided publicly disclosing that it actually had bugs patchable in this manner. Early K7 (Athlon) cores initially supported microcode updates as well, until ironically the microcode update mechanism itself was found to be broken and subsequently listed as an errata! The following sections describe the microcode update procedure, obtained by clean room reverse engineering various vendors' BIOS code. The actual microcode update blocks are embedded in the BIOS image; the most recent updates (created June 2004) have been included in the Linux driver source code attached to this description. Microcode Update Procedure The update procedure expects the 64-bit virtual address of the update data, including the 64 byte header, to be in edx:eax: edx = high 32 bits of 64-bit virtual address eax = low 32 bits of 64-bit virtual address ecx = 0xc0010020 (MSR to trigger update) Execute wrmsr with these register values. If the address and update block data are valid, wrmsr completes successfully. The microcode does not appear to update MSR 0x8B with the new update signature as it does on Intel processors, despite the fact that some BIOS code I have analyzed does seem to check this field. It is possible the MSR is only updated under certain conditions, for instance when microcode is loaded before initializing the cache controller. Nonetheless, as we shall see below, the processor is clearly doing something internally when it claims to accept an update in this manner. It was not tested on any other K8 cores, although the driver source code includes updates for CPUIDs 0x0F4A and 0x0F50. Microcode Block Format The microcode block consists of a 64 byte header and an 896 byte data area. The processor consumes both the header and data area during an update. The most important ones are: - Offset 0: 32-bit word for update creation date (eg 0x20040602) - Offset 12: 32-bit checksum: sum of all 32-bit words in the data area - Offset 24: Low 8 bits of the cpuid (eg 0xf48 -> 0x48). Microcode Format Surprisingly, the microcode itself is in no way encrypted as it is in Intel microcode updates; the raw data loaded into the microcode patch array is directly exposed. The repetitive structure of the data, bit patterns and fields characteristic of microcode indicate that apparently no encryption was performed. US Patent 6438664 describes the most probable structure of this data; the bit patterns in the update blocks show the outline of the uop triads and control fields known to exist in K8 microcode. Further analysis of the microcode format is in progress. Even more surprising is the total lack of strong authentication that the update block has not been damaged or altered. The processor's sole means of validating an update is to take the sum of all 32-bit words in the 896 byte update block and compare it to the 32-bit checksum at offset 12; this verification is done by microcode already stored in the microcode ROM. I have tested modifying random bits within the update block, regenerating a correct checksum, and loading the block into the processor. In many cases the processor accepts the block with no visible effects; Most alarming is the way in which certain bit modifications cause the processor to perform very bizarrely, for instance raising segfaults and performing incorrect computations on certain microcoded instructions. The processor also apparently does not check the header to see if the loaded update matches its exact model and stepping; it is possible to load updates intended for an Opteron onto an Athlon 64 CPU, although this will crash the machine or cause bizarre behavior. Depending on which data block bits are modified, loading an invalid update apparently causes an internal fault and the CPU spontaneously reboots. Implications The ability to fundamentally alter instruction decoding and execution on AMD K8 processors is sure to interest hardware hackers everywhere. Unfortunately, it is not clear if this has much practical use. The updates are structured to patch specific microcode lines, and there are a very limited number of patch slots available (around 64 if the patented technique was actually implemented as described). Adding useful new instructions to the ISA is therefore unlikely; at best we could enable a previously undefined opcode to execute a few lines of uops and return. The primary purpose of microcode patching is to modify or disable defective functionality, rather than add new features. Interestingly, this does have serious implications for system security. If one is able to get root access on a machine even once, it is hypothetically possible to install a microcode update specifically to help compromise security from userspace at a later time. Such an update could be flashed into the BIOS to make it persistent across reboots. For instance, by patching the appropriate microcode lines, it may be possible to catch an opcode that would normally be illegal, and instead handle it by tricking the TLB into thinking we're in kernel mode when in fact the attacker has only compromised a userspace process. From there, the attacker could control the entire machine, all without altering a single bit of "software". Imagine the fiasco that would ensue if a system were compromised by altering the CPU itself. Evidently AMD was not as wise by assuming their microcode was uncrackable. There may also be a hidden danger to altering K8 microcode without complete information. It is possible (though very unlikely) that the microcode could electrically reconfigure signal routing in a fashion similar to FPGAs, for instance to cut off defective logic and reroute signals to redundant arrays. This approach has been used in the past and the AMD patents even suggest it. If this were the case, there is a very remote chance the CPU itself could be permanently damaged, for instance, by tri-stating pass transistors into a high current draw state or adjusting the K8's voltage and frequency scaling controls out of spec. I have just seen programmable logic...