Page 2 of 2 FirstFirst 12
Results 11 to 14 of 14

Thread: Coreboot Gets Support For Haswell Power Limiting

  1. #11
    Join Date
    Mar 2012
    Posts
    184

    Default

    Quote Originally Posted by luttztfz View Post
    Hello!

    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.
    • CPU: AES-NI (AES encryption instructions) and VT-x/AMD-V (hardware virtualization support)

    Optional, but preferred are the following CPU features:
    • SSE4.1/4.2 and AVX (2.0)
    • VT-d or AMD-Vi (IOMMU)


    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-NI
    http://www.truecrypt.org/docs/hardware-acceleration

  2. #12
    Join Date
    Dec 2013
    Posts
    3

    Default

    Quote Originally Posted by Ramiliez View Post
    No modern CPU has x86 architecture
    I don't understand. My older G4 CPU is non-x86 while my more modern AMD Phenom X6 is x86.
    Quote Originally Posted by Ramiliez View Post
    IOMMU is dependant on motherboards firmware and thats precisely the thing which notebook manufacturers dont give shit about
    I get that. So Linux will not be able to use the IOMMU with a Coreboot firmware because it is hard to implement, right?
    Quote Originally Posted by Ramiliez View Post
    From security standpoint it might be better not to use AES-NI
    http://www.truecrypt.org/docs/hardware-acceleration
    I just read that and don't find any security concerns.

    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...

    Thanks for your reply.

  3. #13
    Join Date
    Jan 2013
    Posts
    21

    Default

    Quote Originally Posted by luttztfz View Post
    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.

    Quote Originally Posted by luttztfz View Post
    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)

    Quote Originally Posted by luttztfz View Post
    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).

  4. #14
    Join Date
    Dec 2013
    Posts
    3

    Default

    Quote Originally Posted by pgeorgi View Post
    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.

    Quote Originally Posted by pgeorgi View Post
    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.

    Quote Originally Posted by pgeorgi View Post
    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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •