Announcement

Collapse
No announcement yet.

GNOME To Warn Users If Secure Boot Disabled, Preparing Other Firmware Security Help

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • #81
    Originally posted by binarybanana View Post
    I use SecureBoot with my own keys (totally pointless otherwise), but I don't like how they seem to imply that everyone with SecureBoot disabled is running some faulty, broken setup. But hey, that's exactly what I'd expect from GNOME. They know better that you what you need.
    There are two types of users that may be receiving this warning: those who know what they're doing, who are perfectly able to disable the warning and that's it, and those who don't, and then are running some faulty broken setup. If you don't know what SB is, then you definitely need it.

    Originally posted by Waethorn View Post
    Does Coreboot prevent third-party closed-source modules from running on Linux? If running an open-source operating system stack from top to bottom is important to you, this should be part of your consideration.
    Coreboot does not prevent anything to load unless you tell it so. It works perfectly with closed-source modules and it can even boot Windows.
    But in any case that has nothing to do with the point being discussed. Vendor BIOS implementations are half-assed, Coreboot is open but also relatively good quality for the supported boards. In particular, they half ass these security parts that make it troublesome to get anything but Windows working in a secure manner, and that can not be solved with current implementations due to new keys being stored in NVRAM only. Being able to build your own images is the only real fix for existing hardware that doesn't compromise working setups (e.g. the shim that's used to sign GRUB which makes all of the benefits of SB void) while not making it hard to boot at every CMOS reset.

    Originally posted by Waethorn View Post
    Secure Boot support in Linux prevents the installation of closed-source modules (drivers) on Linux. If this pushes NVIDIA to advance their open-source driver development, why wouldn't users of Linux support the move?
    Not really. It's just some distros refuse to sign these modules, which is a different issue. You may or may not agree with that policy, but it is a fact that this is the reason why SB conflicts with NVIDIA drivers in some distros.

    Comment


    • #82
      Originally posted by Waethorn View Post

      Most motherboard makers don't write the firmware code. AMI and Phoenix do. Motherboard companies just tell them which setting options to include and give them copies of logos and graphics.
      Nope the code is written by the specific party and then the vendor offers some adjustments, a Uefi is a mix of alot of firmware blobs(like most call them) they are modular 1st comes the basic uefi blob thats specced somewhere, then comes the cpu blob in the amd case AGESA, then comes the PCI code theres a pci consortium or something ? then comes a chipset blob, USB, Software Raid, Audio, Network Stack, Network Firmware.

      So now for your average mainboard you allready have 9 modules that get shoved together, and then ontop comes the boot logos and settings, from the manufacturer, so no it´s not that easy to make a good UEFI cause you have to work with the modules you get and make do with them, and if a bug happens then you have to phone home to amd/intel/realtek whatever is on your mainboard and have them fix the issue, then they send you a new module, and you integrate that in your UEFI, then you have to test it, and release it, so there is a reason why some bios suck they don´t want to go trough that hassle and pay every party for their modules just to release a new Bios version.

      Comment


      • #83
        Secure boot? The bios feature that was created by microsoft literally for the sole purpose to make it harder for users to install different operating systems and absolutely no other reason?

        This has something to do with gnome since when?

        I don't actually care much, since I don't use gnome, never have used gnome, always hated gnome I think it's the worst desktop environment, always have, probably always will...

        I'm just completely baffled, who wasted his time writing this completely pointless code and for what reason?

        Comment


        • #84
          Originally posted by erniv2 View Post
          Nope the code is written by the specific party and then the vendor offers some adjustments, a Uefi is a mix of alot of firmware blobs(like most call them) they are modular 1st comes the basic uefi blob thats specced somewhere, then comes the cpu blob in the amd case AGESA, then comes the PCI code theres a pci consortium or something ? then comes a chipset blob, USB, Software Raid, Audio, Network Stack, Network Firmware.

          So now for your average mainboard you allready have 9 modules that get shoved together, and then ontop comes the boot logos and settings, from the manufacturer, so no it´s not that easy to make a good UEFI cause you have to work with the modules you get and make do with them, and if a bug happens then you have to phone home to amd/intel/realtek whatever is on your mainboard and have them fix the issue, then they send you a new module, and you integrate that in your UEFI, then you have to test it, and release it, so there is a reason why some bios suck they don´t want to go trough that hassle and pay every party for their modules just to release a new Bios version.
          Aren't many of those modules just PEs in a block filesystem in the ROM? I know that's how you load filesystem drivers for example. This means interfaces are most likely well (enough) defined.

          Comment


          • #85
            Originally posted by mdedetrich View Post

            Yeah but the write the BIOS (which is why it looks different for each motherboard) and its in the BIOS that most of the frustrating/annoying issues arise in using SecureBoot. The firmware isn't the problem, its the usability/polish of the BIOS.
            They don't. AMI and Phoenix have the codewriters. The motherboard makers just do the design work for the menus and graphics and choose the options to display to the end-user. Most of the work on the underlying code is already done for them. What you see is just a front-end for the settings. Designers and developers are two different jobs.

            Comment


            • #86
              Originally posted by erniv2 View Post

              Nope the code is written by the specific party and then the vendor offers some adjustments, a Uefi is a mix of alot of firmware blobs(like most call them) they are modular 1st comes the basic uefi blob thats specced somewhere, then comes the cpu blob in the amd case AGESA, then comes the PCI code theres a pci consortium or something ? then comes a chipset blob, USB, Software Raid, Audio, Network Stack, Network Firmware.

              So now for your average mainboard you allready have 9 modules that get shoved together, and then ontop comes the boot logos and settings, from the manufacturer, so no it´s not that easy to make a good UEFI cause you have to work with the modules you get and make do with them, and if a bug happens then you have to phone home to amd/intel/realtek whatever is on your mainboard and have them fix the issue, then they send you a new module, and you integrate that in your UEFI, then you have to test it, and release it, so there is a reason why some bios suck they don´t want to go trough that hassle and pay every party for their modules just to release a new Bios version.
              All of the basic hardware support modules are provided by AMI and Phoenix. THEY are the ones that work with the chipset manufacturers toward integration. Motherboard companies like ASUS don't do shit for this part aside from providing some pretty graphics and UI choices. When a company like MSI or ASUS choose a firmware vendor, the hard work (code development) is handed off to them, although AMI and Phoenix already have baseline to work from for any motherboard manufacturer since they all use the same chipsets, aside from a few different choices for add-on chips for Ethernet and maybe additional controllers for supplemental RAID or USB. Yes, all of this is under the release control of the motherboard maker, but they don't actually do the job to maintain it properly or update it for whatever mapped settings or UI issues might arise from changes. This is a lot like how AOSP gets security updates, and the phone maker MIGHT make changes to it, but ultimately, it is their responsibility to release it. And then it gets handed off to your cell provider to approve it too. It may or may not need some testing (it rarely ever needs real changes). If they aren't willing to do the testing, they don't bother to release it. This is the same for motherboard makers.

              Just think of how bad the PC situation would be if Windows released security or functionality releases this way, even though they consider the computer manufacturer to be reponsible for end-user support. They still release updates directly to end-users. AMI and Phoenix can't release bugfix updates this way because the motherboard makers maintain a certain level of Intellectual Property control over their hardware, just like it's done with Android phones.

              Comment


              • #87
                Originally posted by mdedetrich View Post

                Did he give any reasons why?
                He's a stuck up ass. I don't know why he bothered to release a product as open source if he shits all over everybody's idea on how it could be modified to fit a particular purpose.

                Comment


                • #88
                  Originally posted by sinepgib View Post

                  There are two types of users that may be receiving this warning: those who know what they're doing, who are perfectly able to disable the warning and that's it, and those who don't, and then are running some faulty broken setup. If you don't know what SB is, then you definitely need it.



                  Coreboot does not prevent anything to load unless you tell it so. It works perfectly with closed-source modules and it can even boot Windows.
                  But in any case that has nothing to do with the point being discussed. Vendor BIOS implementations are half-assed, Coreboot is open but also relatively good quality for the supported boards. In particular, they half ass these security parts that make it troublesome to get anything but Windows working in a secure manner, and that can not be solved with current implementations due to new keys being stored in NVRAM only. Being able to build your own images is the only real fix for existing hardware that doesn't compromise working setups (e.g. the shim that's used to sign GRUB which makes all of the benefits of SB void) while not making it hard to boot at every CMOS reset.



                  Not really. It's just some distros refuse to sign these modules, which is a different issue. You may or may not agree with that policy, but it is a fact that this is the reason why SB conflicts with NVIDIA drivers in some distros.
                  From what I understand about Coreboot, you have to have SeaBIOS or their TianoCore version of UEFI to boot Windows. Those are payloads. You can't just map to the Windows kernel like you can with Linux on Coreboot (or LinuxBoot as it was previously known). You would need TianoCore for newer versions of Windows that mandate UEFI requirements though.

                  I stand by my point though: if the biggest independent Linux vendor out there (Fedora via Red Hat) issues warnings that force NVIDIA to advance their open-source driver development, good for them. NVIDIA needs a good swift kick in the pants. I wouldn't doubt if this move had something to do with Torvalds contention with NVIDIA. Torvalds' Linux distro of choice is Fedora. I would bet a good chunk of this paycheck comes from Red Hat.

                  Comment


                  • #89
                    Originally posted by Artim View Post

                    Well I can't agree with you either. The "tie-in" with Android (and any other OS, but mainly Android and iOS) should be in a way that makes use of their TPM implementation. And I never said I have anything against certificates. But never in a million years should a company as incompetent and all-overbearing as Microsoft should have any say in that matter. If it needs to be trusted by third-parties, it should be in the same way other certificates like for encrypted communications do it: there should be several independent roots of trust. Of course then there's the same problems with it too: there needs to be a way of telling the device to distrust a chain of trust if someone abuses their power or simply has bad security so everyone can create a certificate for everyone. This would be very difficult to pull off in a setup, but in most cases it would probably be enough to have the user connect to their WiFi first. But what if a chain of trust is distrusted at some point after installation?

                    Also, if it's done with user creates certificates as many distributions would need to do currently if the user wanted it to use secure boot, it needs to be a user-friendly, automated yet transparent method that wouldn't scare everyone off but the most tech-savvy users.

                    And of course sandboxing isn't the end all be all solution either. It's more like why should applications in the 2020s not all be sandboxed with runtime permissions granted by the user when needed, like iOS and Android do it for years now? It would be the same argument as with SSL/TLS encryption of all network traffic. Sure, there are always terrible vulnerabilities or conceptual weaknesses that would allow an attacker to decrypt the data in some MITM-Attack, but it still would be quite the added level of difficulty to do so. So nobody in their right mind (and no, all the politicians lobbying against (end-to-end-)encryption aren't) would say anything against having all network traffic secured with at least TLS 1.2 and ephemeral encryption keys.

                    Of course, no packaging system is perfect, But I'd rather see a system like the one Debian-based distributions use, to be upgraded in a way that more dependencies can be present in multiple versions that still receive security updates, that are always sandboxed and are more distribution independent, rather than having to deal with foul compromises of the likes of AppImages, Snaps and Flatpaks.
                    Microsoft came up with the idea with firmware companies. EFI was already a thing, but it wasn't universally compatible between systems. EFI was 64-bit on Itanium and mixed on Mac systems, but Microsoft wanted a new standard that made it widely compatible with systems so they worked on getting it ported to x86 by contributing to specification drafts. The firmware companies themselves collaborated on getting a working draft with prototypes. It was eventually supported in Windows Vista 64-bit, so Secure Boot took a while to be implemented. When you run on the biggest percentage of desktop PC's out there, you kind of have a bit of sway on how you'd like to see the platform evolve, you know. It's just like Apple and Google working on the HTML5 spec. Anway, when you talk about chains of trust, there are ways of distrusting that already within the certificate authority system. When you're dealing with asynchronous encryption, you're talking about needing quantum computing to crack the prime factors of a value 2^xyz digits long...yadda yadda..., just like any existing secure computing system such as SSL. Is it perfect? No. Should users worry about it not being perfect? No more so than using SSL for your online bank. Much of those problems are because of user error, not because the encryption itself is faulty, so you're splitting hairs for no reason. Quantum computing is more dangerous because of the possibility of AI than decryption.

                    Android apps are already sandboxed too, BTW. This is why you have a permission system built into the operating system.

                    Comment


                    • #90
                      Originally posted by mdedetrich View Post

                      Did he give any reasons why?
                      Not one I could make sense of.

                      Comment

                      Working...
                      X