Register Test Priority Level 1

Register Test Priority Level – 1

Description – the following 4 registers control assigned resource allocation ID (RAID) for any type of resource access. The SPEs have their own register, and the question/security idea is to test if a particular SPE can be made to read a RAID out of another SPEs register.

MultiCore Multi-Level Secure Experiment
Experiment Number: UI-09-046 / Processor: IBM Cell BE
Unit(s) being tested: Resource Allocation Register for PPE / Violation: Resource Allocation ID sharing
Synopsis:
For each process running on an SPE associated with a group that requires some resource, the PPE assigns a resource allocation ID (RAID) to allow all resource requesters of 1 group to access a resource. This RAID provides each requester with a channel to the resource that it needs. This access to a resource initiates load or store requests or DMA read or write accesses. The question to be answered is based on PPE hacking. If a SPE spoofs the PPE, We have problems.
Materials Needed:
SPE, PPE
Methodology:
Setup:
Install script to change the value of this register to deny access of a resource for a necessary group.
Procedure:
Script to change the address of the resource that will be accessed by a group.
Specific Runs INCLUDE:
Spoof SPE, then run scripts to alter resource access.
Program Specifics:
1, 10, 100, 1000, 10000 sec tests to allow specified times for a SPE to crack the PPE. (password, admin privileges, etc…)
Analytical Method (answer these questions with this test):
Can we use a Denial of Service Attack by setting a group to another resource (spoof PPE)? Is there a way to specify all of memory for a SPE to use, given a “key” for all of memory as an allowed resource?
Results:
MultiCore Multi-Level Secure Experiment
Experiment Number: UI-09-047 / Processor: IBM Cell BE
Unit(s) being tested: Resource Allocation Register for SPE / Violation: Resource Allocation ID Sharing
Synopsis:
For each process running on an SPE associated with a group that requires some resource, the PPE assigns a resource allocation ID (RAID) to allow all resource requesters of 1 group to access a resource. This RAID provides each requester with a channel to the resource that it needs. This access to a resource initiates load or store requests or DMA read or write accesses. Also, can multiple SPEs be in the same group?
Materials Needed:
“group” bit of a requester (SPE).
Methodology:
Setup:
Install script on an SPE to change its group ID.
Procedure:
Script to change the “group ID” of a SPE.
Specific Runs:
Run scripts on SPE without spoofing PPE, to attempt to get an SPE to access the wrong resource.
Program Specifics:
Try to set a SPE to a group with “top-secret”, “secret”, “classified”, and “unsecure data”.
Analytical Method (answer these questions with this test):
Can multiple processors have the same resource ID for the same group of information?
Results:
MultiCore Multi-Level Secure Experiment
Experiment Number: UI-09-048 / Processor: IBM Cell BE
Unit(s) being tested: Resource Allocation for IOIF 0 & 1 / Violation: Bandwidth violation IOIF 0 & 1
Synopsis:
Each I/O interface has 4 virtual channels, 1 for each resource allocation group. External bridges or I/O devices must be able to identify 1 of the channels with each physical transfer. Virtual channels can do both reads and writes. The Channels have “interchannel delay” when say 2 virtual channels access the same memory bank. (resource) Delays occur when outbound and inbound requests compete for the same resource. IF 2 SPEs are competing for the same resource, can SPE 2 see what SPE 1 is getting from that resourceduring that delay. Assuming the PPE has given both processors the group ID the access that resource.
Materials Needed:
2 SPEs.
PPE to give 2 SPEs the rights to the same resource at the same time.
Scripts need to print the previously used data from the resource before they begin there own work.
Methodology:
Setup:
Install a script on each SPE to request access to the same resource from the PPE.
Configure the PPE to allow both SPEs to be in the same resource allocation group.
Procedure:
Run the configuration script to make the PPE set 2 different SPEs to the same group.
Run the 2 Scripts to execute the same commands using the same resources.
Specific Runs:
Loop the 2 SPEs and their commands so that when 1 gets done it will run the same instructions again. Force quit after a few cycles. Analyze the 2 SPEs and the delays they create before and after instruction sets.
Program Specifics:
1, 10, 100, 1000, 10000 seconds and record length of time of delay. Print resources that the other SPE is using to a file.
Analytical Method:
Is there much data in the previously used list in the file we create? If so we could see what another SPE was doing.
Results:

Description – the following 4 registers control if/when I/O accesses timeout, set I/O access translation, catch I/O errors, and verify that “software should ensure that no accesses to the previous or new address range occur”. Tests should be run to attempt to change timeout bits incase an SPE can force the system to give it more time to perform its duties, and tests to verify that mask bits aren’t set so that SPEs are given inappropriate access to previous address ranges.

