CSCI-UA.0202 Spring 2015 Homework 10

Handed out Friday, May 1, 2015
Due 10:00 AM, Friday, May 8, 2015

Homework 10

These problems should be done on your own. We're not going to be grading them strictly (we'll mainly look at whether you attempted them). But they will be reinforcing knowledge and skills, so you should totally work through them carefully.

Buffer overflow vulnerabilities

For the statements below, please state whether they are true or false. Justify each answer.
  1. "If a server has a buffer overflow vulnerability, that means the server definitely has a bug."
  2. "Buffer overflow vulnerabilities can be ruled out by making the stack non-executable."
  3. "Buffer overflow vulnerabilities can be ruled out by making program text read-only."
  4. "Buffer overflow vulnerabilities can be ruled out with the W XOR X security policy."
  5. "Buffer overflow vulnerabilities can be eliminated with ASLR (address space layout randomization)."
  6. "Buffer overflow vulnerabilities are not possible on a 64-bit architecture."
  7. "If a buffer overflow vulnerability is exploited, this implies that the attacker has changed %cr3."

Unix's protection model

Why does the program passwd (which ordinary users are allowed to invoke) need to be a setuid program?

Monitors Review

In this problem, you will implement a monitor to help a set of drivers (modeled as threads) synchronize access to a set of five keys and a set of ten cars. Here is the problem setup:
Below, fill in the monitor's remaining variable(s) and implement the monitor's take_key() and return_key() methods. Follow the coding standards given in class.
typedef enum {FREE, IN_USE} key_status;

class Monitor {
    public:
        Monitor() { memset(&keys, FREE, sizeof(key_status)*5); }
        ~Monitor() {}
        void take_key(int desired_car);
        void return_key(int desired_car);
    private:
        Mutex mutex;
        key_status keys[5]; 
        /* ADD MATERIAL BELOW THIS LINE */ 




};

void driver(thread_id tid, Monitor* mon, int desired_car) {
     /* you should not modify this function */
     mon->take_key(desired_car);
     drive();
     mon->return_key(desired_car);
}

void Monitor::take_key(int desired_car) {
     /* FILL IN THIS FUNCTION. Note that the argument refers
        to the desired car. */








}

void Monitor::return_key(int desired_car) {
     /* FILL IN THIS FUNCTION. Note that the argument refers
        to the desired car. */








}

Concurrency Review

Consider the following implementation of a spinlock:

struct Lock {
    int locked;
}
int exchange_value(int* ptr, int val) {
    int was;
    was = *ptr;
    *ptr = val;
    return was;
}
void acquire(Lock *lock) {
    pushcli();    /* disable interrupts */
    while (1) {
        if (exchange_value(&lock->locked, 1) == 0)
            break;
    }
}
void release(Lock *lock){
    exchange_value(&lock->locked, 0);
    popcli();   /* re-enable interrupts */
}

Assume that the machine provides sequential consistency. The functions pushcli() and popcli() disable and re-enable interrupts, respectively.

Is the code correct? If the code is correct, explain what invariant is maintained. If the code is not correct, give a problematic interleaving and explain why it is problematic.

Handing in the homework

Use NYU Classes; there's an entry for this homework.


Last updated: Mon May 04 19:20:48 -0400 2015 [validate xhtml]