I've been long thinking about an ideal free secure open source OS.
Now here's a tough question I haven't been able to resolve.
I absolutely demand the universal freedom to know.
Yet I do not want the bad guys to take over computers.
I want to be able to hack my computer myself.
I want nobody else to be able to hack it.
How do I achieve both? Where's the balance?
I do not know. If you do know I'd like to hear from you.
Tuesday, 7 February 2012
Need for an open-source mainstream capability-based OS
Sander Temme wrote:
Barrelfish?
A secure OS gotta be capability based.
It's gotta be peformant on multi-cpu boxes.
Barrelfish might be both.
Warning: capability based OS can be really restrictive.
It can be very non free (RMS will hate it).
Remote attestation peformed by a TMP chip is the issue.
BIOS tells the TPM chip the hashcode of the OS. The OS tells the chip the hashcode of your movie player. TPM chip signs the hashcode with a secret key. An MPAA member checks the signature against a database of all TPMs ever produced. If satisfied it provides you with a personal copy of a movie. To watch the movie you need a one-off key. This key is given to you. But the key is itself encrypted. Only your TPM can decrypt it. And your TPM will only decrypt it if correct hash-sums have been provided to it after the last machine restart. Unless BIOS has been broken a 3rd party can really verify what software you're running!
The only reason this is not happening now is that a myriad of drivers are running in kernel mode. It is not possible to check that your particular combination of drivers + OS comply with MPAA requirements.
But with a capability based OS there would be a very small OS core.
And it would be possible to sign it.
The 3rd parties would be able to check that it hasn't been hacked or deny useful services.
The TMP chips would lock us from our own computers!
We would no longer have the freedom to hack, the freedom to know.
Solution?
Programmers of good will should create a practical capability based OS
before commercial vendors do. They should make it so popular that nobody in
a right mind would want to repalce it with a commercial alternative.
And it should be both secure and free.
Free as in GPL v3.
Free as in free to hack.
Both secure and free to hack. That's a challenge. More on this later.
This situation paints for me the following picture: a tap is running, malware flowing like water into a sieve and onto the floor. The security industry is frantically mopping the floor, trying to stem the flow of malware. They are paid well for their trouble, but meanwhile the expensive rug that represents your business is getting awfully wet. It would be nice if someone could turn off the tap, or design an operating system that doesn’t leak like a sieve
Barrelfish?
A secure OS gotta be capability based.
It's gotta be peformant on multi-cpu boxes.
Barrelfish might be both.
Warning: capability based OS can be really restrictive.
It can be very non free (RMS will hate it).
Remote attestation peformed by a TMP chip is the issue.
BIOS tells the TPM chip the hashcode of the OS. The OS tells the chip the hashcode of your movie player. TPM chip signs the hashcode with a secret key. An MPAA member checks the signature against a database of all TPMs ever produced. If satisfied it provides you with a personal copy of a movie. To watch the movie you need a one-off key. This key is given to you. But the key is itself encrypted. Only your TPM can decrypt it. And your TPM will only decrypt it if correct hash-sums have been provided to it after the last machine restart. Unless BIOS has been broken a 3rd party can really verify what software you're running!
The only reason this is not happening now is that a myriad of drivers are running in kernel mode. It is not possible to check that your particular combination of drivers + OS comply with MPAA requirements.
But with a capability based OS there would be a very small OS core.
And it would be possible to sign it.
The 3rd parties would be able to check that it hasn't been hacked or deny useful services.
The TMP chips would lock us from our own computers!
We would no longer have the freedom to hack, the freedom to know.
Solution?
Programmers of good will should create a practical capability based OS
before commercial vendors do. They should make it so popular that nobody in
a right mind would want to repalce it with a commercial alternative.
And it should be both secure and free.
Free as in GPL v3.
Free as in free to hack.
Both secure and free to hack. That's a challenge. More on this later.
Wednesday, 18 May 2011
I want spring's <util:property-path path="..."/> to become simply path="..."
Hi,
I have recently discovered a great feature in Spring:
However I do want an improvement. I want a yet more concise syntax for this. Spring can already do this:
I have recently discovered a great feature in Spring:
<property name="propertyToSet">This is much nicer in my opinion than
<util:property-path path="aBean.aProperty"/>
</property>
<property name="propertyToSet">It is also more powerful because you can do things like
<bean factory-bean="aBean" factory-method="getAProperty"/>
</property>
<property name="propertyToSet">which otherwise would have been awkward.
<util:property-path path="aBean.aProperty.aNestedProperty"/>
</property>
However I do want an improvement. I want a yet more concise syntax for this. Spring can already do this:
<property name="aPropertyToSet" value="true"/>So it would only be logical (and very-very nice!) if it could also do this:
<property name="aPropertyToSet" ref="anotherBean"/>
<property name="propertyToSet" path="aBean.aProperty"/>
Wednesday, 17 November 2010
Political Action Needed For Net Neutrality In The UK
Government wants to abolish net neutrality in the UK. Not a piece of good news. I really like the way Siva has said it:
I expect to see a political campaign started against this motion, similar to NO2ID. This I will wholeheartedly support.
There are a couple of different ways to look at this. The romantic way is that we want to have the Internet as the wild frontier for entrepreneurship, and that's a strong case. There's also the liberal free speech argument, which says we want the Internet to be a level playing field so a variety of voices can enter the public sphere. That's a fairly strong argument. But then you've got the economic argument, which is those of us who write checks every month to these companies, we want to be able to know that we are getting decent service for what we're paying. If my broadband company next week starts dialing down my Skype speed so Skype doesn't work as well for me, I might not even know it or notice it for a long time, until Skype starts frustrating me, and out of frustration, I'm just going to pick up my old phone and dial India the old-fashioned way and just pay for it because I know the call's going to go through. That's the sort of frustration and opacity we might start seeing on the Internet. So it is a service question, a competition question, an economic development question, a consumer question.
I expect to see a political campaign started against this motion, similar to NO2ID. This I will wholeheartedly support.
Saturday, 7 August 2010
Hamcrest 1.1, AllOf, DSL, SuppressWarnings And Maven Central
Hi,
I've never used Hamcrest before; today is my first day with it. And I have already had a lot of "fun" which I would like to share.
My experiences today have been centred around the AllOf matcher. Or rather around this version shipped with Hamcrest 1.1. This is the newest version you can find on Maven central. It also seems to be built into the newest JUnit jar version 4.8.1.
Imagine that in your test you've got variable a of type A and you want to check it against three matchers m1, m2 and m3 of type Matcher<A>. It was quite natural for me to write it like this:
That works and looks nice. But you get a compiler warning: Type safety : A generic array of Matcher is created for a varargs parameter. I have found this blog post to be very helpful in explaining the nature of this warning. The quickest solution is to write:
However it would be nice if we could preserve full type checking in the test code. It took me a while to find an alternative solution:
This is fully type checked. Unfortunately it is a bit more long-winded and we looses the DSL feeling. On a side note this code can not be shortened to just:
This sample deceptively looks as legit as the one above it. However it fails to compile because of a Type mismatch: cannot convert from List<Matcher<A>> to List<Matcher<? extends A>>.
I've had to discovere all this the hard way because in Hamcrest 1.1 AllOf.allOf is defined as:
My day would have been saved if I had switched to Hamcrest 1.2. Nat Pryce has fixed the issue in revision 258. We get explicit overloads of allOf method for up to 6 matchers in one go. This makes my very first code sample compile and run without any warnings.
It is also interesting to note that shortly before this commit another issue had been corrected in Hamcrest codebase: revision 194. Matcher<? extends A> has been replaced with Matcher<? super A>. This is most reasonable: indeed we can apply a Matcher<Object> to test a String. On the other hand it is not very useful to apply a Matcher<SomeClassExtendingA> when our object is known to be of class A.
1.2 release of Hamcrest contains both fixes. Unfortunately it is only available on the project website but not on Maven central. Having spent quite a bit of time on the investigation what do I do now? I see three options:
I have chosen the last option. This is my temporary fix. It makes my test code look nice right now and I can easily take out my hack later when a newer Hamcrest appears on Maven central.
Speaking of which: to use an updated version of Hamcrest I will need a version of JUnit which doesn't package hamcrest classes inside its own jar. Such a version exists, it is called junit-dep. Unfortunately the latest version Maven central currently has is only 4.5. Does anybody know of any way to cause a newer version of junit-dep to be uploaded? As far as I can tell there is just one person behind JUnit, Kent Beck. Is this right? Is there any chance to accomplish this with or without his help?
I've never used Hamcrest before; today is my first day with it. And I have already had a lot of "fun" which I would like to share.
My experiences today have been centred around the AllOf matcher. Or rather around this version shipped with Hamcrest 1.1. This is the newest version you can find on Maven central. It also seems to be built into the newest JUnit jar version 4.8.1.
Imagine that in your test you've got variable a of type A and you want to check it against three matchers m1, m2 and m3 of type Matcher<A>. It was quite natural for me to write it like this:
import static org.hamcrest.core.AllOf.allOf;
import static org.junit.Assert.assertThat;
...
@Test
public void testA() {
...
assertThat(a, allOf(m1, m2, m3)); // here you get a warning
}
That works and looks nice. But you get a compiler warning: Type safety : A generic array of Matcher is created for a varargs parameter. I have found this blog post to be very helpful in explaining the nature of this warning. The quickest solution is to write:
@Test
@SuppressWarnings("unchecked")
public void testA() {
...
assertThat(a, allOf(m1, m2, m3));
}
However it would be nice if we could preserve full type checking in the test code. It took me a while to find an alternative solution:
@Test
public void testA() {
...
List<Matcher<? extends A>> matchers
= new LinkedList<Matcher<? extends A>>();
matchers.add(m1);
matchers.add(m2);
matchers.add(m3);
assertThat(a, allOf(matchers));
}
This is fully type checked. Unfortunately it is a bit more long-winded and we looses the DSL feeling. On a side note this code can not be shortened to just:
@Test
public void testA() {
...
// doesn't compile
List<Matcher<? extends A>> matchers = Arrays.asList(m1, m2, m3);
assertThat(a, allOf(matchers));
}
This sample deceptively looks as legit as the one above it. However it fails to compile because of a Type mismatch: cannot convert from List<Matcher<A>> to List<Matcher<? extends A>>.
I've had to discovere all this the hard way because in Hamcrest 1.1 AllOf.allOf is defined as:
public static Matcher allOf(
Matcher<? extends T>... matchers) {
return allOf(Arrays.asList(matchers));
}
public static Matcher allOf(
Iterable<Matcher<? extends T>> matchers) {
return new AllOf(matchers);
}
My day would have been saved if I had switched to Hamcrest 1.2. Nat Pryce has fixed the issue in revision 258. We get explicit overloads of allOf method for up to 6 matchers in one go. This makes my very first code sample compile and run without any warnings.
It is also interesting to note that shortly before this commit another issue had been corrected in Hamcrest codebase: revision 194. Matcher<? extends A> has been replaced with Matcher<? super A>. This is most reasonable: indeed we can apply a Matcher<Object> to test a String. On the other hand it is not very useful to apply a Matcher<SomeClassExtendingA> when our object is known to be of class A.
1.2 release of Hamcrest contains both fixes. Unfortunately it is only available on the project website but not on Maven central. Having spent quite a bit of time on the investigation what do I do now? I see three options:
- use the long-winded version of code
- wait for Hamcrest 1.2 to be uploaded to Maven central
- copy-paste AllOf into my own code base and backport these two fixes
I have chosen the last option. This is my temporary fix. It makes my test code look nice right now and I can easily take out my hack later when a newer Hamcrest appears on Maven central.
Speaking of which: to use an updated version of Hamcrest I will need a version of JUnit which doesn't package hamcrest classes inside its own jar. Such a version exists, it is called junit-dep. Unfortunately the latest version Maven central currently has is only 4.5. Does anybody know of any way to cause a newer version of junit-dep to be uploaded? As far as I can tell there is just one person behind JUnit, Kent Beck. Is this right? Is there any chance to accomplish this with or without his help?
Sunday, 2 August 2009
shoal/jxta - any good?
Hi,
looking for re-usable code to drive a clustered java application.
Shoal promises
Deal? Invest more effort? Hold on! Here's their list of open bugs
Does it look easier just to write my clustering code from scratch?
looking for re-usable code to drive a clustered java application.
Shoal promises
- peers discovery
- group membership
- group messaging
- small replicated cache
Deal? Invest more effort? Hold on! Here's their list of open bugs
- (36) Messages received not in same order as when sent
- (61) When members join the group concurrently, join notifications of some members are often duplicated or missed
- (74) potential to miss FAILURE_NOTIFICATION when multiple instances killed at same time
- (83) When group leader failed, any member couldn't receive FailureRecovery notification
1.1 is said to be a "work in progress".
So is 1.0 okay? I don't know
Another oddity: a CVS commit message seems to imply (83) has been fixed.
But it's still open in the issue tracker
Jxta - the foundation of Shoal - is another unknown.
When I troubleshoot late at night I prefer to have an intimate knowledge of my whole stack.
Jxta is another big (?) thing to learn. Thankfully sources are available but still..
Does it look easier just to write my clustering code from scratch?
Implement proper Paxos?
Be less dependent on other people's bugs?
P.S. I've had a look at Geronimo clustering as well. They allow Cache servers to be in separate jvm-s. Hmm.. Somehow my intuition doesn't immediately suggest integrating that code is an easy route either..
P.P.S. Zookeeper was another obvious candidate. What stops me here is that Zookeper seems to have a very hard dependency on disk. Every change is persisted. Node recovery is done by reading the transaction log. It's a mismatch for my goals. I need something blazingly fast living completely in RAM
Friday, 12 December 2008
eclipse -clean
Hi! I've got an irresistable urge to share this.
eclipse -clean
cleans eclipse caches and can make a very stubborn build error go away.
I've had a "resource already exists on disk" in a m2eclipse driven project. Deleting the file manaully/refresh/clean/close-open-project did not help. workspace/.metadata/.log contained a lot of ClassCastException-s.
But closing Eclipse and re-running it as "eclipse -clean" did help.
eclipse -clean
cleans eclipse caches and can make a very stubborn build error go away.
I've had a "resource already exists on disk" in a m2eclipse driven project. Deleting the file manaully/refresh/clean/close-open-project did not help. workspace/.metadata/.log contained a lot of ClassCastException-s.
But closing Eclipse and re-running it as "eclipse -clean" did help.
Subscribe to:
Posts (Atom)