MultiCore Multi-Level Secure Experiment
Experiment Number: UI-09-042 / Processor: IBM Cell BE
Unit(s) being tested: I/O IOC_IOCmd_Cfg / Violation: Process Timeout Changed
Synopsis:
This is a base configuration register. Pre-sets when processes timeout, token parameters, read intervention, outgoing channel settings. A test could be “is this register secure?” Can processors modify the preset timeout bit making it less responsive as far as timing out if a command takes too long? Can a SPE pre-set the timeout bit so that it doesn’t time out? Can this register be reprogrammed to pre-set the outgoing I/O channels differently? Can it be modified so that information can be read differently?
Materials Needed:
SPE to reprogram this register. A script to reset the average processor timeout.
A script to reset the different out channels so information can be set to non-secure zones.
Methodology:
Setup:
We will have to write code to reprogram this register, and set it up to be executed from and SPE. Like Always, we will need a output monitor to view the status of executing processes and the address of where data is being sent.
Procedure:
1 procedure to reset the timeout bit.
1 procedure to reset the outgoing channels.
Specific Runs:
Have SPE, for example, hack the timeout bit and set it to various values.
Try setting the timeout so processes can run for 10, 20, 30 seconds?
Program Specifics:
Write a infinitly executing program for 1 SPE, and start it after another SPE changes the timeout bit……bits should be set to within a 30% standard deviation of average timeout for IBM read/write commands.
Analytical Method:
Verifying Processes Do indeed “time-out”.
Results:
MultiCore Multi-Level Secure Experiment
Experiment Number: UI-09-043 / Processor: IBM Cell BE
Unit(s) being tested: I/O IOC_IOST_Origin / Violation: disable control for main memory
Synopsis:
This register should be configured at boot up. First bit, when set to 0 enables I/O address translation. Security concern: Can a processor set it to a 1? Disabling this feature disables protection of the main storage. This also adjusts the size of the cache pages, controls cache misses, and orders I/O memory accesses.
Materials Needed:
A processor that di able this feature and a script to disable it.
A processor that can spoof the allowed disabler if the PPE is the only processor allowed to change this register.
Once disabled, a processor will need to read and write data from main storage at will, top secret or not top secret.
Methodology:
Setup:
A monitor to view changes to main storage.
Install the scripts on an SPE.
Procedure:
A procedure to either hack the bit or spoof a process that can, possible PPE?
A script to change the bit to a 1.
Specific Runs:
Purely hacking at first if we have to Spoof the PPE to do this.
Then test to just change the bit.
Program Specifics:
1, 10, 100, 1000, 10000 seconds which the hacking processor will try in order to spoof a privileged processor, PPE.
Analytical Method:
Security of main storage analysis.
Results:
MultiCore Multi-Level Secure Experiment
Experiment Number: UI-09-044 / Processor: IBM Cell BE
Unit(s) being tested: I/O Base Address Register / Violation: Is the Previously accessed address list flushed after it is used?
Synopsis:
This register is an address to an address range for the currently accessed memory. Once a processor gets done with its task, is the cache flushed or is it just re-written with the new addresses in the new range? If it is just rewritten, the idea is that the old addresses would remain in the cache until it is over written. AND….
“software should ensure that no accesses to the previous or new address range occur” when modifying a Mask Register. Is this true? Can the register be flushed so it no longer points to a range in the cache? Can the cache be flushed after each use?
Materials Needed:
Processor (SPE or PPE)
Instruction set to record cache before running own code.
Methodology:
Setup:
Monitor to view if previous addresses are viewable when changing mask bit.
Install script to record address in register and cache before execution of own code.
Procedure:
Code for processor to change register mask bit.
Code to print data at old address if still present. (steal it)
Specific Runs:
Try to change the bit and record any previous addresses.
Then go to all addresses and take information.
Program Specifics:
Not time specific, 20 tries to set bit and steal data.
Analytical Method:
Previous processor has used address, is it gone by the time another processor sets the mask bit?
Results:
MultiCore Multi-Level Secure Experiment
Experiment Number: UI-09-045 / Processor: IBM Cell BE
Unit(s) being tested: I/O IOC_IO_ExcpStat / Violation: I/O error uncaught
Synopsis:
This register captures error information for I/O exceptions. There is not going to be very many security concerns as to if errors cause I/O exceptions, but more importantly will be the case that if an exception is caught, can we determine what data caused it and what a processes was doing when it was caused.
Materials Needed:
Script to record exceptions and their causes.
Monitor to print these and try to access addresses associated with those addresses.
Methodology:
Setup:
Monitor for average and hacked exceptions caught.
Install Script on an SPE.
Procedure:
Script to catch exceptions and use addresses associated with those I/O transfers.
Specific Runs:
1. run script in background mode.
2. Wait for exceptions to be caught by the normal usage of the register.
3. Record information about exception caught.
4. Access Information used associated with that exception.
Program Specifics:
Wait for exceptions for a variety of seconds, (10, 100, 1000, 10000 seconds)
Analytical Method:
Is I/O exception information secure?
Results:

