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.
- "If a server has a buffer overflow vulnerability, that means the
server definitely has a bug."
- "Buffer overflow vulnerabilities can be ruled out by making the
stack non-executable."
- "Buffer overflow vulnerabilities can be ruled out by making program
text read-only."
- "Buffer overflow vulnerabilities can be ruled out with the W XOR X
security policy."
- "Buffer overflow vulnerabilities can be eliminated with ASLR
(address space layout randomization)."
- "Buffer overflow vulnerabilities are not possible on a 64-bit
architecture."
- "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:
-
The relationship
between the keys and the cars is that key 0 operates cars 0 and 1,
key 1 operates cars 2 and 3, etc. That is, key i works for
cars 2i
and 2i+1.
-
If a key is being used to operate one car, it cannot be used
to operate the other.
- A driver requests a particular car (which
implies that the driver needs a particular key). However, there may be many
more drivers than cars. If a driver wants to
go driving but cannot get its desired car or that car's key, it waits until the
car and key become available.
When a driver finishes driving, it returns its key and notifies any drivers
waiting for that key that it is now free.
-
You must allow multiple drivers to be out driving at once, and
you must not have busy waiting or spin loops.
- We repeat: there could
be many, many instances of driver() running, each of which
you can assume is in its own thread, and all of which use the same
monitor, mon.
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]