Re: cpu scaling
On 06/13/2012 03:27 PM, Matej Kosik wrote:
Hello,
On Fedora 16, CPU scaling works fine for me.
From this I assume you're now using F17 as you seem to suggest it
doesn't work fine anymore, but I believe everything holds for F16 as well.
On Debian, I was able to determine minimal/maximal frequencies of CPU-s
by looking to files like this:
cat /sys/devices/system/cpu/cpu*/cpufreq/scaling_{min,max}_freq
Is there a way how can I do the same on Fedora?
Well.. yes?
[thib@dhow ~]$ cat
/sys/devices/system/cpu/cpu*/cpufreq/scaling_{min,max}_freq
/etc/redhat-release; uname -a
80
80
2534000
2534000
Fedora release 17 (Beefy Miracle)
Linux dhow 3.4.0-1.fc17.x86_64 #1 SMP Sun Jun 3 06:35:17 UTC 2012 x86_64
x86_64 x86_64 GNU/Linux
Is there a way how can I determine that CPU scaling is turned on,
on a given machine?
This might be of interest:
https://docs.fedoraproject.org/en-US/Fedora/17/html/Power_Management_Guide/Core_Infrastructure.html
--
t
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org
Re: Checking which application is taking bandwidth
On 06/14/2012 09:16 PM, Kevin Martin wrote: Correct me if I'm wrong but isn't "ss -p" essentially the same as the older "netstat -anp"? net-tools (including netcat) are somewhat deprecated in favor of iproute2 programs (which include ss as a netcat replacement) in some circles. -- t -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: What's wrong with this /etc/fstab ?
Maybe try ntfs-3g? I'm not really up-to-date on what's the default NTFS driver now, but I know this used to be some kind of mess. # mount -t ntfs-3g Options[0] may be different. [0] http://www.tuxera.com/community/ntfs-3g-manual/ -- t -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: Red Hat Will Pay Microsoft To Get Past UEFI Restrictions
On 06/05/2012 01:29 PM, Alan Cox wrote: On Tue, 05 Jun 2012 06:47:24 -0400 Sam Varshavchik wrote: Don't worry about. Microsoft will make sure that the OEM knows exactly how to implement the ability to install keys for other operating systems. They seem quite averse to that actually. UEFI itself cannot really tackle it because UI is out of the UEFI remit (and as I understand it always has been) I think he was being sarcastic. -- t -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: Red Hat Will Pay Microsoft To Get Past UEFI Restrictions
On 06/05/2012 12:46 PM, Sam Varshavchik wrote: Thibault Nélis writes: Supposing your OEM isn't abusing his powers and respects Microsoft's requirements if it's an x86 platform, you should be able to add your own key in the firmware, which will be used to verify the boot loader. And I would also like a pony, too. Sheep; slaughter; etc… I think there's a point where thoughtful skepticism and criticism turn into plain negativity. I'm not saying you reached it, but I don't know what you're trying to achieve with these kinds of comments either. If it's to warn people that every OEM on the planet has bad intentions or is weak and bought by Big Bad Corp, I think they kind of got that from earlier posts. In any case, I'd be happy to talk about all this in a year or two, when we'll have more information than speculations. (Don't worry I'm not offended or anything, I'm just saying we don't know jack yet.) -- t -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: Red Hat Will Pay Microsoft To Get Past UEFI Restrictions
On 06/05/2012 08:02 AM, JD wrote: So, will there be a document that will accompany the ISO, advising the user what key to insert into the firmware so that the firmware will be able to authenticate the boot loader? I don't know if this has been discussed somewhere at Fedora, but I would assume the documentation will be updated to mention this at some point, and you'll probably get some help in f18 release notes too. You could raise the issue with the documentation team if it hasn't been already. The main problem is that the UEFI spec doesn't describe a standard UI to do this AFAIK, so every hardware vendor might implement it in a different way. If the process varies too much from user to user, Fedora might prefer to simply refer the user to the firmware's documentation. In any case, this information will be freely accessible somewhere, and I suspect some open source tools will also appear to assist if necessary. -- t -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: Red Hat Will Pay Microsoft To Get Past UEFI Restrictions
On 06/05/2012 05:20 AM, JD wrote: Well, I was thinking of distros. Since I will not be the creator of the Linux ISO which I will be downloading and burning onto a DVD, how can I create those keys and insert them into the DVD without going through the whole rigmarole of building the OS and the whole ISO in the first place? At least, this is how I understand how this is supposed to work. If I am wrong, perhaps Alan Cox or Thibault Nelis, or Sam Varshavchik can elucidate. Supposing your OEM isn't abusing his powers and respects Microsoft's requirements if it's an x86 platform, you should be able to add your own key in the firmware, which will be used to verify the boot loader. If this thing is well designed (I assume it is), you won't have to flip a single bit on the boot loader and certainly not rebuild it (provided it does support secure boot in the first place). -- t -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: Red Hat Will Pay Microsoft To Get Past UEFI Restrictions
On 06/05/2012 04:47 AM, Kevin Fenzi wrote: On Mon, 04 Jun 2012 18:06:24 -0700 JD wrote: On 06/04/2012 05:03 PM, Sam Varshavchik wrote: This has been explained in this thread before. It is logically impossible to have a so-called "secure-boot" for both a free OS and a non-free OS on the same platform. Since, by definition, a free OS allows unrestricted access to the hardware, a free OS can then be trivially used to bypass any secure boot hardware restrictions for a non-free OS. I'm not following your logic there... Because there's none. Not sure I want to argue again, so let's just say Sam and I have different interpretations of the facts. In mine, it is perfectly possible to have multiple keys in the same firmware at the same time, and perfectly possible to securely dual-boot systems. For this to work, you can't have a universal key for free OSes (or any OS) as Sam rightly points out, which is why every OS must have a key of its own in every device (not realistic in practice) or obtain a signature from a "certificate authority", "trust broker", or "intermediary" (whatever you want to call it) whose sole job is to verify that every OS it signs is doing a good job at securing itself so that it won't be used to chainload the others. To do such a job, you'd want an intermediary that you can trust, and that is unbiased, which is not the case with Microsoft (and which is the basis of this whole controversy), because whenever someone shows signs that it isn't willing to plug its known security holes, the intermediary should blacklist its key. The reason is that the trust relationship is broken. The effect is that its users won't be able to use secure boot with that key anymore, and will either have to find another intermediary that is willing to trust the OS developers, or let the users sign it themselves, provided they themselves trust the OS developers, which is hopefully the case for any OS. If users don't trust their own OS, they will migrate and this OS will be doomed anyway (not talking about Windows and Mac users, who don't have alternatives like we have with our different distributions). No one has wanted to be this 'authority'. Perhaps someone will come out appear now given all the press. Precisely. I'd like to add something I haven't seen in explained clearly anywhere yet: Microsoft really didn't have to provide signatures for $99. If they hadn't, other operating systems would be *forced* to do the right thing and provide this service themselves or pay another organization to do it (if they want a zero-config secure boot out of the box, that is, anyone can still provide secure boot without all the hassle, but users would have to configure it). Now we already argued about why they would do it, and I believe they have many reasons (control, a little income, being first in a potential new market). -- t -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: Red Hat Will Pay Microsoft To Get Past UEFI Restrictions
On 06/05/2012 05:10 AM, JD wrote:
I wonder if China will go along with the MS plans!
Much of our HW is made in China. What's to prevent
China from inserting back door code in the HW? I
mean that would totally make secure boot a laughable
thing.
Well this scheme where the manufacturer inserts a stealth certificate
actually makes sense, unfortunately. Secure boot or no secure boot,
anyone concerned with security and privacy should always trust the
manufacturer of the hardware one uses, unless it is open hardware.
This is much like the difference between proprietary software and open
source software, where you need to trust the proprietary software
developer, whereas you don't need to for open source software (because
anyone, including you, can review the source).
>> But, I thought secure meant that the owner could secure access to the
>> machine any time he wanted. The owner is the manufacturer, isn't it?
>>
>> {O.o}
> I have not seen your assertion made by anyone in this thread,
> especially when it comes to MS and windows.
> Surely, it is possible (or should be possible) to make and install
> your own keys for any of the open source OS'es. Perhaps Sam or
> Thibault or Alan will have more to say about this.
In the context of motherboards, a good OEM would allow you to install
your own keys. Microsoft's "Windows Ready" requirements for OEMs also
force them to provide this "custom mode" feature (the document is freely
available), but only for x86 platforms.
--
t
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org
Re: Fedora 15 versus 17, files missing on the same filesystem
Okay, so just to be clear, you mean that you have *not* copied files
from a f15 filesystem to a new f17 system, but actually have copied
files (with a file manager, GNOME Nautilus) from an external system to a
unique filesystem that is used by both f15 and f17 that you dual-boot on
the same disk.
If that's the case, that is very weird indeed.
You may try:
$ (cd $MOUNTPOINT && find -type f -exec md5sum {} \;) |tee CHECKSUMS
Replacing $MOUNTPOINT with the path to your mount point directory path
of course. This creates a file named CHECKSUMS in the current
directory. Generate one from both systems, then use:
$ diff path/to/first/CHECKSUMS path/to/second/CHECKSUMS
To see if the contents of the files actually changed.
--
t
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org
Re: Red Hat Will Pay Microsoft To Get Past UEFI Restrictions
On 06/04/2012 12:22 PM, j.witvl...@mindef.nl wrote: -Original Message- From: users-boun...@lists.fedoraproject.org [mailto:users-boun...@lists.fedoraproject.org] On Behalf Of JD So, if all the linux distros put their "heads" together and create a single Linux signature authority, which will serve all the distros, and be funded largely by the industry (which sell linux servers - such as IBM, among others), and other for-money linux distros, such as Red Hat; then this will go a long way towards making linux totally independent of MS as far as key signatures are concerned. That's what I believe yes. It will still be far from ideal, but then again, an ideal situation implies a dynamic WoT and would thus require educating users in basic trust management. Smart algorithms with sane default behavior and good UI can actually make this quite easy if appropriate metaphors are used, but the general consensus in the industry right now seems to be that "users are too stupid to understand these things". I tend not to agree, but that debate is quite heavy on its own (this is the reason why we're still stuck with PKI for the web by the way). So with that established mindset, the only solution is to force people to trust who the developer wants them to trust first, and then maybe offer them the choice to have their say if they're deemed intelligent enough to find the obscure certificate stores. This sounds bad, but it enables the process to be entirely automated and transparent for the user. Just like when visiting HTTPS websites; we don't have to worry about how many people in our web of trust actually do trust the owner of the certificate to be the owner of the domain, or about verifying a fingerprint on an side-channel (who picks up the phone to do that these days?). It just works (although at what cost?), so it is sort of better from a usability stand point, if we exclude the "I might not trust who I'm told I should trust and I might not like it" from the concept of usability. The way we implement this is by having predefined root certificates, quite simply. If the user actually trusts the owners of *all* the root certificates on his machine, then the model is actually fine. I think I'd trust Red Hat, SUSE, Canonical, the Linux Foundation, the FSF or the OSI way, way more than Microsoft for example. There's still the problem that typically one entity cannot be certified by multiple entities, and thus we have to include all root certificates for all certified entities we need to verify, and this quite invariably will include root authorities that we don't trust (in this case, the problem will most probably occur with other certified hardware in the machine, as pointed out elsewhere in this thread, but I think not with shims). Anyway, webs of trust and distributed social networking constitute nice food for thought IMO. In the meantime, we'll just have to go with good enough. -Original Message- Excuse me if I'm misunderstanding, But somehow it looks to me that we are forced in a direction we should not be heading to. Wasn't the whole idea behind this uefi-restrictions, to: a) improve Microsoft security record (fighting malware, rogue-drivers, worms, ...) b) Fighting illegal versions of Windows. Well I would hope not. UEFI is independent from Microsoft, and it looks like this spec is going to be implemented in a very wide range of devices in the near future. It's the *Unified* Extensible Firmware Interface, after all. The board comprises AMD, American Megatrends, Apple, Dell, HP, IBM, Insyde Software, Intel, Lenovo, Microsoft, and Phoenix Technologies[0]. Secure boot will also be useful for everyone. The goal is legit, but unfortunately it *is* very possible to subvert and abuse the technology, and to make it into a revival of Palladium, which is why everyone ought to, I think, take a look at it and form an informed opinion before accepting it blindly (I know this won't happen for people on this list, but the rest of the world doesn't care as much) or refusing it outright. As long as you still can boot something else (I mean NON-microsoft) On x86, yes, on ARM, I think there will be blood (although Microsoft isn't nearly as big on ARM as they are on x86, people might just be able to ignore them and buy an alternative if they're smart). Just hope that "official" versions of W8, do not require such uefi-structure beneath them, otherwise you have a problem with vmware/kvm/xen. Indeed there could be a problem, but only if they plan to verify the firmware's integrity. Technically this is a challenge (since the firmware could make up a lie) and I don't think they have any plan to attempt that, it was just speculation AFAIK. [0] http://www.uefi.org/about/ -- t -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guid
Re: ucview
On 06/02/2012 12:37 PM, François Patte wrote: Bonjour, Bonjour! I installed ucview to record images from a webcam. It stops recording after 2,2 GB. At 2,147,483,647 exactly? That looks like a classic 32-bit signed integer overflow. Is that the normal behaviour? If that's what it looks like, then no, and in such case I would suggest checking versions, then probably filing a bug report (after verifying if one doesn't exist already). Thanks for lights! Good luck. -- t -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: proposal to Fedora/Redhat for fedora 18
On 06/02/2012 07:11 PM, Joe Zeff wrote: Changing it in the UEFI interface before boot sounds much more reasonable, A post in the other thread suggests that I might be wrong BTW, or at least that it would depend on the vendor. but please don't call me "Shirley." Roger, roger. -- t -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: puldeaudio cpu load
I'd say Flash doesn't have a great reputation (I assume plugin-container is running Flash here) and that's one the reasons why. I also have a constant load even when the video is paused, in the order of 0.7-1.3%. About PulseAudio though.. it's definitely not normal (at least I don't see that). I've never really debugged PA so I wouldn't know which tools to use to get more visibility, but I'm sure they have some information in their documentation. It probably won't take you very far, but you could also try PowerTOP, they have some tunables that might influence PA's CPU usage. -- t -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: How to know what is the device corresponding to a certain external disk?
Also, maybe this would suffice to identify them, in case you can't
install the package:
$ ls -l /dev/disk/by-{id,label}
--
t
--
users mailing list
users@lists.fedoraproject.org
To unsubscribe or change subscription options:
https://admin.fedoraproject.org/mailman/listinfo/users
Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
Have a question? Ask away: http://ask.fedoraproject.org
Re: Secure Boot UEFI (ARM)
Coreboot / TianoCore is indeed the way to go. Presentation from earlier this year (just Coreboot), for the interested: http://video.fosdem.org/2012/maintracks/janson/Coreboot.webm -- t -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: Fedora 15 versus 17, files missing on the same filesystem
Did you copy the data at the filesystem level or at the volume level? (In other words, did you copy the files themselves or the whole volume/partition block by block?) In the former case, I wouldn't worry too much, it might just be the result of the natural defragmentation of your files. To reassure yourself, you could use one of the many tools for comparing file trees, or a simple combination of `find', `diff' and maybe your preferred checksum tool if you have time. In the latter case, well, keep the backup a while longer until you figure it out. -- t -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: Red Hat Will Pay Microsoft To Get Past UEFI Restrictions
On 06/02/2012 07:24 PM, JD wrote: On 06/02/2012 10:08 AM, Joe Zeff wrote: I sure do! The only PC's I've ever owned that were pre-built were laptops. I'm not a hardware geek, but one of my friends is, and when it's time to upgrade, we get together, buy parts and he puts them together. I pay him with a tank of gas and a good, home cooked dinner because among other things, I'm a cooking geek. Thiebalt... What anattitude: "Do we care about them"... I to, like Joe Zeff, have assembled my dektops from bits and pieces that I could afford and were the best at the price I was willing to shell out. I think there must be thousands of nerds like us out there. But what do you care This is a first step of building a tyrannical system After the first step, the screws get tightened even further...step by step. Always try to find who stand to make bug bucks from initiatives like these. It's all about control and through control, charge fees and get filthy rich. Um, I think you're missing the point guys. I, too, assemble all my personal machines myself, and I find this not being a problem for me as I use Linux. Since we're on a Fedora mailing list, I kind of assumed we all were. However, I admit I should have formulated this very differently, especially since my next paragraph is about realizing this also affects hypervisors. And I apologize to the people who dual-boot whom I have unintentionally ignored. I did dual-boot for a long time too by the way (ever tried to make Microsoft's LDM friends with grub1?). -- t -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: Red Hat Will Pay Microsoft To Get Past UEFI Restrictions
On 06/02/2012 10:19 PM, Sam Varshavchik wrote: But I thought that this was the plan of action, isn't it? Sign a shim that boots Fedora. Presto, secured boot, with Microsoft's blessing. So, did you just change your mind, and realize that: 1) It makes no sense, and 2) Microsoft is not going to sign a shim that will boot an arbitrary Linux kernel, which can be trivially used to bypass the protection that a secured boot offers to their non-free OS? We're really talking about different things here I believe; from my point of view, I see you asking the question "When will a universal key that can boot any kernel?" in a very rhetorical way, as in, it will never happen because either the system is broken or Microsoft won't allow it (I'm not sure what you meant exactly, but I'm pretty sure it's one of those, correct me if I'm wrong). However, I argue that asking the question is a little wrong; if such a key would exist, secure boot would lose its purpose, and thus we shouldn't even desire such a key. But I'm kind of certain that you understand that very well already, which is why I'm out of words. In my opinion, a better question would be "When will alternative organizations to Microsoft will appear to offer the same services?", and with that one I'd actually worry they might never come, even though we need them. Yes, you're right, it does make sense. That would be considered blackmail Somehow, I don't think they'd care how it's called, on this mailing list. Believe me I truly realize how broken the legal system is, in pretty much every country currently. I'm just hoping there are a few laws that can be interpreted in a way that could recognize this as what it is [blackmail]. though, at least if these OEMs don't have the option to abandon Microsoft to sell their products to competitors. Could they even get away with it? Who would stop them? I don't exactly know; the SFLC, the EFF, the FSF, or heck, maybe the OSI (as I pointed out already they're kind of looking for things to do ATM apparently). If they start using secure boot in higher APIs, especially in the web for hypothetical applications that would require secure boot (as discussed in another branch of this thread), then the many privacy activism organizations could jump on board too. You've got to believe, there's still a lot of good people out there! Do we really care about them? Well, in the same way you'd care about someone sitting on the side of the road, all bloodied up, next to flaming, smoking wreck. You don't know them. They're of no personal interest to you. Still, as a human being, you would care somewhat. Maybe just a little. That's one of the things that makes you human. Yes, you're totally right, I didn't really mean it that way. I was merely trying not to "go there" because that opens an entirely new debate (that's not uninteresting at all, just potentially very long). I should have been either more subtle or more explicit about it, that was just ambiguous. -- t -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: proposal to Fedora/Redhat for fedora 18
On 06/02/2012 05:50 PM, Steve Dowe wrote: Does anyone know if the signed bootloader must be executed first before Secure Book can be disabled? Or would one just enter a BIOS-like config screen before any disc activity and disable it? Surely you can access the UEFI firmware interface before the boot loader, just like the BIOS SETUP yes. -- t -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: Red Hat Will Pay Microsoft To Get Past UEFI Restrictions
On 06/02/2012 04:34 AM, Sam Varshavchik wrote: Well the math doesn't compute here, it's cryptographically impossible. I mean you could sign a shim that won't verify the integrity of the boot There you go. Look I can't really go on on that. You seem to imply that this is a bad thing. I simply say that it doesn't make sense to want this in the first place. I don't know what to say. loader, but you would gain absolutely nothing from secure boot then, it makes as much as disabling it entirely. Let's rewind it back up a bit. The presumed purpose of a secure boot is to prevent bootloader-infecting malware. Once that out of the way, you're done with your secure boot. Proceed as usual. Not really, since you established yourself that a kernel can act as a boot loader in a lot of ways. Leaving the ability to infect the kernel or any software able to boot another OS is the same as leaving secure boot disabled, so simply disable it. Actually, it makes perfect sense. This is analogous to client certificate verification with TLS. mean it's not even a real catch-22, you won't ever boot the kernel before the firmware, so this is a non-issue. You need to put yourself into Microsoft's frame of mind. They're going in the direction of OEMs locking down their firmware to booting only Microsoft OSes. Now, the other shoe drops. In turn, some future Microsoft OS release will only boot on firmware that's signed by Microsoft's key. If it's not, the OS will refuse to boot, displaying a soothing message to the user that their hardware is incompatible. To make it compatible, OEMs will have to pay the same $99 fee for Microsoft to sign their firmware. Now you get it? Yes, you're right, it does make sense. That would be considered blackmail though, at least if these OEMs don't have the option to abandon Microsoft to sell their products to competitors. Could they even get away with it? Anyway, this would only affect OEMs and Windows users who want to install their copy of Windows on machines they assemble themselves (or in any way non-approved by Microsoft). Do we really care about them? I don't mean it in a bad way, but we've got enough to worry about already, that's an issue the FSF and the EFF might be interested in, not Fedora users. (If I did mean it in a bad way, I'd say these people could potentially become happy new Linux users :).) Who said anything about selling? In the next sentence, my reference to copyright infringement was not a throwaway line. In order to boot a future Microsoft OS release, in a future version of libvirt, you will need a signed firmware image, swiped from an OEM who paid the Microsoft tax, order for the Microsoft OS to boot in your VM. VMWare will have no issues paying a fee to Microsoft, for their VM firmware signed, of course. Oh, you're right, add the hypervisor developers to the previous list of affected people; I admit I didn't think of the VM side of things. Actually it would even be the responsibility of the distributors to sign the hypervisors in this world. These we should certainly care about, I agree. It's just that I see this a mile away. It's as clear a day. I have no particular passion towards Microsoft. I just want them to leave me the hell alone, that's all. I know what you mean. Well, I learned a lot. -- t -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: Red Hat Will Pay Microsoft To Get Past UEFI Restrictions
On 06/02/2012 04:28 AM, Sam Varshavchik wrote: Yes, all five of them. Point taken. [0] Yes, I found it, it was there all along, I guess I didn't look hard enough (or didn't listen properly): http://download.microsoft.com/download/A/D/F/ADF5BEDE-C0FB-4CC0-A3E1-B38093F50BA1/windows8-hardware-cert-requirements-system.pdf [search for secureboot, you'll find it easy enough] I never said that Microsoft would openly prohibit OEMs from offering an option to install user-provided keys. They key word here is "openly". How do you mean "openly"? It can't get much more open that a mandatory interface that let's you do it simply. What UEFI could do to make things better is standardize the UI, but that's it. Exactly, by ignoring them and using the services of other organizations. Well, that's one unique way to ignore them: it costs $99 to do that. Please try to stay with me, you can't have everything. If you can find somebody who's gonna keep a key safe and manage hundreds of customers (signing their shims) *and* make contracts with as much OEMs as possible to get their own key in the firmwares for *you*, for *free*, then give me a number, and give it to Fedora. If you think this service is useless for secure boot, I'll argue that you're not being realistic, you can't ask every OS developer to make deals with every OEM on the planet. If you want to be realistic and want secure boot for free for every developer of every OS, then fat chance, you can't have it. Some might have the contacts to make the deals for free, but Fedora chose not to use them so they wouldn't have an unfair advantage over the other distros. That's their explanation anyway. There are plenty of people who use non-Fedora kernels with the rest of the Fedora distribution. Now, I have no reasons to do so myself; and I can't think of a typical reason why I'd want to do that; but they surely have their own valid reason for doing that. I know that, and that's my point, they're non-Fedora kernels, so it's not strictly Fedora in the sense that Fedora maintainers have no authority to bless each and every one of these kernels with a signature, and nor should they have one. And, if their hardware required a Microsoft-blessed key to boot a host OS, then the whole point of getting one would be to be able to boot their machine. Imagine the gall – wanting to be able to boot a custom kernel. Easy, sign it yourself. We went over it a hundred times now. If you can build a kernel you can sign a million of them. If the technical task of signing a kernel is too much for people who don't care much about security, they can disable secure boot. -- t -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: Red Hat Will Pay Microsoft To Get Past UEFI Restrictions
On 06/02/2012 01:26 AM, Sam Varshavchik wrote: [snip] I repeat: this is NOT going to happen. If you allow an open operating system to boot, as a trusted boot, then "trusted boot" ceases all meaning whatsoever for a non-free OS that requires a signed chain from the hardware. And I won't even start on the subject of virtualization, like KVM/Qemu/libvirt. Well, *obviously*, nobody expects secure boot to do anything magical here. If you want to use these features without restriction, secure boot is useless as you said, so don't use it. Some people will still want to use secure boot because they find it useful - you might not, but there are a lot of people out there. For these people, you have two options: (1) block these features and/or (2) set them up so you can define exactly what they will be used for in your policy (if possible). In other words, the kernel should make sure that it won't load anything it can't trust (especially things it can't trust not to load another kernel) while still providing as much features as possible. This is the classic convenience vs security trade-off, and I don't think anyone is disillusioned about that "revelation". I say again, if it's too inconvenient to have to configure/cripple/block these features, then you can't possibly use secure boot in a useful manner, and hence shouldn't even bother with it. (Well, I know you know.) No vulnerability is needed. Which is why you will never have a trusted boot of an open Linux kernel. I can't talk about the feasibility of securing the entire kernel, but I kind of got the feeling that Alan Cox knew more about it, maybe he can comment a bit on that (again). I know a lot of smart people are thinking about it very seriously, so we shouldn't say it's impossible just yet. I guess the main problem comes from virt done entirely in userspace, and I admit I have no clue what the plan is to address these. I would hope some reasonable techniques exist for this already, or Microsoft wouldn't have invested so much in secure boot (they'd have the same issue afterall). Some basic userspace initialization integrity checking would already go a long way I think. Yes there is a process, indeed it doesn't require any third-party, and no it doesn't blow anything up. No, there is no such process in existence right now. You just think that there will be, in the future. Not going to happen. No. Never. If we're still talking about the process to add your own keys (that's what I was talking about anyway), know that it's confirmed by Microsoft for x86[0]. Now all vendors who don't comply [don't provide the interface to do it] won't be certified by MS. They don't want that. Why Microsoft would help here is certainly a bit of a mystery at first, but as I mentioned already, they certainly fear a PR and legal nightmare, because even if they don't explicitly require anything many vendors might not care to add the feature. And then they'll most certainly happily hide behind Big Bad Microsoft, because "Windows-certified hardware won't boot alternative OSes on x86" (that already made the news even though it's wrong). They would be quite right too, being an OEM kind of frees you from having to deal with end-users; the problems with their products are delegated to the buyer, here, Microsoft. So yes, it all makes sense in the end for MS to demand that of their vendors. Tell you what. Let's revisit this, when there's a key that will boot any Linux kernel, that anyone can build themselves, and install, ok? Well the math doesn't compute here, it's cryptographically impossible. I mean you could sign a shim that won't verify the integrity of the boot loader, but you would gain absolutely nothing from secure boot then, it makes as much as disabling it entirely. You're going meta. Who's gonna check the integrity of the firmware? Can you I tell you who: Microsoft. And their OS, when it boots. The only way to work around it, would be copyright infringement. I don't think we understand each other, I was joking. It makes little sense for the OS to check the integrity of the firmware if the firmware itself is the one thing that verifies the integrity of the OS (via the loader). I mean it's not even a real catch-22, you won't ever boot the kernel before the firmware, so this is a non-issue. Anybody can sign all the firmwares in the world all day long, nobody's gonna care nor look at these signatures. 'Real sorry if I missed an obvious use-case here, but in any case it wouldn't part of secure boot I don't think. Anyway, that won't stop, of course, an OEM &/| Microsoft from suing anyone that produces hardware containing an image signed by a Microsoft key, but actually executes something else, that allows for an open boot. Why would they sell their OEM arrangements (in the form of loaders signed with their own key) explicitly for people to load their own software if it's to sue t
Re: Red Hat Will Pay Microsoft To Get Past UEFI Restrictions
On 06/02/2012 12:47 AM, Sam Varshavchik wrote: Who exactly is outraged right now? A bunch of geeks on a mailing list? So what? Who cares? Again, people have won cases to get their money back over the license of preinstalled Windows copies because they use alternative OSes. Secure boot is way more intrusive than that for these people *and more*, so that precedent is quite reassuring. Also, why would they explicitly state that they require OEMs to implement a custom mode (where you can manage your firmware keys) for x86 and not for ARM[0]? They simply don't dare locking down the x86 ecosystem because they have too much of a monopoly there, they can't risk it - the press and the regulators would be all over it. They already made that mistake, they won't make it again. [0] Yes, I found it, it was there all along, I guess I didn't look hard enough (or didn't listen properly): http://download.microsoft.com/download/A/D/F/ADF5BEDE-C0FB-4CC0-A3E1-B38093F50BA1/windows8-hardware-cert-requirements-system.pdf [search for secureboot, you'll find it easy enough] I agree it's not ideal, so we must still demand for alternatives to Microsoft, preferably unbiased, now. We can start by not playing their games. Exactly, by ignoring them and using the services of other organizations. Not wanting such services would be equivalent to not wanting secure boot. Everybody can disable it if they don't want it already, but personally I think the technology is nice to have if done right, so it's worth showing the need for alternatives to Microsoft. I do not share your optimism. Let's just say that, a very very long time ago, I was developing Windows software. Not for very long. I don't even remember for how long, probably a year, no more. Even though it was a long time ago, I still remember what I figured out myself, on my own, back then. And I believe that there are some things out there that don't ever change. I understand, I wouldn't bet on this kind of thing everyday either. Anyway, it was actually confirmed all along (see the link above [0]), so all is good in the end. The price is irrelevant. That's just one part that makes it a farce. Nobody's going to get a key to boot an open OS on the same hardware that can boot a Microsoft OS. Doesn't matter what the price is. Actually all OS distributors with a large enough user base of people with no special skills will be interested in this kind of service (whether it's from Microsoft/Verisign or anybody else), and will happily pay for it. I didn't come up with that by the way, it's where Fedora is going for one. Niche distributions won't need it, their users will happily install new keys, just as any serious Fedora user will. Oh, I'm sure that it was informed. Like I said, all that's about, is getting RHEL into the secure boot chain. Yup, agreed. So yeah, okay, trekker, I take the bet, they get the key. :) Not the Fedora key. My bet was on a key that can boot an open Fedora, which can do everything that Fedora can do today, on the same hardware. They might get a key signed to boot a locked-down RHEL. Might. Not a guarantee. There will not, I repeat, NOT, going to be a signed key that boots Fedora, where "Fedora" refers to Fedora as we know it today. The most you're going to get, is a key that will boot Fedora that's been built and signed on Fedora build servers, using this key, that will refuse to load unsigned modules, and with certain Linux kernel features disabled. And nobody, but those build servers, will have the key. I don't think I follow you, what would be the point of using a key that would boot a version of Fedora that hasn't been built by Fedora build servers? The builder can hide anything in the binary, so the builder must naturally be the one to be trusted (or not), and hence the one to sign the boot loader (possibly asking for an intermediate like MS/VS for a signed shim if he thinks it makes sense for his user base). If the builder is you, and your user base is you, then just sign the thing yourself. This goes for modules as well; if you're willing to load any module not supported by Fedora, then fine, either review them yourself and approve them in your personal trust chain with your own keys, or disable secure boot if you don't see the value in it. If you see that there's a huge portion of users who want the same module and you think that it's ridiculous to ask them all to review and sign it themselves, then there would be value in having it reviewed by Fedora maintainers (trusted by Fedora users), you can file a report asking them nicely to consider the integration of the module in the official repositories. If they don't agree, then you can build a spin with all the other users; it's FOSS. -- t -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraprojec
Re: Red Hat Will Pay Microsoft To Get Past UEFI Restrictions
On 06/02/2012 12:20 AM, Sam Varshavchik wrote: They won't have a choice. Microsoft will require that all hardware an OEM makes must be signed by their key, or none at all. Hardware OEMs will have to choose whether their entire product line will only support a Microsoft OS, or all other OSes. No collusion between OEMs will be necessary. Each OEM can document how they arrived at their decision independently. I believe the decision will be easy for them. Excluding other OSes (or intermediates) wouldn't be smart for any OEM; they have zero incentive to do that, nothing to gain whatsoever. The only thing that would come out of such a decision would be the name of their company on a hundred headlines suggesting they've taken a bribe from Microsoft. And if Microsoft is really paying them off, it would clearly be illegal, and they would know it. I don't think even Microsoft could bribe enough OEMs to make a difference, and I don't think they would even consider it (everything gets leaked these days, it's too risky, it would be a total disaster). OEMs could certainly make OS developers and intermediates pay to have their key included (provided they want it badly enough), so they would also pass on some easy money. Anyway, I completely agree with everything you've said. -- t -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: Filesystem format for external hard disk
On 06/01/2012 04:45 PM, Bryn M. Reeves wrote: Or is the ext4 code able to mount ext3 now (I didn't think so)? I'm pretty sure it is fully backward compatible yes, even with ext2 from what I read. It simply doesn't use all the new and fancy features obviously. -- t -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: Red Hat Will Pay Microsoft To Get Past UEFI Restrictions
On 06/01/2012 02:33 PM, Sam Varshavchik wrote: Because that makes the entire concept of a trusted boot, into a trusted operating system, moot. They are not that dumb. This will enable a piece of PC hardware to boot an operating system, then run virus code that boots Windows' bootloader, infecting it, and bypassing the protection benefits that a trusted bootloader chain allegedly offers. We agree on that. You're just inverting cause and effect here. At some point, they have to trust the people developing the software, and not the software itself. In essence, the shim is like a certificate (since it's signed by Fedora implicitly via the package management system). If the shim enables anyone to execute any code they wish, "on bare metal", it makes the entire concept of trusted boot completely and totally moot. Not anyone, just Fedora. If Fedora starts to fuck up and many Windows users report being infected, and it turns out that hackers are using vulnerable Fedora kernels to host malware and chainload to Windows, then they will blacklist the shim. Since Fedora doesn't want that, the kernel maintainers, the boot loader maintainers, and the shim maintainers will make sure that nothing is vulnerable on their end, and keep the key secure. If Windows is as good as it pretends to be, it would also blacklist any boot loader shim it signed if attacks were reported on other OSes as well and if the shim's owners are not willing to address the issues / aren't able to / disappear. But yeah, it's doubtful, which is why we need unbiased trust brokers. Sure, I can sign it. Except that Fedora will refuse to run it, because it's not signed by their key. And, if there's a process by which my own signing key acquires the magical pixie dust, that does not involve, in any way whatsoever, any outside party giving their stamp of approval, that blows the entire boot loader trust chain wide open. Yes there is a process, indeed it doesn't require any third-party, and no it doesn't blow anything up. Managing the keys will be done via a trusted UEFI interface, much like the BIOS SETUP interfaces we have today, at boot time. An attacker would need physical access to the machine, and a password for the key store (and possibly even to access this interface). This is the pie in the sky. This part, is not going to happen. Microsoft will make sure of that. Another bet? As Alan Cox said, the public outrage if it doesn't happen will be immense, and even without it there probably will be regulations. There is precedent for far less than what's happening right now, and for once we can use the governments to do something good. Just be sure to be heard (but again, I don't think that's gonna be a problem, people are already boiling up). You should, perhaps, spend a few minutes actually thinking it logically through. I'm normally the paranoid one in the back, so don't worry I had. Maybe I have too much faith in our regulators and the people to voice their concerns, but I'm not going to start talking like it's the end even if I'm wrong. Nothing is lost yet, and awareness is raising even before the release of the technology. I know the fight isn't won yet either, but if everyone does its part we won't even have to lift a fist, and judging by what Microsoft is doing offering $100 signatures via Verisign (which isn't very expansive for one-time deals targeted at OS developers), I think they don't want to fight. They could just leave it be, use their OEM contacts for themselves, and tell the world other OS developers just have to get their own deals. But they don't, probably because they've been screwed for that kind of thing in the past. Monopoly isn't legal everywhere. If Microsoft will sign the key that enables loading a free and open operating system, this will defeat their own trust boost chain, by side-stepping it. Which is why they won't. They will only sign a bootloader that loads a closed OS kernel. Fedora will never get a signed bootloader, this is for RHEL. [Already covered that] Now, from all the reading I've done on the subject, the only thing I found was a kill switch that OEMs must install to completely disable trusted bootloading. Hmm I get a lot of noise from Windows 8's killswitch articles. Care to share for reference? If that's the story, that's still alarming, but I don't see how firmwares would be able to receive revocations by themselves. If they do somehow, then that's a problem and is unacceptable (unwanted traffic). If they don't, then fine, just let your trusty OS either ignore them as noise packets or treat them as cool alerts that your machine is infected. Typically the OS would have to poll for the revocations anyway (because of the many users behind NATs and firewalls defaulting to blocking all inbounds), so Linux can always decide what to do. I'm going to throw in another 1,000 quatloos on a different bet. Microsoft will
Re: Red Hat Will Pay Microsoft To Get Past UEFI Restrictions
On 06/01/2012 02:40 PM, Sam Varshavchik wrote: they can't possibly review all the software that could follow the boot loader down the chain, They won't have to. Once they have a signing key that boots their current Windows OS, they have no further need for a certification process. What value added benefit does it bring to them? For now, they avoid public outrage and keep control. I personally believe there will be other players in that game in the future, because there's a potential market for trust brokers between the OEMs and the OS distributors. If that's true, Microsoft will simply be ahead of everyone else and by feeding the mouths of everyone now they delay the necessity for other businesses to take parts of that market. I could be wrong, but at least it makes sense, and since they *do* sell these certifications and act all "we're the good guys", this explanation doesn't seem far off. I agree it's not ideal, so we must still demand for alternatives to Microsoft, preferably unbiased, now. I don't think there is much information on the exact nature of the relationship between Microsoft and Verisign. It's weird that Microsoft wouldn't get a penny out of it, especially since they host the platform, so Verisign must be paying back a good share. Or maybe I'm looking at it the wrong way and it's not about money, but.. well it usually is. because it includes big monolithic kernels, so they have to trust the people who develop the software instead of the software itself. No, they don't have to trust anyone. Who says that Microsoft must trust a bunch of hippies? Hahaha. How about buying a laptop or a PC that will boot any damn OS you want, without all this cockamamie crap? Well any computer *will* boot any damn OS, just add a key, or don't use the technology. Again, you're assuming that I will be able to add my own key. All I've heard is that OEMs will have a physical kill switch, to turn off secure boot. Where can I read some big name OEM's announcement of a board that will accept user-generated keys? Please prove me wrong. Where can I get the details of those plans? Well I don't see why Matthew Garrett would lie about that in his article (we all read his post right?). Maybe I trust his word too easily, or maybe his source is wrong, but I certainly think he's way more informed about the situation than any of us. You're right in that we should wait to see it formally announced by the OEMs before shouting victory though, but I kind of got from the vibe that it was a sure thing, so I don't think we should worry about that too much until the situation changes, hoping that it won't. And would you care to take my bet, for 1,000 quatloos, that Microsoft's certification program will be a farce? They'll sign Oracle's key, that can only boot Solaris, sure. They may very well sign an RHEL key, that will boot a locked-down RHEL. A $100 farce? At that price, they are *clearly* targeting very small players. I know it doesn't help that their site has been down since the beginning of this discussion, we can't really evaluate, but I got the feeling that Fedora's decision to use Microsoft's services was informed and not just thrown in the wild, so they presumably know for sure that they can get it. So yeah, okay, trekker, I take the bet, they get the key. :) An open Fedora? Not going to happen. Ah come on, it's not the end yet. -- t -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: Red Hat Will Pay Microsoft To Get Past UEFI Restrictions
On 06/01/2012 02:27 PM, William Brown wrote: The problem with this scheme is that a "trusted" os would in theory, with the users permission be able to some how update the trusted key repository on the firmware. Which means the security of your machine is as good as the security of your firmware / the OS that is "trusted" to update the keys. Given certain operating systems weak security record in the past, I would say that doing this would sadly amount to proving no security benefit at all ;) Typically you would only be able to manage the keys via the UEFI firmware UI, only accessible at boot time. Now of course an attack can be mounted against the firmware, but these are often set up to only initialize the minimum hardware necessary to run the boot loader. I don't think you can reduce the attack surface much more than that, and it's a good thing to keep it contained. -- t -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: Red Hat Will Pay Microsoft To Get Past UEFI Restrictions
On 06/01/2012 01:05 PM, Sam Varshavchik wrote: Just last week, installing the kernel 3.3.7 update made the ACPI backlight intensity adjustment keys on my Thinkpad work, for the first time. Unti now, they never worked. I never bothered to complain. I figure that, sooner or later, the kernel will get the support for the right bits of hardware in this laptop that it wasn't yet familiar with. And I was right. I hear you, exact same story with the embedded SD card reader on my laptop. Started to work one day, all of a sudden. Always pleasant. This kind of progress is about to be thrown under the bus. Well that's not really related though. -- t -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: Red Hat Will Pay Microsoft To Get Past UEFI Restrictions
On 06/01/2012 01:00 PM, Sam Varshavchik wrote: If, all of a sudden, another bootloader gets pushed into Fedora, only a year or so after all the headache and pain of migrating from grub 1 to grub 2, then this will validate our collective take on the subject. With the ability to manage your keys, this won't be necessary. -- t -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: Red Hat Will Pay Microsoft To Get Past UEFI Restrictions
On 06/01/2012 01:18 PM, Sam Varshavchik wrote: Who gets to make a call what is "trusted", and what even "trusted" means. Can I recompile my own kernel, sprinkle some magic dust over it, and make "trusted", without involving any other party? Yes, you can sign it yourself, with your own key. Again, you are assuming that Microsoft will sign off on the concept of signing a shim, and going forward, it's the wild-wild West. Not going to happen. Well why wouldn't they? The alternative is a boot loader for which a review would make sense. Great, but now the boot loader runs a kernel which hasn't been reviewed by Microsoft. Should they review the kernel as well? It's impossible. At some point, they have to trust the people developing the software, and not the software itself. In essence, the shim is like a certificate (since it's signed by Fedora implicitly via the package management system). BTW, if you're wondering about loading your own modules or building your own kernel, it wouldn't make sense to ask Fedora to trust your piece of software, No, it wouldn't. Why the frak should I ask anyone for permission to run my own software on my own computer? Can you explain that concept to me? Well, we agree, so just sign it yourself, there's no problem here. since it would have nothing to do with Fedora and won't even be in their repos. Nobody said that it would. So you have to do the logical thing, generate a personal key and sign your own stuff with it. But I can't do that. Only Fedora key's signed stuff will run. Yes you can. You have to go up the chain. The top is the firmware, where you'll put your key, then sign your own shim with it. The actual boot loader will then be yours to chose, and you'll make it load your own kernel. Etc. And, if an individual can get a signed key, just for asking, for their own stuff, so can an upper Moldovian, in order to right the next release of Stuxnet, that's going to get bootstraped off Fedora. You're living in a fantasy land. Not quite. They would have to ask (a) the OEMs directly, (b) trust brokers that the OEMs trust. OEMs won't care about individuals, they can't possibly do, so they will refuse all requests. For now, the only trust broker is Microsoft (actually, we now know that Verisign is somehow involved since they will receive the payments; and they are arguably less biased). Microsoft/Verisign currently ask $100 for the signatures. Every time an attacker's malware is detected and blacklisted, it would have to pay $100 to a trust broker to get a new signature. Now, I agree that it isn't much for certain botmasters, but at least Verisign probably won't allow shady payments, and hiding the financial trail of an electronic transaction with the payment methods Verisign uses is increasingly difficult. Also, I guess Microsoft/Verisign will ask for at least a little bit of information before signing, so you'd have to come up with a believable story every time, possibly with something to back it up. This will discourage a lot of attackers, and will slow down the spread of malware significantly. That's the plan anyway, and until now it's pretty sound. Or, an attacker could walk you through the steps to install their key on your firmware. For certain targets, I believe they'd be better off paying Verisign rather than their phone bill. ;) If the modules you want are of enough value for all Fedora users, you can ask the kernel maintainers (I guess) to review them, sign them and bundle them in the Fedora repositories. This feels natural. I don't give a frak about that. I just want to run my own stuff, without anyone else sticking their nose in my personal business. Is that too much to ask? As I said already, just sign it yourself, which is only natural since you wouldn't be running Fedora software anymore, but your own little derivative of Fedora. You should cool down, BTW. That's just the slashdot effect, everyone suddenly likes to hate and revolution sounds cooler than ever, but it will pass. -- t -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: Red Hat Will Pay Microsoft To Get Past UEFI Restrictions
On 06/01/2012 01:11 PM, Sam Varshavchik wrote: You are assuming that Microsoft will sign a bootloader with such functionality. I would not take that bet. The plan is to make them sign a shim boot loader, which essentially delegates the trust down to Fedora entirely, because they have no control over what Fedora will make that shim load next. Fedora can implement whatever they want after that. And they will sign; they can't possibly review all the software that could follow the boot loader down the chain, because it includes big monolithic kernels, so they have to trust the people who develop the software instead of the software itself. Now, users who buy machines with Windows pre-installed should expect their firmware to include Microsoft's key, and should be aware that they can add theirs legally. If they don't want to use Windows and don't want the trouble of setting up keys they should either: (a) Buy from an OEM which builds machines with their OS of choice pre-installed, including a secure boot key for it, (b) Ask an OEM for a machine without any OS (if you install the OS yourself then you should be responsible for installing the key as well), (c) Fight an OEM which pre-installs Windows to add a new key, possibly a set of keys from unbiased trust brokers that can distribute certificates (bootloader shims) to your OS of choice to make it more realistic. How about buying a laptop or a PC that will boot any damn OS you want, without all this cockamamie crap? Well any computer *will* boot any damn OS, just add a key, or don't use the technology. The problem here is about those users who don't know or care about it, and who might not be comfortable generating keys, securing them, signing boot loaders, and adding them to the firmware. This process can be greatly streamlined, but still it won't be suitable for everyone, and those who need secure boot the most are unfortunately those who probably won't set it up themselves. And if secure boot isn't enabled by default even on machines with preinstalled OSes, then the world will gain nothing from the technology as, again, the people feeding the zombie networks are the same who won't care to enable it themselves. -- t -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: Red Hat Will Pay Microsoft To Get Past UEFI Restrictions
On 06/01/2012 09:46 AM, Alan Cox wrote: Out of support releases are also an interesting problem. If a hole is found they need to revoke the key. If they do that the users machine is crippled. It's potentially a criminal matter in many EU states as well so whoever issues the revocation could end up in jail. Nobody is really too sure. This is all untested waters. If we're talking about the kernel, one can always make the boot loader prompt the user whether it wants to continue without the assurance of a safe boot, possibly launching the (unsafe) kernel in some sort of locked down mode (filtering connections and whatnot) to try to avoid compromise in case the system isn't yet infected. All the system has to do is fetch a new kernel and install it somehow, and if it does, even if it *is* infected, it would work, since the bootloader is assumed to be secure. If it's the bootloader that doesn't match, the shim could do the same. The thing is, if machines are compromised, the first thing the malware will do will be to block the revocations coming from the network. As such, I think that for real-world end-users who don't go fetch revocations frequently via secure back-channels, the only real advantage of secure boot will be to stop the spread of malware, not cure it. For that, you would still need the usual detection and removal techniques. Don't get me wrong, containing malware infections is still a huge win, especially when we consider the number of active botnets today, but to me I don't think OS developers should worry too much about locking down infected machines. If it's infected, the fight is already lost. Or I maybe I totally missed something; is the firmware able to go fetch revocations itself? Not sure I'd like that anyway. Correct - and you need to lock it down way more than that. Also I can't see Red Hat directly signing third party binary blobs. If it does that it implicitly believes they are lawful and also acquires some liability for them in they malfuction. That's a good point, but a little disclaimer would do, wouldn't it? I mean even today Red Hat shouldn't explicitly support them when it comes to security. I hope they don't. But you're right, it would seem weird to sign a blob and drop all responsibility for it at the same time. I guess there's no use in secure boot if you execute software you don't trust anyway, so users of third-party binary blobs probably would naturally disable secure boot. It will be up to the Fedora Board to stop Red Hat corrupting the goals of the Fedora project in this way - or if they won't for people who dislike it to dump Fedora - particularly package maintainers. That would be, well, extreme. Say if legally OEMs are bound to empower the user to manage the keys in the firmware, would you still advocate against the use of the technology? I mean, right now there's no real issue, OEMs will most certainly include *at least* the keys for the operating systems they pre-install, and that includes Red Hat (if not then there's something terribly wrong with the OEMs' common sense). With a law that states that you must be able to manage your keys, I believe freedom is untouched. I don't think any hardware vendor stated they would retract that freedom from users. Now, users who buy machines with Windows pre-installed should expect their firmware to include Microsoft's key, and should be aware that they can add theirs legally. If they don't want to use Windows and don't want the trouble of setting up keys they should either: (a) Buy from an OEM which builds machines with their OS of choice pre-installed, including a secure boot key for it, (b) Ask an OEM for a machine without any OS (if you install the OS yourself then you should be responsible for installing the key as well), (c) Fight an OEM which pre-installs Windows to add a new key, possibly a set of keys from unbiased trust brokers that can distribute certificates (bootloader shims) to your OS of choice to make it more realistic. Now that seems a little harsh for OEMs, but given Windows little monopoly*, I think everyone is OK with that - there is famously good precedent with users who got their money back on the license for the pre-installed Windows copies they got with their computers (even though their arguably knew that it was explicitly bundled as one product), so I'm pretty sure we'll make it work this time too since the situation is even more extreme. * We can justify it by stating how hard solutions (a) and (b) actually are, but these kinds of OEMs do exist. They're just too rare. -- t -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: Red Hat Will Pay Microsoft To Get Past UEFI Restrictions
On 06/01/2012 09:15 AM, Alan Cox wrote: Now a signed bootloader has its uses, however in a properly designed system you would allow the user to import their own keys. If it goes banana, I'm pretty confident this will be required by law in most sane countries. There are good organizations of activists out there, and even some who seek a new purpose[0]. Well, that's a good one right there. I don't think we're that lost yet. I hope I'm not being naive, and you're certainly right in that we should watch this closely and shout loudly if it doesn't go in the right direction. We should not, however, give up already. Even if this goes extremely bad, firmwares will be hacked. The tech world always goes on with technical solutions, whether the politics follow or not. I mean this thing affects *everyone*, it's not a lost fight. I am sure MS will use this for the Windows 9 era to say "See secure boot works for everyone, now make it mandatory". Matthew Garrett unintentionally just gave them everything they needed to continue that plan. I think that's a little fallacious and a big shortcut. Well, my opinion on that is in another post of this thread already, should you want to read it. Alan [0] http://video.fosdem.org/2012/maintracks/janson/A_New_OSI_for_A_New_Decade.webm -- t -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: Red Hat Will Pay Microsoft To Get Past UEFI Restrictions
NOTE/PS Yes, I was brave and did read myself back (now I feel pain for you). Doing that, I realized we badly need a very visible FAQ somewhere. Does it exist already? Can we point people to it? Should we write it? Anyway, here goes: On 06/01/2012 05:34 AM, Sam Varshavchik wrote: positive and confident that this entire kit-and-kaboodle has no choice but require a closed, hood-welded-shut OS, booted up with a signed chain, in order for it to work. Oracle Solaris? Yes, I think that would qualify. No it isn't necessary. You're looking at it the wrong way; basically only the things able to boot kernels and kernels themselves have to be signed and trusted to ensure the integrity of the kernels. This is because an untrusted piece of software could execute an otherwise trusted kernel and do bad things behind its back. For the rest, we trust these kernels to arbitrate our programs and allocate the resources of our machines correctly as they've been doing for decades, with no doubt that they've been compromised themselves thanks to secure boot. Whether the security services offered by the kernels include checking the integrity of all binaries on the machine[0] or not (or the use of many other security features) is irrelevant to secure boot, and only depends on how much security you want your kernel to provide. We're told that Fedora's bootloader is going to get signed – and by that, that must mean "grub", right? No, too many updates, it would be unreasonable to get it signed by a third party at each release. The obvious solution would have been to use a certificate store that the firmware could use and get a certificate from a trust broker (here, Microsoft). I'm told this solution didn't make it to the UEFI spec (didn't read it myself), so we're using a technical hack around this: a shim bootloader that will get signed and won't change often (hopefully never). Its sole purpose will be to chainload to the actual bootloader (GRUB2 for example). Technically this delegates trust just as a certificate would (implicitly this is sort of like a certificate since all packages, including the shim, are signed by Fedora release keys), so the ability for Microsoft to review that shim code has little value. Some people say they won't sign the shims of all the distros (well, those who target average users anyway), I say they get $100 per signature, and duh, it's Micro$oft. They can't review all the components that can execute kernels (all bootloaders and all versions of all kernels) so they have to delegate trust at some point anyway, so might as well make it at the lowest level to make the process smooth. Plus, if a FOSS kernel or bootloader is used as malware to boot their Windows operating system, it will affect their users, so they do care, and they have to sign as much shims from as many trusted open source distros as possible. The alternative is a big PR and legal storm because users of alternative operating systems won't be able to use their hardware. If we were able to force them to give us a choice of web browsers on their own OS, we will be able to force them to give us a choice of OS on our own machines (we can never own their software, but we own our hardware, so the argument is ten times more powerful this time). They know this, and they already publicly announced they were gonna play ball. Yet another reason is that if they don't the world will demand more trust brokers more quickly (we should in any case, but people are a little slow when it comes to security). If a business model emerges from this and more companies start to make contracts with OEMs to distribute certificates (signed shims), they will lose control and money. I believe this will and should happen eventually, so they will probably play as nice as possible to keep their customers (they only have a headstart). Remember that they are a lot more of potential customers as we usually think of as desktop users (mobile systems, server systems, custom embedded systems for all kinds of applications and industries). Well, should these potential customers want to boot their systems securely on a wide range of third-party hardware out of the box, that is (and Fedora does). We really shouldn't see it as Red Hat selling out to Microsoft. As a customer, Red Hat owns Microsoft and will be able to chose another trust broker as soon as other organizations doing this start to appear, should they be dissatisfied with Microsoft's services. Hell, as you state at the end of your post, Red Hat has the infrastructure, the resources, the money and the OEM contacts to provide that service itself for itself and for many other FOSS players. It probably just didn't think about it yet (or not enough, this isn't an easy business, and should be thought through). Note that even Fedora could be able to do it, as many hardware vendors apparently agreed to put Fedora keys i
Re: Filesystem format for external hard disk
On 05/31/2012 05:09 PM, Bryn M. Reeves wrote: I tend to encourage people to pick ext4 over ext3 on modern hardware and software. Aside from some clear performance wins for not-that-uncommon workloads (deleting lots of large files, storing large images etc) there's the fact that most of the attention upstream these days is going into ext4 - - the earlier ext* file systems are pretty much in maintenance mode today. Yep, most of the FUD around ext4 has long been obsolete now. -- t -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: Need more info: UEFI Secure Boot in Fedora [Long]
On 05/31/2012 02:38 PM, Alan Cox wrote: It's of course all a bit of a joke because it's then a simple matter of using virtualisation to fake the "secure" environment and running the "secure" OS in that 8) The distributions can review the hypervisor code (then sign it as a symbol of trust) and the kernel can then verify its integrity at runtime (just like the firmware verifies the bootloader's integrity, and the bootloader the kernel's). The hypervisor can then emulate secure boot for the virtual machines and continue the chain. Note that you're already half-way there with KVM, since most of its code runs in the kernel itself. Other hypervisors wouldn't be any different from any other package offered by the distribution, at least if the maintainers provide security support for all of them (as is the case for most serious distros). It would be pointless to sign and verify every binary, library and script on the system if the code isn't trusted. Mature infrastructure for integrity checking already exists: most IDS do file change tracking (they would need to be explicitely supported by the kernel though), but see the Linux Integrity Subsystem (in the form of the Integrity Measurement Architecture and the Extended Verification Module). (Repost: http://mjg59.dreamwidth.org/12368.html?thread=399184#cmt399184) No. I would assume the Fedora project pays the $99, and then distrubtes the signed bootloader component, with the fedora keys built in. I don't believe that would be compliant with the Fedora Project definitions of freedom. [Reply not directed at anyone in particular, I'm just rambling from now on] Let's just see it from another perspective. The obvious alternative is for Fedora and every other distribution to ask every single hardware vendor to include their own key in their firmwares. It's impossible, plain and simple. The communications channels would have to be super-efficient (they never are with such bureaucracy), the policies extra-clear, and the upgrade processes absolutely smooth (to accommodate with new software distributions, key expiration and thefts). I almost see an entire stack of protocols there, a long standardization process, and we still exclude offline or rarely connected users who won't be able to keep up with slower channels. So, as always in this kind of situation, we add another level of indirection, in the form of a trust broker. Hardware vendors trust a few big brokers in the software industry (more than a dozen would be ideal), and these brokers in turn place their trust in software distributors and make it their job to see that these distributors don't abuse that trust, blacklisting those who do. Not all communities would have the resources to do that (although I think the Linux Foundation should act as a broker). Companies in the software industry can, and they already have the contacts with the OEMs, let them do it. If anything, $100 for such a service with no apparent human verification is probably too low. Many attackers would probably pay-up to have their malware compromise as many machines as possible before they get blacklisted. Infected machines can certainly be stopped from receiving updates, so the revocations will only stop the spreading of the botnets, not shut them down. If they can spare $100 every few months (they probably make way more from their botnet business) to get a new key, they might just be alright. The system may stop the weakest players though. Another big point for making people pay to have their components signed, aside from financing the operation properly (necessary to keep the root key really secure and push the revocations in time) and discouraging small attackers, is that it's increasingly difficult to pay electronically anonymously, at least as long as no broker trusted by the vendors starts issuing signed components for anonymous money (BTC for example). Obviously, and just like the PKI for X509 CA hierarchy, the weakest link of the chain can fail the whole system (which is why there shouldn't be too many brokers, see the current web browsers struggle and last year f*-ups). Now, we only have Microsoft, but hopefully this is only the beginning. Aside from all the obvious potential abuses (blocking free software arbitrarily), the technology is actually quite sound if we can control it. And the good news is, we can. We can and we must. Even though this all looks relatively good(-ish), in reality it's merely good enough (a) for the average user who doesn't care too much about having to trust big corporations to more or less know what they want and to act in their favor and (b) for the average big distribution which doesn't care too much about giving away contact information and a little bit of money. (BTW, if you insist you don't fit that user description yet don't use something like Monkeysphere for your web browsing, then you're a hypocrite.) The
Re: Bandwidth Monitor for GNOME
On 05/31/2012 09:41 AM, Junayeed Ahnaf Nirjhor wrote: Just to see the speed and which app is taking the BW If you want to see statistics per-process, you can use `nethogs' for example. -- t -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
Re: uuidd fails to start
On 05/29/2012 06:21 PM, JD wrote: I am not running anything that I KNOW to require uuidd. I simply wanted to make sure that if there are other daemons or apps that need it, will be able to use it. You could try $ rpm -q --whatrequires uuidd -- t -- users mailing list users@lists.fedoraproject.org To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines Have a question? Ask away: http://ask.fedoraproject.org