Description – the following 4 registers control SPE confidential work. Tests should be done to verify that SPEs can’t access another SPEs GPR. Also, tests should be done to verify that if SPEs write to logs, can other SPEs read these logs by obtaining the bits to these logs. Tests should also cover PPE spoofing, in the attempt to modify “privileged state” registers of other SPEs.

MultiCore Multi-Level Secure Experiment
Experiment Number: UI-09-014 / Processor: IBM Cell BE
Unit(s) being tested: SPE GPR / Violation: Location of other SPE GPRs Not Private
Synopsis:
For any SPE, all data types used for any calculation based on information for that SPE is stored in that SPE’s GPR. The address of the GPR for all the SPE’s is know, So the idea would be to create pointers to those other memory addresses at a given time and then delete those pointers when it comes time to process the regular process for that SPE.
Materials Needed:
Script to create temporary pointers that make an SPEs GPRs get data from another SPEs GPRs. A Monitor, or print function to record the values that we get from a temporary pointer. A function to free all temporary pointers so an SPE can still do it’s assigned tasks.
Script from SPE FPSCR test.
The SPE FPSCR test to run in parallel.
Methodology:
Setup:
Install both scripts described above on an SPE, and have the FPSCR test right beside it.
Procedure:
See the Script under materials needed.
Specific Runs:
Test if an SPE needs permission from the PPE to process our script.
Test if temporary pointer can be assigned to where ever we want on the stack.
Program Specifics:
Run the SPE with temporary pointers, then free them and exit the script to process a normal task. Repeat process a few times.
Analytical Method: (questions to be answered)
How much bandwidth does a typical SPE take during ‘normal operation’?
How much does it take with 128 temporary pointers assigned to another SPEs GPRs?
Results:
MultiCore Multi-Level Secure Experiment
Experiment Number: UI-09-015 / Processor: IBM Cell BE
Unit(s) being tested: SPE FPSCR / Violation: PPE FPSCR log
Synopsis:
The processor updates this register after every floating-point operation to record information about the result and any associated exceptions. The idea here would be to make a lookout for this register that would count floating point operations. Such a test would run in parallel with the SPEs GPR tests. It would also need a temporary pointer to the FPSCR of the appropriate SPE’s GPR that we will have already created temporary pointers to in the last test.
Materials Needed:
A Script to create a temporary pointer to the address of the SPEs FPSCR register of choice. A print function to keep updating the value in that register at all times. And of course a free pointer function so the hacking SPE can process its own instruction set as well.
Script from SPE GPR test.
The SPE GPR test to run in parallel.
Methodology:
Setup:
Install both scripts described above on an SPE, and have the GPR test right beside it.
Procedure:
See the Script under materials needed.
Specific Runs:
Test if an SPE needs permission from the PPE to process our script.
Test if temporary pointer can be assigned to where ever we want on the stack.
Program Specifics:
Run the SPE with temporary pointers, then free them and exit the script to process a normal task. Repeat process a few times.
Analytical Method:
How much bandwidth does a typical SPE take during ‘normal operation’?
How much does it take with 128 temporary pointers assigned to another SPEs GPRs?
Results:
MultiCore Multi-Level Secure Experiment
Experiment Number: UI-09-016 / Processor: IBM Cell BE
Unit(s) being tested: SPE privilege state supervisor register & MMIO registers / Violation: Registers deal with the mailbox system.
Synopsis:
The Mailbox system was put in place so that an SPE could flag the PPE down in a sense to inform the PPE that it was either ready for a new task, or was finished with an existing task. The Cell Manual is unclear as to which registers hold this “flag” so to speak. The idea behind this test is to monitor these registers get set/act as the “mailbox”. Then once we know this, test 2 is to create temporary pointers to another SPEs “mailbox” register and force the other SPE to flag the PPE at inappropriate times stating that it is finished when it is not really finished with a task.
Materials Needed:
Script to monitor the “mailbox” system so we can learn which registers get used.
Script to create temporary pointers to another SPEs “mailbox”, send inappropriate flags< and free the temporary pointer.
Methodology:
Setup:
Part 1: Install the Monitor Script……(we must learn which registers are used for the “mailbox”)
Part 2: write and Install the manipulative script.
Procedure:
1. Execute the Script to watch the “mailbox” and output the resulting registers.
2. Write Manipulative Script with this information.
3. Execute the Manipulative Script, with the desired calls to inappropriately flag the PPE of that SPEs progress.
Specific Runs:
To see if we can create pointer such that, as an SPE, we can simulate the ownership of another SPEs “mailbox” registers.
Program Specifics:
Send inappropriate flags to the PPE every 1, 10, 100, 1000, seconds trying to get the other SPE to crash.
Analytical Method: (question to be answered)
How secure are the “mailbox” registers?
Can they be hacked such that 1 SPE could shut down another SPE?
Results: