If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

I just found the Phoronix article about the Asus Chromebook C720 and thought to myself that this netbook might be the ideal replacement for my old Asus EeePC 901 netbook. So I checked it out and found that it uses an Intel Celeron 2955U processor. This particular CPU lacks AES-NI support. But especially for netbooks with ULV and LV processors (which in general are not very fast) AES hardware instructions would be very helpful to keep good overall performance when using encrypted partitions.

So, I refrain from this idea to get the Asus Chromebook.

I am still looking for a netboot that meets the following criteria:

Architecture: x86 i.e. IA-32

Firmware: Coreboot, but with the possibility to add SeaBIOS or Tiano Core for Windows compatibility

OS: Arch Linux or Debian GNU/Linux, but using LUKS to encrypt everything. Windows is planned only as a second OS if at all, but then unencrypted.

The only CPU I found that fullfils these wishes is an Intel Core i3-4010U like in the Acer Aspire E1-572-34014G50, but it doesn't come with Coreboot. Well, it doesn't come with ChromeOS either.

So, my question is, if anyone of you know of and may recommend a netbook that uses Coreboot, is flashable (to open up Coreboot for the SeaBIOS payload) and has a CPU with AES-NI and VT-x/AMD-V?

Thanks in advance,
luttztfz

No modern CPU has x86 architecture
IOMMU is dependant on motherboards firmware and thats precisely the thing which notebook manufacturers dont give shit about
From security standpoint it might be better not to use AES-NIhttp://www.truecrypt.org/docs/hardware-acceleration

Anyway, I already figured that no such netbook exists. Maybe I'll have to stick to the mainstream Windows stuff and just but Linux on it. A Chromebook with a free and open firmware (i.e. BIOS) would have been a dream come true...

I don't understand. My older G4 CPU is non-x86 while my more modern AMD Phenom X6 is x86.

Your modern Phenom provides an x86 instruction set to the outside, but internally it translates it to some simpler instruction set which can be more efficiently executed. I don't think the distinction is very useful in this particular discussion.

Originally Posted by luttztfz

I get that. So Linux will not be able to use the IOMMU with a Coreboot firmware because it is hard to implement, right?

No, it can't use IOMMU because that's a hardware feature that just isn't there. coreboot can't call hardware into existence, it can merely configure hardware that is already around. (Though in the case of that i3 you picked, it actually contains an IOMMU: look for VT-d on http://ark.intel.com/products/75107)

Originally Posted by luttztfz

I just read that and don't find any security concerns.

The problem is that you don't know what side effects the crypto hardware has: The random number generator might not be quite as random as you'd wish (but exactly as non-random as an adversary planned it). The AES crypto might keep parts of your key in accessible registers that you don't know about, so other processes on the same machine can read out keys.

While possible, both scenarios are relatively unlikely. It's something to keep in mind however (and worry about some more if you're operating in a security conscious context).

Your modern Phenom provides an x86 instruction set to the outside, but internally it translates it to some simpler instruction set which can be more efficiently executed.

Actually I was aware of that. It just doesn't change anything about the architecture to the outside, which is x86. And such a CPU is modern nevertheless. But you're right, it doesn't concern this discussion.

Originally Posted by pgeorgi

No, it can't use IOMMU because that's a hardware feature that just isn't there. coreboot can't call hardware into existence, it can merely configure hardware that is already around.

I was referring to the statement that the IOMMU has to be supported (= implemented in code) in the firmware as well as the (logical) pre-condition of being supported (also: implemented) by the hardware. Means: if the CPU supports an IOMMU but the firmware hasn't code to initialize and/or indicate its presence to an operating system, it won't be usable.

Originally Posted by pgeorgi

The problem is that you don't know what side effects the crypto hardware has: The random number generator might not be quite as random as you'd wish (but exactly as non-random as an adversary planned it). The AES crypto might keep parts of your key in accessible registers that you don't know about, so other processes on the same machine can read out keys.

While possible, both scenarios are relatively unlikely. It's something to keep in mind however (and worry about some more if you're operating in a security conscious context).

My security context is that if I loose the damn thing, no one else should be in the position to read my data. I am aware that my data will be in a thiefs/finders hands nevertheless, but until s/he has the means to decrypt it, my data will be outdated and (stored) (online) passwords will be changed (because I changed them).

What you say is true for any cryption/decryption, because without the hardware AES functions all this will be implemented in software with basically the same set of problems. The initial AES key may well be done without the hardware random number generator or without relying exclusively on it: I'm rather thinking about using /dev/urandom (and provinding lots of MY OWN user random data for it). At least that is how I understand all this crypting of data thing.