[HN Gopher] Responsible stewardship of the UEFI Secure Boot ecos...
___________________________________________________________________
Responsible stewardship of the UEFI Secure Boot ecosystem
Author : Harvesterify
Score : 353 points
Date : 2022-07-12 08:12 UTC (14 hours ago)
(HTM) web link (mjg59.dreamwidth.org)
(TXT) w3m dump (mjg59.dreamwidth.org)
| AshamedCaptain wrote:
| The worst problem is that people are (even in the other
| discussion thread here on HN) still claiming that we are
| scaremongering. Back when all this Secure Boot was announced, we
| already said that its main purpose seemed to be to make booting
| of non-MS operating systems more complicated, rather than
| security enforcement.
|
| "But, you're scaremongering! See, I put this Debian USB pendrive
| and I can still boot it fine!"
|
| This was because Debian (and many other distros) went, at some
| point, through MS-enforced hoops in order to get their bootloader
| signed. Quite a perilous situation in which MS was this "steward"
| of the entire PC OS ecosystem; whether a Linux distribution
| booted or not on PCs was practically at the whim of MS. That was
| at least better than the alternative (no booting -- since MS got
| away with SecureBoot anyway) and we have to thank people like
| mjg59 for it.
|
| Now, your Debian pendrive will not boot on this Lenovo PC, even
| if MS-signed.
|
| "But, you're scaremongering! See, I put this Debian USB pendrive
| in, hit F1, hit cursor down three times, tab, down five times,
| space, F12, and I can still boot it fine!"
| phendrenad2 wrote:
| It's not even scaremongering at this point, it's just expired.
| Every 5 years or so something like this comes up, and it's used
| as another data point in the slippery slope that you all are so
| sure is happening. And yet, if I buy any random PC off the
| shelf in 2022, there's still a huge chance that it'll boot from
| a Linux ISO without having to jump through any hoops.
|
| I think what's happening is, at some point in the past someone
| decided that there was a conspiracy to lock out Linux, and
| while that future hasn't come to pass, the total number of
| Linux-compatible devices keeps expanding, and therefore we keep
| getting examples of vendors locking things down too hard. These
| appear to be examples of the trend, but they're an increasingly
| small percentage of the total pool of Linux-compatible devices.
| It's the same thing that happened with Android. You can still
| root most phones, despite some being locked down. Things have
| reached an equilibrium. As I said in another post "there are
| more forces than Microsoft at work here".
| nimbius wrote:
| while i absolutely agree with this sentiment, i feel like
| "Microsoft" as a boogeyman has become far more toothless since
| secureboot first took flight in 2006. the same people who
| clamored and wailed about secureboot on windows laptops snored
| through most of Apples worst laptop freedom offenses.
|
| in 2022 there isnt an single manufacturer that doesnt offer
| (albeit sometimes sporadically) a Linux laptop. system76 and
| others exist to deliver the linux laptop and desktop, and
| Google flat-out refused to do any EFI on chromebook because,
| surprise, it wasnt really necessary. The average chromebook in
| 2022 has a cogent enough arm processor to handle daily compute
| on a wide variety of distros with ease.
|
| Battlestation vendors like Asus will likely seek the rubber
| stamp for their laptop products that ship with windows, but for
| liquid cooled battle station geeks the same motherboards will
| ship with open EFI to run whatever keys you want to, or dont.
| AshamedCaptain wrote:
| > Google flat-out refused to do any EFI on chromebook
| because, surprise, it wasnt really necessary. The average
| chromebook in 2022 has a cogent enough arm processor to
| handle daily compute on a wide variety of distros with ease.
|
| Google is in no way a model to follow. They actually make it
| more complicated to install _native_ Linux than x86 PC
| manufacturers, what with their "developer mode", often
| ridiculous, physical hardware manipulation requirements to
| enable it, and non-removable Scary Boot Prompts unless you
| completely overwrite the full system firmware. In other
| words: Google is actually worse right now than MS would be on
| x86 even if they MS extended this Secured Core crap to all
| other PC manufacturers. It doesn't matter much that they use
| open-source firmware if they lock it down worse than the
| rest.
|
| And "containerized Linux" like Crouton misses the point and
| anyway MS is doing it too! (so much for those who say MS does
| not care about the Linux desktop market share).
| trelane wrote:
| > those who clamored and wailed about secureboot on windows
| laptops snored through most of Apples worst laptop freedom
| offenses.
|
| I've never had to buy an OSX computer in order to install
| linux on top of it. The same cannot be said of Windows.
| jeroenhd wrote:
| Allowing the Linux bootloader is a security risk for consumer
| Windows devices. Microsoft foolishly doesn't enable Bitlocker
| on them, so the excellent rootkit protection secure boot
| provides gets wiped out entirely the moment you grab a copy of
| grub with your own chain loader. This is possible because a
| vulnerable version of Grub got signed at some point that allows
| loading unsigned code.
|
| Secure boot should always be possible to turn off, and it
| should always be possible to load your own keys. I don't see
| the point of keeping it enabled on Linux if all of its
| protection can be disabled by editing a file on /boot. It
| defeats the entire point of requiring higher-than-kernel level
| permissions to alter the boot sequence.
|
| Linux needs better secure boot key management features if it's
| serious about making secure boot work. Without it, just turn it
| off. It's a bit of a pain for new Linux users, but so is every
| other step of the way.
| NotEvil wrote:
| You might wanna read the article. It argues the very point
| you are making.
| AshamedCaptain wrote:
| > for consumer Windows devices. Microsoft foolishly doesn't
| enable Bitlocker on them
|
| Actually, Microsoft enables Bitlocker on many if not most
| consumer devices. For example, I have not been able to find a
| laptop without Bitlocker enabled by default since the Windows
| 8.1 era. Even home editions of Windows enable bitlocker by
| default, even if they don't call it Bitlocker (they call it
| "Full device encryption" or the like). On desktops the
| situation is the opposite -- until recently, most desktops
| didn't even ship with a TPM at all.
|
| Nowadays TPMs are a requirement for Windows 11, so devices
| with Bitlocker disabled by default are going to be a
| minority.
|
| > I don't see the point of keeping it enabled on Linux if all
| of its protection can be disabled by editing a file on /boot.
|
| That's not true -- if a distribution is shipping a signed
| bootloader binary, then there should be no way to use that
| distribution's bootloader to run an unsigned binary. In fact,
| it would be considered a security vulnerability and the
| corresponding bootloader binaries would be blacklisted by
| Microsoft. It has happened in the past:
| https://www.suse.com/support/kb/doc/?id=000019892 . The
| default behavior of most distribution's GRUB2 (and specially
| whenever it is pre-enrolled into a signed shim) is that when
| you boot under Secure Boot it will check the signature on any
| UEFI executable, GRUB module, or Linux kernel you try to
| boot, and refuse to boot if it is not in the (UEFI
| firmware/shim) whitelist.
|
| > Linux needs better secure boot key management features if
| it's serious about making secure boot work.
|
| Linux already has multiple secure boot key management
| facilities. And then there's shim.
|
| But in any case, the problem is that Microsoft itself should
| be required to face these problems; under no circumstance
| should it be that by default MS gets their signatures to work
| for free but everyone else needs to have extra UI to manage
| them.
| kingrazor wrote:
| Many business class PCs shipping with Pro versions of
| Windows do not have bitlocker enabled by default. We have a
| few hundred laptops and desktops in the validation lab I
| work in and very few of them shipped with bitlocker
| enabled.
| AshamedCaptain wrote:
| Name a laptop model and we'll check. But do check the
| other thread too, I think you'd be surprised. I was
| surprised too -- it is practically guaranteed that on a
| laptop with a TPM and modern standby, Bitlocker will be
| enabled by default. In fact, a Windows install will
| default to on, ignoring the OEM setting.
| kingrazor wrote:
| I can't speak to anything newer than comet lake, but
| between my various HP elite books, elite desks, Dell
| optiplexes, latitudes, and Lenovo thinkpads, very few of
| them have shipped with bitlocker enabled by default.
| AshamedCaptain wrote:
| As I mention on the other thread, I could believe Asus or
| Acer or some other cheap laptop disabling it because of
| gaming performance or whatever, but not the big brands.
|
| I am quite familiar with HP itself, and in fact as I
| linked on the other thread they publicly claim that _all_
| their laptops have Bitlocker enabled by default. Lenovo
| is the laptop of TFA, so they are definitely doing
| Bitlocker on their enterprisey laptops. My Dell Inspiron
| 5510 came with Bitlocker on out of the box, and perusing
| the Dell support site having articles about Bitlocker
| recovery as early as the WD15 docking station era, I am
| sure they are enabling it by default too.
| kingrazor wrote:
| I don't know what to tell you. Only going off my own
| experience. Maybe things have changed since Kaby Lake.
| Most of my systems are Kaby Lake or older. I only have
| the one comet lake Dell and at this point can't actually
| recall how it shipped since I've reinstalled the OS
| several times at this point.
| vladvasiliu wrote:
| > I have not been able to find a laptop without Bitlocker
| enabled by default since the Windows 8.1 era
|
| We use HP Pro/Elite Desk/Book at work. They arrive with
| Windows 10 Pro and with BitLocker disabled. They have had a
| TPM and everything for many years, now. Latest such PC I've
| seen was manufactured in February 2022 (Elitebook 840 G8).
|
| > But in any case, the problem is that Microsoft itself
| should be required to face these problems; under no
| circumstance should it be that by default MS gets their
| signatures to work for free but everyone else needs to have
| extra UI to manage them.
|
| The thing is that if the PC comes with Windows pre-
| installed, then the certificates should be enrolled. But if
| not, maybe there shouldn't be any certificate? I guess my
| point is that it's unreasonable to expect a manufacturer to
| ship a computer with a bunch of certificates. I'd even say
| that it wouldn't be that secure.
| bobkazamakis wrote:
| > I guess my point is that it's unreasonable to expect a
| manufacturer to ship a computer with a bunch of
| certificates. I'd even say that it wouldn't be that
| secure.
|
| How exactly do you think a root trust should be
| established? Should it just boot up and start grabbing
| whatever certificates it thinks might be authentic over
| the network?
| admax88qqq wrote:
| Ship with no certificates, and Trust on First Use the
| certificate of whatever OS is installed first.
|
| There fixed it.
|
| No extra hoops for any OS. Extra hoops if you wish to
| change OS, which could increase security>
| vladvasiliu wrote:
| Of course not.
|
| But the issue is that if there's a "root" certificate
| installed, then we're more or less in the current
| situation, where MS has that root certificate and anyone
| else who wants to have a bootloader must get it signed by
| MS.
|
| Sure, there could be some kind of "neutral" entity in
| charge of this, but the issue remains.
|
| Then there's also the issue of managing certificate
| revocations. Don't know how that works, currently. Maybe
| via firmware updates? But then, older computers are SoL.
|
| Instead, what I think should be done, is to improve the
| workflow and documentation for installing one's own
| certificates. It's what I do on my own PC to run Arch
| (whose bootloader is not signed by MS) and I also signed
| MS's certificates so I can dual-boot. But the whole
| process is somewhat involved, it's not a simple "click a
| few buttons and you're done" kind of deal.
| mjg59 wrote:
| >Then there's also the issue of managing certificate
| revocations.
|
| Revocation updates are in the form of authenticated UEFI
| variable blobs. They can be applied regardless of OS and
| don't require a firmware update.
| AshamedCaptain wrote:
| I am precisely typing this from an store-bought HP Elite
| laptop from 2017 (!) and it definitely came with
| Bitlocker enabled. In fact, HP explicitly says that all
| their laptops with modern standby (which again is most of
| them, and explicitly the Elitebook 840) come with
| Bitlocker on !! https://support.hp.com/us-
| en/document/c06458046
|
| You could have said Acer or some other lesser-known brand
| and I would have not been able to counter, but HP? Are
| you sure "work" didn't configure Bitlocker to be disabled
| ?
| vladvasiliu wrote:
| > Are you sure "work" didn't configure Bitlocker to be
| disabled ?
|
| Absolutely. I took the PC out of the box myself ("I am
| work") and I know we don't have our supplier do anything
| to the PCs before they send them to us, because we
| remaster them first thing.
|
| My PC didn't go through that process because it's not one
| of the models everyone else uses and I don't use Windows.
|
| ---
|
| edit: there's talk on a page referenced by your link
| about "Device Encryption" (as opposed to Drive
| encryption) which is activated when the PC is joined to a
| domain. This did actually happen, but out of the box the
| drive was not encrypted. The reason I know is because I
| went to enable regular Bitlocker but then stopped because
| I didn't have a separate drive on hand to save the
| recovery key.
| AshamedCaptain wrote:
| > there's talk on a page referenced by your link about
| "Device Encryption" (as opposed to Drive encryption)
| which is activated when the PC is joined to a domain.
|
| Device encryption, disk encryption, and Bitlocker are
| actually the same thing. The reason is that Windows Home
| doesn't have "Bitlocker" which means it can't do external
| (aka non-boot) disk encryption, so they call the
| resulting feature "Device encryption", but it's still
| Bitlocker.
|
| My only guess is that you didn't login with a Microsoft
| account, since it is a requirement and "you don't use
| Windows". But obviously, the majority of people do login
| with a Microsoft account, and judging from HP's own
| support page plus the amount of people I can google
| claiming to have lost their recovery keys on the same
| laptop model you have ... I'm quite sure it is enabled by
| default.
| vladvasiliu wrote:
| > My only guess is that you didn't login with a Microsoft
| account
|
| That's correct, I created a local-only account since the
| PC wasn't connected to any network.
|
| However, I would have expected a feature "enabled by
| default" to not be tied to a specific type of account. I
| suppose that it would have to save the key somewhere,
| which works less well with local accounts.
| AshamedCaptain wrote:
| MS accounts are mandatory for all home editions of
| Windows, and likely soon to be for everything that's not
| an enterprise edition.
| mjg59 wrote:
| The devices we're talking about here all have Bitlocker
| enabled by default.
| jeroenhd wrote:
| I didn't know that, that's very nice. I appreciate that
| Microsoft is finally moving forward with offering
| encryption by default.
| ho_schi wrote:
| Turn SecureBoot off. Secure the UEFI and harddrive itself!
|
| _Requirements_
|
| State of he art UEFI implementation and usually a harddrive
| from the professional series. In case of a ThinkPad it should
| be possible for more than a decade.
|
| _How To_ 1.) Set an UEFI-Password to
| protect the UEFI (formerly BIOS) itself 2.) Set a
| Harddrive-Password within the UEFI, which requires a
| harddrive with built-in encryption
|
| This protects the UEFI itself from manipulation, the
| bootloader, the kernel and the howl system. It is simple,
| therefore less error prone. Transparent to the operating-
| system, therefore any operating system is supported. It
| doesn't affect performance because professional harddrives
| actually encrypt always all data - they just don't ask for a
| key. You need to trust into the UEFI implementation and the
| harddrive manufacturer, which you hopefully do.
|
| _Bonus_
|
| No Certificate Authority (CA) and certificates involved. This
| reduces the error surface because it is error prone. You
| could even add LUKS (or whatever you prefer) on top of it.
| Because of the transparent built-in encryption you will not
| have a conflict. Probably a touch too much? But upon your
| decision.
|
| https://support.lenovo.com/ie/en/solutions/ht002240
| tentacleuno wrote:
| > You need to trust into the UEFI implementation and the
| harddrive manufacturer, which you hopefully do.
|
| Trusting hardware encryption on consumer SSD's has been
| proven to be a pretty disastrous idea[0], with even
| Bitlocker disabling hardware encryption by default.
|
| From what I understand, a _lot_ of encryption
| implementations were really really bad, with massive
| security vulnerabilities and issues. I suppose if you 're
| an enterprise you have the money to test if the SSD is
| _actually_ encrypting the data on the NAND, but a consumer
| would be none the wiser.
|
| [0]: https://www.howtogeek.com/fyi/you-cant-trust-
| bitlocker-to-en...
| ho_schi wrote:
| Yes. I just didn't remember the specific models affeced:
| Crucial: MX100, MX200 und MX300 Samsung: 840 EVO
| und 850 EVO
|
| Curcial fixed it later with an firmware update. I think
| people got mad on Samsung because they didn't fixed it?
| Not affected where Intel, Micron, Samsung's own more
| expensive PRO-Series (interesting?) and others. We also
| rely on hardware based encryption on iPhones and
| Androids? Finally we need to trust the CPU and the random
| number generator, TPM, Pluton and that the keyboard or
| whatever is not manipulated. By the way - I don't trust
| Microsoft's Pluton! And interestingly Dell and Lenovo
| decided to turn it off by default.
| bejelentkezni wrote:
| Debian's images are not Secure Boot signed. You made that up.
| mjg59 wrote:
| Debian has shipped with a signed bootloader since version 10,
| released over 3 years ago.
| phkahler wrote:
| I think they said the Debian boot loader was, not the whole
| OS image.
| ziml77 wrote:
| You still are scaremongering.
|
| Secured core is a class of device security specifically
| intended to be highly locked down.
|
| From https://docs.microsoft.com/en-us/windows-
| hardware/design/dev...:
|
| > Secured-core PCs provide protections that are useful against
| sophisticated attacks and can provide increased assurance when
| handling mission-critical data in some of the most data-
| sensitive industries, such as healthcare workers that handle
| medical records and other personally identifiable information
| (PII), commercial roles that handle high business impact and
| highly sensitive data, such as a financial controller with
| earnings data.
|
| > For general purpose laptops, tablets, 2-in-1's, mobile
| workstations, and desktops, Microsoft recommends using Security
| baselines for optimal configuration. For more info, see Windows
| security baselines.
| AshamedCaptain wrote:
| Only when MS allows booting "vetted" non-MS OSes _with the
| same amount of effort_ as it takes to boot MS OSes (like what
| they do already in other devices) there is any minimal chance
| of believing this is for security, and not for pure market
| control.
|
| If they wanted to have a setting to control whether to block
| non-MS OSes to boot, they could have put THAT as the hard-to-
| find option, rather than the opposite. They would not have
| needed to make an entire class of separate hardware whose
| only difference is apparently that by default it boots MS
| OSes only, and who knows how is being pushed behind the
| scenes.
| raxxorraxor wrote:
| But it is untrue that these devices are particularly secure,
| especially compared to the average linux distribution. This
| is Microsoft marketing and nothing else. On the contrary, the
| case for security is not to use MS systems because one of the
| largest threats for industry is industrial espionage and a
| lot of Microsoft components and data retention cannot be
| audited.
|
| Boot sector attacks have become quite rare and a sensible
| threat analysis is the basis of good security. Otherwise you
| could sell any crap as security. Unplugging your keyboard
| stops a lot of attacks actually...
| MereInterest wrote:
| I don't see why Microsoft working to make an extremely
| locked-down class of devices should be taken as evidence that
| Microsoft isn't working to lock down devices, or that they
| wouldn't have an incentive to lock down devices.
| Avamander wrote:
| That's not what the person they replied to said though.
| Providing the means to harden a device do not mean you
| can't boot non-MS operating systems. It does show intent to
| harden devices yes, but not what was replied to.
| MereInterest wrote:
| Placing additional obstacles to installing your choice of
| OS, even if each one is individually justified, leads to
| an veritable steeplechase of obstacles in doing so. By
| placing more and more restrictions on the default, each
| of which must be individually researched and disabled,
| fewer people are able to exercise their choice. There
| doesn't need to be a definitive deathblow if you can
| bleed away the opportunity to choose.
| Avamander wrote:
| > Placing additional obstacles to installing your choice
| of OS, even if each one is individually justified, leads
| to an veritable steeplechase of obstacles in doing so.
|
| It's a huge stretch to call a single toggle in UEFI an
| "obstacle" if you're already competent enough to install
| an OS from scratch. Maybe the focus should be on that,
| how to provide preinstalled Linux instead.
|
| > each of which must be individually researched and
| disabled
|
| Or you read the user manual.
| MereInterest wrote:
| Hurdles like these are why "competent enough to install
| an OS" is considered a bar in the first place. I agree
| that it is good when OEMs offer Linux preinstalled, but
| that doesn't absolve Microsoft from adding obstacles in
| cases where OEMs do not.
|
| Reading the user manual is a form of research that must
| be done. When software doesn't allow an action, and
| doesn't immediately explain what can be done to override
| the restriction, that's a form of additional research.
| AshamedCaptain wrote:
| > we already said that its main purpose seemed to be to
| make booting of non-MS operating systems more complicated
|
| is literally on the first paragraph of my comment.
| sgift wrote:
| My problem with the position of the "MS is bad" crowd here is
| that the security reasons are outright dismissed. It's even in
| the article:
|
| > The second is that this is predicated on the idea that
| removing the third-party bootloaders and drivers removes all
| the vulnerabilities. In fact, there's been rather a lot of
| vulnerabilities in the Windows bootloader. A broad enough
| vulnerability in the Windows bootloader is arguably a lot worse
| than a vulnerability in a third-party loader, since it won't
| change the PCR 7 measurements and the system will boot happily.
| Removing trust in the third-party CA does nothing to protect
| against this.
|
| Why is it 'all'? Why not 'some' vulnerabilities? Because then
| it's rather obvious that having one less bootloader allowed by
| default means less potential for vulnerabilities. And then the
| whole point breaks down.
| AshamedCaptain wrote:
| > Because then it's rather obvious that having one less
| bootloader allowed by default means less potential for
| vulnerabilities.
|
| Even if this was true, the fact that this defaults to having
| the MS signature enabled by default (and the other signatures
| have to enabled manually) should already make any security-
| oriented person shiver extensively, considering MS's
| vulnerability record. At least, it is clearly an (anti-)trust
| issue, which is already grounds to dismiss the entire idea.
|
| Second, the fact that it may reduce the attack surface by an
| infinitesimal amount, and not even in paper (since the attack
| surface is still theoretically the same), is really an
| argument for it? By the same logic, I can always argue for
| having 40+-character length passwords and other rather
| dubious practices, which by definition also improve security
| -- and these ones at least do so on paper. It's just that
| security people already know that this infinitesimal
| improvement just does not warrant the other can of worms that
| such an approach opens, i.e. it is not worth the trade-off.
|
| And third, there are better ways to reduce the attack surface
| to an even lower level; ways that do not put a single vendor
| in control of the security of the entire ecosystem. Claiming
| "this is one way, we should do it!" is textbook politician's
| fallacy.
|
| I will note that this crap hasn't worked for Apple when
| arguing why they should remain an steward of the entire Apple
| software ecosystem , and it shouldn't work for MS, either.
| ahartmetz wrote:
| Bootloader attacks are neither common, nor does it seem
| likely that "secure boot" keeps out a really determined
| attacker. Why spend so much effort on such a relatively
| useless feature unless there is another reason for it?
| Avamander wrote:
| > Why spend so much effort on such a relatively useless
| feature unless there is another reason for it?
|
| Because it's not only Secure Boot really. It's just one
| part of a larger set of firmware hardening methods called
| Device Guard (since 2016), which is also a part of Secured
| Core. (which was mentioned in the article).
|
| > Bootloader attacks are neither common, nor does it seem
| likely that "secure boot" keeps out a really determined
| attacker.
|
| Because an increasing amount of PC's have Secure Boot
| enabled and few attacks really are conducted by a "really
| determined attacker".
| ahartmetz wrote:
| > Because an increasing amount of PC's have Secure Boot
| enabled and few attacks really are conducted by a "really
| determined attacker".
|
| But these few attacks are the only ones against which
| "secure boot" might help, and it probably doesn't.
| Bootloader attacks were extremely rare to nonexistent
| even before "secure boot".
| cesarb wrote:
| > Bootloader attacks were extremely rare to nonexistent
| even before "secure boot".
|
| Playing devil's advocate: boot sector viruses were common
| back then. Secure Boot completely avoids both them and
| their UEFI equivalent, which is probably why we don't see
| them anymore.
| Avamander wrote:
| It's not really devil's advocate. It's no longer trivial
| and is increasingly less so, for random malware that has
| acquired high privileges to compromise the entire boot
| sequence.
| AshamedCaptain wrote:
| Boot sector viruses were already hardly common before
| Secure Boot. Practically since anything that is not MS-
| DOS-based, it is not that easy to write to the hard disk
| boot sector from a running operating system, and if you
| can do so, then it is much easier to write your payload
| somewhere else in the host OS (with all the OS
| functionality at your disposal) rather than the boot
| sector.
| Avamander wrote:
| > Boot sector viruses were already hardly common before
| Secure Boot. [...] t is not that easy to write to the
| hard disk boot sector from a running operating system,
|
| I wonder why... could it be that even then the risk was
| understood and there were attempts to mitigate? I hope
| you remember the option in BIOS called "Master Boot
| Record Protection".
|
| Your "it's uncommon now, so it must not be a problem"
| argument is tedious at best. Precautions were taken, the
| worst case has been avoided and that's not an argument
| supporting not having any precautions.
|
| > then it is much easier to write your payload somewhere
| else in the host OS (with all the OS functionality at
| your disposal) rather than the boot sector.
|
| Sure, as long as you can launch before the AV or
| perpetually keep it at bay without making noise. Getting
| your malware to run sooner or even as part of the system
| gives you a very valuable advantage. It's ridiculous to
| even imply that it wouldn't have become a big problem.
| pdonis wrote:
| _> it 's rather obvious that having one less bootloader
| allowed by default means less potential for vulnerabilities._
|
| Ok, so why not allow me to remove the _Windows_ bootloader
| and just have the third party one that I trust more?
| Joker_vD wrote:
| Because _Microsoft_ doesn 't trust it more, and they know
| better what's good for you.
| hollerith wrote:
| The OP is careful and measured. This comment is the opposite.
| zahllos wrote:
| Agree. There's separate issues at play: the mechanism, what
| value it adds or subtracts and how it can be used. The
| critical component is allowing end users to control their own
| devices.
|
| Fair disclosure, I've been involved in products supporting
| secure boot, have run my own laptop with my own keys such
| that only my signed stuff runs. I also have one of those
| Talos 2 boards and it also supports its own secure boot, even
| though all of the software all the way down to the firmware
| is open source.
|
| So far Microsoft have actually been pretty reasonable: they
| enabled the shim in the first place. No Linux distros
| including heavyweights like Redhat or Canonical stepped up to
| undergo the requirements for default inclusion in the UEFI
| forum.
|
| It always strikes me as a logical fallacy to argue against
| having a secure boot but then be pro end to end encryption.
| 'Secure boot is being used to oppress us therefore secure
| boot is bad' is as extreme a view as 'some awful human beings
| share csam so end-to-end bad'.
|
| Ultimately in both cases the problem is societal and not
| technical. We need consumer rights protections so we don't
| end up renting our devices, and we need policing and
| community work to eradicate csam. Frothing at the mouth
| misinformed 'activism' comes across very badly to people
| outside the tech world we necessarily need to engage to make
| constructive policies for the future.
| Perseids wrote:
| Your arguments strike me as inconsistent. You say we need
| consumer rights protections so we don't end up renting our
| devices, but then you criticize the comment that speaks up
| about a consumer rights problem.
|
| > There's separate issues at play: the mechanism, what
| value it adds or subtracts and how it can be used.
|
| The thing is, it's absurd to separate these issues. Look at
| it from the perspective of most users: Secure Boot is a
| solution to a minuscule problem. The vast majority of
| exploits happen in their browsers, office suits or due to
| social engineering (phishing, ransomware, adware).
|
| So from the start, to sway the trade-off in favor to Secure
| Boot, the trouble it generates must be minuscule as well.
| And that is not the case: From the beginning Secure Boot
| has been a threat to free OS choice on PCs. Microsoft did
| not start by proposing a non-profit steward that will find
| good rules how code signing can be implemented and what
| rules you have to follow to be let in. That would have been
| "pretty reasonable". Instead they declared themselves
| rulers and it required a massive effort of the free
| software community to find ways to fulfill the requirements
| Microsoft unilaterally declared.
|
| Being able to find a working process with Microsoft has
| generated some fragile trust, but all of that is in peril
| with news like Lenovo removing the _Microsoft Corporation
| UEFI CA_ from their default installation.
|
| If you would really care about letting the mechanism stand
| on its own without it being intermingled with politics (and
| I read that you care about that from the cited line) there
| is only one solution: Take the private keys to the Secure
| Boot certificates away from Microsoft and hand them over to
| neutral party. (And of course that will not happen, and
| thus the political and technical side remain deeply
| intertwined.)
| Avamander wrote:
| > Secure Boot is a solution to a minuscule problem. The
| vast majority of exploits happen in their browsers,
| office suits or due to social engineering (phishing,
| ransomware, adware).
|
| It's a minuscule problem right now because _of_ SB. Why
| spend time and effort if it 's likely you'll encounter a
| protected system.
|
| If you give adversaries the possibility of implanting
| something deep into the boot chain, you've lost the
| entire battle. Obviously things that get exposed to
| untrusted content get exploited _first_ , but no good
| attacker would leave it at that, especially if they want
| to create persistent malware and botnets. Exactly due to
| *Secure Boot* we aren't suffering from mass-spread
| malware like the ones that existed.
|
| > massive effort of the free software community to find
| ways to fulfill the requirements Microsoft unilaterally
| declared.
|
| Not really massive, mostly like absolute bare minimum, if
| you've read them. But okay.
|
| > Take the private keys to the Secure Boot certificates
| away from Microsoft and hand them over to neutral party.
| (And of course that will not happen, and thus the
| political and technical side remain deeply intertwined.)
|
| We could totally have a third root CA as well, if
| mandated or needed, but I haven't heard anyone pushing
| for it. Apple doesn't care and most Linux distros barely
| support existing Secure Boot which requires much less
| effort than running your own CA does.
| AshamedCaptain wrote:
| > It's a minuscule problem right now because of SB. Why
| spend time and effort if it's likely you'll encounter a
| protected system.
|
| It was a minuscule problem even before SB and even today
| still is without SB. For most people who are exploited up
| to the point were malware _can write directly to the boot
| hard disk_, "boot chain safety" is at that point the
| least of the user's problems. Their data is already
| uploaded to a Russian server, ransomware installed, their
| webcam turns on without the warning LED, and all their OS
| security including the root account has been compromised
| up to the point that the attacker can start erasing off-
| site backups without the owner even noticing (no need and
| no point to compromise the boot chain).
|
| The only scenarios were boot chain integrity would apply
| are evil maid scenarios where the attacker can write to
| the boot disk externally, i.e. _not from the user's OS
| itself_, and these are way outside the worries of the
| immense majority of users. Correctly, IMHO.
|
| > Not really massive, mostly like absolute bare minimum
| [effort], if you've read them. But okay.
|
| > most Linux distros barely support existing Secure Boot
| which requires much less effort than running your own CA
| does.
|
| This is a just cheap criticism (even insulting) without
| even providing any reasoning whatsoever. And I say that
| as someone who has criticized Linux distributions from
| trying to play under the arbitrary MS rules.
|
| Most if not all Linux distros do their own CA already.
| They sign packages, after all.
| Avamander wrote:
| > It was a minuscule problem even before SB and even
| today still is without SB.
|
| This is just a cheap way to handwave the problem away
| without even providing any reasoning whatsoever.
|
| It wouldn't be this minuscule if that attack venue
| wouldn't have been made so much less worthwhile. We have
| real life examples of these types of attacks, how are you
| seriously trying to claim that it wouldn't have gotten
| widespread? In what universe would malware makers agree
| not to abuse something so high-reward if allowed?
|
| > For most people who are exploited up to the point were
| malware _can write directly to the boot hard disk_, "boot
| chain safety" is at that point the least of the user's
| problems.
|
| It's not that absolute. It's certainly bad when things
| have gotten that far, but it doesn't mean it isn't a good
| idea to protect against deeper infection. "Oh they got
| infected, let's just abandon it all" is just so overly
| reductionist and is really of no substance.
|
| > The only scenarios were boot chain integrity would
| apply are evil maid scenarios where the attacker can
| write to the boot disk externally
|
| Blatantly false.
|
| > This is a just cheap criticism without even providing
| any reasoning whatsoever.
|
| It's not a criticism even, it's an astute observation.
|
| > Most if not all Linux distros do their own CA already.
| They sign packages, after all.
|
| That's an even worse look for them, then, bunch of those
| distributions not shipping at least a signed shim (MOK
| enrollment excluded for now) and a signed installer.
|
| For now I'll also skip over the fact that your average
| distro's package signing is way below the standards a
| trusted commercial CA has to follow.
| [deleted]
| zahllos wrote:
| Specifically I'm critical of the original post labelling
| any 'it is actually ok' message on secure boot as
| 'scaremongering'.
|
| > Instead they declared themselves rulers
|
| This statement logically suggests that Microsoft laid
| down the law on secure boot and the impetus was entirely
| theirs and nobody could have done anything differently.
|
| The UEFI forum was made into a public forum for the
| public version for x86. Before that it was a proprietary
| boot protocol designed by Intel mostly for itanium but
| also licensed to Apple for x86 (2010 era Mac minis use
| efi). Microsoft were not the originators, although I've
| no doubt they're contributors to this and secure boot.
|
| Where Microsoft _do_ dictate is the Windows logo program,
| which is distinct from UEFI. This was the discussion
| originally on Matthew Garrett's blog: will they or won't
| they leave an 'off' option (practically they had to, to
| boot older windows and rescue disks).
|
| Furthermore Microsoft's Windows logo requirements, while
| requiring OEMs to carry their keys on the basis OEMs want
| Windows logo, didn't exclude the likes of Redhat or
| Canonical from standing up a CA and getting included.
| There's some discussion of this on Matthew's older blog
| posts:
| https://mjg59.dreamwidth.org/6503.html?thread=194919
| although I think there was a better discussion on OEM
| inclusion I can't find.
|
| In other words we find ourselves where we are because
| everyone has been content for years to simply use the
| shim signed by Microsoft. Only Microsoft stood up a CA
| and underwent the due diligence. And you can't say a free
| CA can't be stood up, because letsencrypt went from zero
| to cab root programmes in this time.
|
| The only issue in here that needs some care is forcing
| vendors to ship all approved CAs, not a minimum selection
| they care about.
|
| Bootkits are a minor issue now as othe commentators have
| insinuated because of secure boot.
|
| There are other advantages, too. With secure boot and
| tpms remote attestation of some systems at least becomes
| a bit more reasonable. You can also have the same bootkit
| resistance under Linux if you're prepared to put in a
| little bit of effort.
|
| Sure if I had my way we'd have prioritized MTE/PAC over
| secure boot but there you are.
|
| So let me sum up. Yes, what Lenovo is doing is bad, and
| if Microsoft are really proposing ditching third party
| signing then they deserve another massive antitrust suit.
| Looks like Matthew is again pretty much the only voice in
| the Linux world trying to make something practical work.
|
| I am saying that it should always be the case that you
| can disable secure boot and it should always be the case
| that you can manage your platform keys. I also think they
| should ship the UEFI CA by default and offer the option
| to opt in to secure core as part of Windows' OOBE if they
| feel so compelled.
|
| But there is a non profit neutral third party already and
| no Linux distro (or the Linux foundation) have pushed for
| CA inclusion that I know of.
|
| UEFI and Secure Boot are here to stay unfortunately.
| That's not going to change (and that's more of a comment
| on the design of UEFI than SB).
| cowtools wrote:
| Secure boot is opressive when you don't have the keys. So
| is encryption.
| trelane wrote:
| If someone else has the keys, you're not the owner,
| you're a renter.
| AshamedCaptain wrote:
| I actually paraphrased a lot of parts from the OP. I guess
| (guess because you don't mention the reasons why this is "not
| careful nor measured") you are one of these people who think
| that as long as there is some key combination that allows a
| Linux distribution to boot, there is no reason whatsoever to
| complain ?
|
| Well, sorry, but no. I will sound the alarm way before the
| only way to install Linux (or any other OS) is to disassemble
| the laptop and hit some physical switch that will cause a
| Scary Boot Prompt to be permanently shown on my device,
| reminding me that I'm booting an "unsupported OS" and that
| "someone could be doing this to steal my personal data", and
| requiring me to acknowledge it by waiting 30 seconds before
| it proceeds to boot my actual OS. Every Single Time I boot
| the device. I will complain loudly way before we reach that
| on PCs.
|
| Cause that's exactly what I had to do to run Linux on a
| Chromebook. And Google also seems to think that because they
| allow me to run some Linux distros under a heavily curtained
| container inside their OS, "all's good". Google does not get
| a free pass from me, why should MS?
| wrycoder wrote:
| And hardware will not allow that "unsupported" OS to access
| routable network.
| trelane wrote:
| Well, crud. With remote attestation, that could become a
| reality.
| dane-pgp wrote:
| First it will be required for playing online games[0],
| then governments will require ISPs to enforce it for
| anyone who goes online.
|
| Once people start side-loading to get around future bans
| on E2EE messaging apps, I expect governments will require
| OS vendors to implement blacklisting of such software
| even on desktops, using something like Apple's Gatekeeper
| service[1].
|
| [0] https://www.pcgamesn.com/valorant/windows-11
|
| [1] https://appleinsider.com/articles/20/11/15/big-sur-
| telling-a...
| kps wrote:
| If you want a picture of the future, imagine a secure
| boot stamping on a human face -- forever.
| Avamander wrote:
| > "But, you're scaremongering! See, I put this Debian USB
| pendrive in, hit F1, hit cursor down three times, tab, down
| five times, space, F12, and I can still boot it fine!"
|
| Because yes, one extra option in UEFI settings is the end of
| Linux on the Desktop. People definitely do not change anything
| else in UEFI settings ever as Linux users and it's
| significantly more complex than before. /s
|
| But that's not true, is it? Changing DG or SB toggle is no more
| difficult than setting the system's clock or boot order. These
| things are also described in the manual. People installing any
| OS fresh are likely to have the skillset necessary to do so.
|
| > Back when all this Secure Boot was announced, we already said
| that its main purpose seemed to be to make booting of non-MS
| operating systems more complicated, rather than security
| enforcement.
|
| This is not Secure Boot per se, it is Device Guard. It's quite
| misleading to call it Secure Boot. If you read up on what
| Device Guard tries to achieve you should be able to see how it
| as a whole does provide noteworthy security improvements.
|
| > Now, your Debian pendrive will not boot on this Lenovo PC,
| even if MS-signed.
|
| *Please* do go on how you're not scaremongering here or in the
| previous thread. That sentence is literally false.
| AshamedCaptain wrote:
| > This is not Secure Boot per se, it is Device Guard. It's
| quite misleading to call it Secure Boot. If you read up on
| what Device Guard tries to achieve on Secured Core PC
|
| As clearly mentioned in the TFA, this is Secure Boot itself
| and has nothing to do with Device Guard.
| Avamander wrote:
| Yeah and it is incorrect. Disabling that CA is a part of
| Device Guard requirements since 2016. Obviously Secure Boot
| enforces its configuration, but it's specified and set as
| such due to Device Guard.
| pjmlp wrote:
| As someone that started with 8 and 16 bit computers, I am fine
| with single purpose computers.
|
| Instead of giving money to Microsoft or Apple, support OEMs
| producing hardware with Linux pre-installed like Tuxedo and
| System 76.
| trelane wrote:
| The wider problem is that, as long as Microsoft is
| superdominant in the PC market, Linux OEMs will still be
| affected by Microsoft's decrees, because they don't (yet?)
| have the influence of Apple to get fully custom hardware.
| pjmlp wrote:
| How could they when places like FOSDEM are full of people
| carrying Apple laptops.
| chithanh wrote:
| That is not the point. The point is by employing dark
| patterns, Microsoft makes it progressively more difficult for
| normal users to switch away from Microsoft.
|
| Want to switch default browser? Adding yet one more step to
| stop you.
|
| Want to boot other operating system? Now you have to go to
| UEFI setup and change boot settings.
|
| etc.
| trelane wrote:
| Want to run Linux? Why go through the hassle of some Linux
| OEM when you can just keep Windows and run WSL?
| AshamedCaptain wrote:
| This is exactly my problem with all of this. Microsoft
| makes a way to run Linux desktop programs on Windows,
| meaning that they DO care about the market share that
| _desktop_ Linux represents. At the same time, they make
| steps to make running actual desktop Linux OSes as
| inconvenient as possible, which incidentally makes WSL
| appear more and more convenient every time.
|
| At this point, the simplest explanation is malice.
| trelane wrote:
| Well yes. Strategically, it makes all kinds of sense for
| them to force people who want to run Linux into their
| walled garden. Sure, you can run Linux, as long as it's
| safely contained inside Windows, an approved version, and
| preferably running something that requires Windows above
| you (e.g. DirectX inside WSL being a thin shim).
|
| However, what makes sense for Microsoft may not be in
| _our_ best interest.
| jacquesm wrote:
| It always was. There wasn't a day in the history of
| Microsoft that they were aiming for a level playingfield.
| pjmlp wrote:
| What they care about is the market share of the
| developers that buy Apple devices to develop UNIX
| applications, and couldn't care less about Linux itself,
| and are now not happy with the direction macOS is going.
|
| WSL focus on Linux, because the Linux kernel ABI is the
| new POSIX.
| pjmlp wrote:
| It is the point, it is like arguing to switch away from
| Spectrum, C64, Atari, Amiga, Acorn,.... back in the day.
|
| PC only got out of control, because Compaq was clever on
| their reverse engineering process, and IBM failed to uphold
| their ownership.
| NeutralForest wrote:
| This is correct of course but we can't ignore that Windows
| computer are ubiquitous nowadays. Alternatives like Tuxedo or
| System76 are either pricier or are missing options such as
| keyboard layouts, delivery to non US/CAN/AUS and European
| countries, world wide support (in your language). Also,
| people just _know_ Windows. Those issues might go away in
| time but there 's non-zero friction to acquiring Linux
| hardware imo.
| MereInterest wrote:
| >As someone that started with 8 and 16 bit computers, I am
| fine with single purpose computers.
|
| I'm also okay with single-purpose computers. Like the
| computer in the thermostat that controls the boiler, or the
| timer for the sprinklers. An OS-locked computer is still a
| general-purpose device, and describing it as "single purpose"
| muddies the waters.
|
| > Instead of giving money to Microsoft or Apple, support OEMs
| producing hardware with Linux pre-installed like Tuxedo and
| System 76.
|
| Why is this an "XOR" instead of "AND"? I prefer purchasing
| from OEMs that provide pre-installed Linux, AND I find it
| morally repugnant when manufacturers assert ownership over a
| device after having sold it.
| pseudalopex wrote:
| > As someone that started with 8 and 16 bit computers, I am
| fine with single purpose computers.
|
| No one should complain about regressing 30 or 40 years?
| pjmlp wrote:
| Given that most people using GNU/Linux praise using it as
| if it was UNIX V6, that shouldn't be an issue.
| boesboes wrote:
| As a former system-76 owner: it just sucks they are such low
| quality. All plastic, worse thermals then a 2018 mac book.
| Couldn't even decode a 720p youtube video without burning up.
| System 76 just rebrands some shitty chinese laptops and you
| notice.
|
| I tried not giving money to apple, but it was money wasted
| tbh. Like seriously, $2k for a barely useable laptop.
| trelane wrote:
| > System 76 just rebrands some shitty chinese laptops and
| you notice.
|
| This is manifestly not the case. Perhaps in the very early
| days but not in the last several years.
| mardifoufs wrote:
| I thought they are still using rebranded Clevo laptops in
| their current product line? Not that it's inherently a
| bad thing, just curious to know.
| trelane wrote:
| They work with Clevo to develop them[3], and make the
| hardware work with Linux[0], preferably in firmware (so
| you don't generally need the System76 driver). They also
| set them up with CoreBoot and open source EC[1].
|
| Although Clevo can sell their own version of the
| hardware, it is not really the same[2]
|
| [0] Based on my experience. I ordered a laptop a long
| time ago and they explained they were working with Clevo
| to get the firmware fixed so that suspending worked
| reliably. This is before the OpenBoot + EC stuff came
| about.
|
| [1] https://support.system76.com/articles/open-firmware-
| systems/
|
| [2] https://twitter.com/jeremy_soller/status/132295496454
| 9824512
|
| [3] Clevo is System76's ODM. Most OEMs (e.g. Dell, HP)
| work with ODMs to put together the final product the OEM
| then offers. I posted the public Dell ODM list in another
| thread. System76 wanted to bring laptops in-house; I
| don't know the status on that. But System76 and Clevo
| work together to offer the final laptop based in a Clevo
| base[4]. And now (like, in the last 4 years) System76
| started also adding open source firmware in some places.
|
| [4] https://twitter.com/jeremy_soller/status/132296053230
| 3872000
| pjmlp wrote:
| So basically helping making macOS more relevant than
| GNU/Linux on the desktop.
| [deleted]
| cptskippy wrote:
| Does Google use Secure Boot on it's Chromebooks? Are you able
| to install whatever you want on them?
| userbinator wrote:
| _The worst problem is that people are (even in the other
| discussion thread here on HN) still claiming that we are
| scaremongering._
|
| Remember what some people on here (and elsewhere) work for.
| They either truly believe advancing the authoritarian
| corporatocracy is a good thing, have been brainwashed into
| doing so, or are just happy to have a job. These are the true
| enemies of your freedom.
|
| Some of us saw this coming endgame ever since the "Trusted
| Computing" movement started, and how they slowly drowned out
| their opposition with propaganda. "Security" has become the go-
| to excuse for having their way with their power. The infamous
| Franklin quote has certainly taken on a new meaning.
| pydry wrote:
| I dont think it's a concerted effort to support corportocracy
| think it's just the just world fallacy.
|
| It happens in all sorts of other domains too - the tendency
| to believe that things, by default, are the way they are for
| good and just reasons is strong in most people.
| mmphosis wrote:
| _It happens in all sorts of other domains too - the
| tendency to believe that things, by default, are the way
| they are for good and just reasons is strong in most
| people._
|
| For example, that's why there are still ashtrays in new
| airplanes by default.
| DoctorOetker wrote:
| I need an explicit list of public keys corresponding to the
| _hardware_ roots of trust. From the article and prior reading
| it seems to be the hardware vendor 's. Or are these in turn
| signed by Intel, AMD, ARM, ...?
|
| i.e. which public key is actually burnt in the processor's
| eFuses?
|
| A cryptographic break can always happen, and in such a
| cryptographically apocalyptic event i'd prefer to be able to
| author, sign and boot a minimal bootloader myself.
|
| Have people ever gathered such listings?
|
| EDIT: a secondary reason for maintaining such lists: key
| compromise can always happen, knowing when you need to
| replace your processor / computer because of a fundamental
| compromise would be mandatory. Also when buying hardware
| being able to observe historically compromised keys by vendor
| could give an indication of their security discipline.
| bitwize wrote:
| We're now at the final stage of conspiracy theory damage control
| with respect to the idea that Microsoft is trying to lock down
| the PC platform and prevent non-Windows operating systems from
| booting:
|
| 1. It's not happening, I don't know what you're talking about,
| anybody who believes that has been radicalized by Russian
| propaganda
|
| 2. Well, yeah, maybe it is happening here and there, but it's no
| big deal, and it's certainly not through a coordinated effort on
| our part
|
| 3. Yes, it's happening, it's been happening all this while, and
| here's why it's a good thing <-- we are here
|
| We all will have to reckon with the fact that general purpose
| computing is going bye-bye. The interests of OEMs and ISVs in
| delivering a safe, consumable experience to end users are aligned
| against allowing unsigned, unapproved software from running. And
| yes, the OEMs, ISVs, and probably most of the consumer market
| will believe that this is a good thing. The next big thing is
| remote attestation: the internet will simply stop working
| properly on your machine unless it can prove that it is running
| an approved OS and application stack.
| option_key wrote:
| You don't understand! Nadella's Microsoft open-sourced a few
| applications and created a popular text editor, which makes him
| basically the second coming of Christ in the eyes of a large
| portion of HN users.
|
| Their numerous anti-user and anti-privacy practices are
| unimportant. Nadella's Microsoft is "cool" and that's all that
| matters.
| Arnavion wrote:
| Non-Cloudflare-captcha link:
| https://web.archive.org/web/20220712083007/https://mjg59.dre...
|
| ("Please stand by, while we are checking your browser... Please
| turn JavaScript on and reload the page." No thanks.)
| skywal_l wrote:
| TLDR: So essentially, if the Lenovo laptop does not allow to boot
| on linux (or anything that is not Microsoft sanctioned) by
| default without a modification of the boot options, this is not
| because of Lenovo but because, in order to be certified by
| Microsoft, Lenovo has to comply with a set of rules that are not
| public and as such, impossible to follow for non-Microsoft
| entities.
|
| Edit: So, as Arnavion commented right below, my TLDR is incorrect
| inasmuch the fact that Microsoft requirements are not public only
| prevent us to understand why this change was made.
| Arnavion wrote:
| >a set of rules that are not public and as such, impossible to
| follow for non-Microsoft entities.
|
| This is not correct, in that there's nothing for "non-Microsoft
| entities" to do in this situation regardless of whether the
| rules are public or not. The only CA that non-Microsoft
| bootloaders can be signed by is the UEFI CA, and that is not
| going to change. At least not in the sense that non-MS
| bootloaders could ask to be signed by the CA that signs Windows
| (the one that's still trusted by default), because it has
| obviously always been intentional that Windows was signed by a
| different CA than the common rabble.
|
| The only piece of information we're missing, and which having
| the docs become public would reveal, is _why_ this change
| needed to be made, so that we can then either sulk about it or
| try to get it reverted or resolved in some way.
|
| Edit: Note that SB has had a revocation list concept built-in
| since the beginning, and this list is designed to be
| serviceable by regular OS updates (the OS can just modify the
| EFI vars, no manual firmware flashing required like it was with
| BIOS). So it was not a problem even if some bootloaders got
| signed that shouldn't have. That's why it's weird that such a
| drastic approach is being taken.
| Avamander wrote:
| > The only piece of information we're missing, and which
| having the docs become public would reveal
|
| It has been documented for a while really:
|
| https://docs.microsoft.com/en-
| us/windows/security/identity-p...
| Arnavion wrote:
| Searching for that phrase "Microsoft UEFI CA must be
| removed from Secure Boot DB" returns a link to a Microsoft
| presentation at UEFI Plugfest 2016 [1]
|
| It doesn't directly say why that requirement was
| introduced, though one could gather from the context that
| it's being done for security. But perhaps more interesting
| is that both this presentation and the MSDN page you linked
| also talk about enterprises being able to control what runs
| on the hardware themselves. Your MSDN page has:
|
| >Removing Microsoft UEFI CA from Secure Boot DB provides
| full control to enterprises over software that runs before
| the operating system boots.
|
| ... and the presentation has:
|
| >Security Certificates added to my device are documented
| and justified, with a pre-defined security response plan.
|
| So I wonder if the reason is just "We wanted to make it
| convenient for enterprises to not have to do a pre-
| provision step to remove the UEFI CA, so instead we
| mandated OEMs to not enable it in the first place."
|
| It would be extremely silly if that turned out to be the
| reason...
|
| [1]: https://uefi.org/sites/default/files/resources/UEFI_Pl
| ugfest...
| Avamander wrote:
| There are vulnerable bootloaders signed with the UEFI CA.
| Disabling less heavily vetted CA on devices that are
| being sold as basically hardened, makes sense. But yeah,
| one aspect of it might be making it easier for
| enterprises, that's a large focus.
| AshamedCaptain wrote:
| There are also vulnerable bootloaders signed with the MS
| production CA. The DBX set is not just shim hashes, you
| know.
|
| If MS's distrusts its own ability to vet other people's
| code, why trust their ability to vet their own code?
| Avamander wrote:
| > If MS's distrusts its own ability to vet other people's
| code, why trust their ability to vet their own code?
|
| If you want to do the legwork yourself, feel free to roll
| your own PKI and sign things you trust yourself.
| AshamedCaptain wrote:
| This fails to answer the question.
| Avamander wrote:
| It was a leading question, answer to which only you can
| know based on your threat model. I did however say what
| you can do if you don't trust Microsoft, which also makes
| the question quite irrelevant.
| [deleted]
| Arnavion wrote:
| Well that's what the revocation list is for, but yes I
| can imagine choosing the nuclear option of just dropping
| the CA is attractive because it's less work for everyone
| involved.
| jsiepkes wrote:
| That document does not specify the requirements Microsoft
| imposes on consumer PC OEM'ers such as Lenovo, HP, etc.
| Avamander wrote:
| If you want to call your model Device Guard compatible or
| even Secured Core compatible (which requires Device
| Guard), then it does.
| trasz wrote:
| This is a gross misrepresentation of what this article is
| about.
| jsiepkes wrote:
| As far as I can tell the summary is exactly what the article
| is about.
| skywal_l wrote:
| Hanlon's razor. It might just be a gross misinterpretation.
| Please enlighten me.
| michaelt wrote:
| _> Given the association with the secured-core requirements, this
| is presumably a security decision of some kind. Unfortunately, we
| have no real idea what this security decision is intended to
| protect against._
|
| Isn't secure boot attempting to protect against 'evil maid'
| attacks?
|
| After all, the evil maid can come in on Day 1 and insert a
| bootable USB stick which boots a linux distro customised to look
| like the normal Windows boot and save your password when you
| enter it; then on Day 2 boot the computer normally and use that
| password.
|
| If you want to protect against that, you need password-protected
| BIOS settings to enable/disable booting third-party code.
|
| (Personally I see adopting the TPM as a fool's errand - I don't
| think it can ever deliver on its promises)
| phh wrote:
| If you can't modify victim's computer itself, just do that on
| another computer?
|
| The evil maid will need less time to replace the computer with
| another one that looks alike the original one, than to install
| a Linux distro
| dotancohen wrote:
| The maid could even install a USB keylogger, if the goal is
| compromising just the credentials.
| michaelt wrote:
| This is what I mean when I say adopting the TPM is a fool's
| errand; I think protection against evil maid attacks is
| impossible.
|
| Unless you're willing to go full iphone/xbox with no third-
| party hardware or OSes.
| phh wrote:
| In the case of the Xbox, you can replace the mainboard
| with like a rpi and still achieve it quite easily (I'd
| say budget ~ 100EUR). That's harder for a smartphone (I'd
| say budget ~ 2000EUR). Either way, the budget is still
| lower than the price of security flaws to circumvent
| secure boot.
| AshamedCaptain wrote:
| > Unless you're willing to go full iphone/xbox with no
| third-party hardware or OSes
|
| And even then, you still have the entire 1st party OS
| attack surface to play with. Which is just _huge_
| specially considering this evil maid scenario implies you
| have a large amount of time with full control of the
| device itself and all its hardware.
|
| These evil maid scenarios are so academical in nature by
| now, that there is practically no way to defend against
| them outside academia itself.
| judge2020 wrote:
| Presumably, if you can't touch the bootloader & the
| device has BitLocker enabled, then you can't even get
| into the OS unless you either (A) know the user's
| password, or (B) have an exploit that can be triggered
| from the lock screen.
| marcosdumay wrote:
| You are saying that down in a thread about how it's much
| easier to just switch the entire computer...
| phendrenad2 wrote:
| Yes, it's likely to stop evil maid attacks. But keylogging is
| just one attack vector. If you can boot to Linux, you can clone
| a copy of the user's data, to be decrypted with a cluster off-
| site.
| 323 wrote:
| The standard response is that after entering the password the
| user will notice that the boot fails to complete to the
| expected Windows instance. In a high security environment this
| boot failure should immediately be flagged and investigated and
| the machine considered compromised.
| michaelt wrote:
| Just chuck up a screen saying "Configuring update for
| Windows, do not turn off your PC" and reboot 2 minutes later.
|
| There's now no evidence of compromise except a user saying
| "My computer rebooted unexpectedly, there was a message about
| windows update" - hardly something that's going to set alarm
| bells ringing.
| 323 wrote:
| Any failure to get to the expected desktop must be
| investigated. No exceptions.
|
| If you ignore red flags, yeah, you are going to get owned.
|
| Windows doesn't do that normally, it doesn't reboot after
| installing updates during the boot. It can only happen if
| the computer crashes during update install, which again, is
| rare and a red flag. So it's not like every week you will
| need to send your computer to investigations during update
| installs.
|
| But of course, the evil maid can just implant your
| keyboard.
| phendrenad2 wrote:
| What if the USB Linux stick loads the NTFS partition and
| runs the entire Windows OS inside of HyperV? Are users
| supposed to learn VM escape shellcode to check their PC
| each time? ("You fat-fingered your shellcode? Well you
| deserve to be owned!")
| dang wrote:
| Recent and related:
|
| _Lenovo shipping new laptops that only boot Windows by default_
| - https://news.ycombinator.com/item?id=32023868 - July 2022 (388
| comments)
| CaliforniaKarl wrote:
| Kindof off-topic, but...
|
| > whenever a signed object is booted by the firmware, the trusted
| certificate used to verify that object is measured into PCR 7 in
| the TPM.
|
| Is there a list somewhere of what each PCR is generally used for?
| I've had difficulty finding the information through Google
| searches.
| mjg59 wrote:
| https://trustedcomputinggroup.org/resource/pc-client-specifi...
| is the spec for this on PCs.
| peter_retief wrote:
| I do not want to ever use Microsoft software, why do I need a
| Microsoft certified key to use my own hardware?
|
| Big question is how do Microsoft get away with this bullying of
| hardware manufactures, probably the fear of losing business.
|
| What can we do to stop this?
| onli wrote:
| The moment systems like TPM and secureboot were added it
| stopped being our hardware. We said as much back then, sabotage
| like described here show that analysis was right.
|
| There is nothing that can be done as long as there is a
| processor duopoly that follows these ms requirements.
| jeroenhd wrote:
| What's the problem with TPMs? Do you mean the Intel ME/AMD
| PSP or is there an anti hardware key movement out there that
| I don't know about?
| cesarb wrote:
| AFAIK, the fears with TPM are mostly about remote
| attestation. That is, a remote system could certify that
| you are running Windows (and not something else like Linux)
| on the physical hardware (and not on a VM) before allowing
| access to some resource; and that "some resource" could in
| the future even include basic things like Internet access.
| jeroenhd wrote:
| That's a pretty terrible system, but I'm more afraid of
| the remote end of the system than the local one to be
| honest. We already have DRM and Intel providing features
| like SGX isn't the problem; the external parties choosing
| to restrict user freedom are.
|
| I don't think remote hardware attestation will be
| implemented anywhere but in enterprise environments where
| it makes sense to do so. Even on Android we see remote
| attestation being bypassed quite easily in most apps.
| Some banks and payment providers are harder to trick, but
| I don't think there's a version of the system that hasn't
| been bypassed yet.
| Avamander wrote:
| > Even on Android we see remote attestation being
| bypassed quite easily in most apps. Some banks and
| payment providers are harder to trick, but I don't think
| there's a version of the system that hasn't been bypassed
| yet.
|
| It's getting harder by the year. I think it has strangled
| a lot of the Android ROM and modding community really,
| how your apps can randomly stop working after an update
| or two or that you can't watch high-quality content.
| jeroenhd wrote:
| I think the Android ROM scene is starting to die out in
| general. Stuff not working outside official ROMs/on
| rooted devices has always been a problem, especially with
| DRM. People want the freedom to do what they want with
| their hardware and DRM people want people to do only what
| they allow with their hardware, the two parties will
| always be at odds.
|
| Huge parts of the ROM scene were on Google Plus (yes,
| people actually used that) rather than on XDA and
| similar, which didn't help. Google also tends to hire
| people who do impressive modifications for Android ROMs
| like the person who wrote magisk, making the custom ROM
| scene shrink some more. I remember the ROM scene being so
| much more active before the corruption and death of
| Cyanogenmod!
| AshamedCaptain wrote:
| > Even on Android we see remote attestation being
| bypassed quite easily in most apps. Some banks and
| payment providers are harder to trick, but I don't think
| there's a version of the system that hasn't been bypassed
| yet.
|
| You do not need to guarantee that it can't be bypassed.
| You just need to ensure that it is annoying for the
| average advanced user to bypass it and that's it -- the
| damage is done.
|
| And for example I have had to change banks already, and I
| consider myself a pretty advanced user...
| jeroenhd wrote:
| You can buy the Linux editions of your hardware, at least for
| laptops, to show that there's a real need for Linux support out
| there, however small it may be in practice. Or you can buy
| System76 or similar hardware to guarantee actual Linux
| compatibility rather than the manufacturer saying "it boots so
| let's ship it".
| selfhoster11 wrote:
| If I had to pay 2x the retail price for Linux compatible
| hardware, I'd have never gotten into Linux as a teenager with
| no money and no access to special hardware.
| trelane wrote:
| "2x?" Citation, please
| selfhoster11 wrote:
| What cesarb said already, rings true to me: even if these
| devices were available at a price comparable to retail,
| no way in hell I would buy a special "Linux phone/laptop"
| in addition to my regular one. I just wouldn't have had
| the financial resources to explore the world of "open"
| things.
|
| To address your proper comment, any amount of time spent
| on window-shopping any "open hardware by design" project
| pricing pages will show exorbitant amounts vs comparable
| spec consumer/mainstream hardware.
|
| Examples:
|
| * Talos Workstation, any Librem product, MNT Reform:
| self-explanatory. Absolutely mad price range for someone
| who is not sure whether they should buy one/need one,
| even for someone already in full-time employment in the
| IT field. If that's what you need or want, and you're
| sure you both need it and can afford it? Great. But not
| accessible to hobbyists.
|
| * the Framework laptop/System76: the most basic
| configurations are around $1k/PS1k. I don't think it's
| likely I would be able to obtain a cheaper one second-
| hand locally.
|
| I am not going to make a survey of all Linux/open laptop
| vendors out there who sell worldwide (or at least, US and
| Europe), but I assume it's similar. If you can point to
| reasonably priced laptops from 2 different vendors or
| more, with specs suitable to using the laptop as a
| modern-day daily driver, I will retract this point.
|
| * OpenPandora/DragonBox Pyra: I was extremely interested
| in this one, but bloody hell, spending 300-500EUR on a
| piece of hardware that will basically only ever play
| source ports of games and emulators? I knew straight away
| that I would only ever lick this thing through the
| virtual shopfront window, because for what you got, that
| price range was extremely hard to justify. This was
| before ARM gaming was a thing in any way.
|
| * OpenMoko: as far as I know, the only attempt at an open
| hardware smartphone (that got something off the ground)
| until the PinePhone came along. Reading about it at the
| time, I recognised that its hardware is outdated, and
| that the software is irredeemable to anyone not willing
| to put blood, sweat and tears into it. Meanwhile, I
| could've picked up a CyanogenMod Android phone and had
| 80-90% of the benefit, for about the same price, and
| comparable or much better specs.
|
| I don't blame anyone on the list above for the prices,
| and I don't think their products are crap. All I'm saying
| is that for someone on a budget, getting one of those is
| unviable. Either it's too expensive outright, or when it
| isn't, the result is not usable as a daily driver because
| you would give up basic features that you actually need.
| And when I mean basic, I mean "it cannot use
| school/work/bank/government/messaging apps made for the
| current duopoly in this device category", not "uses an
| older version of USB".
| cesarb wrote:
| Even 1x the retail price is too much. Like many (perhaps
| most) people here, I got into Linux as a teenager by dual-
| booting on hardware I (or rather my parents) already owned.
| If I had to pay for extra hardware just to try Linux, I
| would probably still be using MS-DOS and Windows.
| pjmlp wrote:
| Instead of giving money to Apple or Microsoft, you give it to
| Linux OEMs.
| fredgrott wrote:
| Does this reflect the same sort of issues in the browser password
| protection space, i.e. Since last year chrome by default links to
| google password protection in short words you have to do extra
| steps to link google accounts to non-google Chrome browsers.
|
| They say security but there is an underlying Elephant in the room
| concern that keeps rearing it's head.
| sylware wrote:
| Accute evil, what did you expect?
| jillesvangurp wrote:
| Sounds like the same anti competitive behavior that MS was
| punished for two decades ago. Making it a requirement to only
| boot software approved by them excludes a whole range of
| competitors from using the same hardware. Making that a condition
| for OEMs to even get a license is the problem here.
|
| Lenovo is otherwise known for supporting Linux on their laptops.
| And yes I know you can jump through hoops and fiddle with scary
| (for ordinary users) bios options to "fix" this. The point is
| that you shouldn't have to and this is a bit too convenient for
| MS to keep competitors off laptops.
|
| Basically, what is needed here is a neutral certificate authority
| not controlled by a single company with a reasonable process for
| independent operating systems to get a certificate.
|
| I recently ran into this trying to boot linux on my old imac.
| Ubuntu actually works but forget about arch, manjaro, and a whole
| lot of other distributions. Imacs have no off-switch for secure
| boot that I know off.
| helloooooooo wrote:
| My new Microsoft Surface Book let's me switch to 3rd party CAs
| or even none at all, with no problem. This sounds like a Lenovo
| issue.
|
| On top of that, I would prefer if my machine is by default, in
| a secure configuration when I buy it. Since the laptops come
| with Windows pre-installed and Microsoft signed bootloaders, it
| is fundamentally more secure than if the 3rd parties CAs are
| enables. I don't want an attacker chain loading Linux and KVM
| beneath my Windows OS.
| Arnavion wrote:
| >I don't want an attacker chain loading Linux and KVM beneath
| my Windows OS.
|
| If your Windows install was protected by Bitlocker, and the
| decryption key was stored in the TPM, and the TPM was set up
| to require attestation to unseal the key, then such
| chainloading wouldn't be an issue. (This is also explained in
| the article.)
|
| BTW, the default for the firmware interface is that it is
| _not_ password-protected, so even this particular Lenovo
| device is vulnerable to the evil maid attack you 're
| describing in its "default secure configuration", because the
| maid can just toggle that option to enable the UEFI CA, or
| even disable SB entirely. Unless Lenovo is planning to make
| the UEFI password a required step in their purchase order
| process, you can expect that the default configuration is
| going to be an unprotected UEFI. That's why the way to
| resolve the threat is not to prevent other bootloaders, but
| to prevent them from reading the data on disk.
| tjoff wrote:
| It is still an issue. A different OS could load and mimic
| the normal boot procedure to steel any credentials entered.
|
| Also, the whole scenario you depict is quite unreasonable
| to expect of a default install - which is exactly what is
| being talked about.
| Arnavion wrote:
| > It is still an issue. A different OS could load and
| mimic the normal boot procedure to steel any credentials
| entered.
|
| What credentials? The bitlocker key is in the TPM. It's
| not something a human can enter.
|
| >Also, the whole scenario you depict is quite
| unreasonable to expect of a default install - which is
| exactly what is being talked about.
|
| I'm confused. Are you referring to the scenario of the
| Windows install with the bitlocker key in the TPM, or the
| scenario of the evil maid attack? The former is already
| how Windows works by default, and the latter is precisely
| the scenario that helloooooooo was talking about, so I'm
| not sure which one you're calling unreasonable.
| tjoff wrote:
| And normal people unlock bitlocker is by entering a
| passphrase. If you have the passphrase you can unlock
| it...
| AshamedCaptain wrote:
| Not really; most people unlock Bitlocker via TPM, that's
| why a shitton of people don't even realize they have it.
| If the TPM doesn't give up the key, you are asked for the
| _recovery key_, not a passphrase.
|
| And the fact they have no clue what the "recovery key"
| is, that is how most people realize they had Bitlocker
| on...
|
| MS actually keeps a copy of _your_ PC's recovery key on
| their servers when you install Windows; that's one of the
| official reasons they have for requiring a MS account
| when you set Windows up: so that they can store your
| recovery key for you and give it back to you if ask
| nicely. (Moral implications of this best left for another
| discussion). This is for the personal editions of
| Windows, in the business editions of Windows; your IT
| (via ActiveDirectory) will store your recovery key for
| you.
| tjoff wrote:
| I know. So walk me through it, you turn on the machine.
| Windows boots, you are greeted with a login/password
| prompt. The user enters their password and now typically
| have access to everything of value on that machine.
| withinboredom wrote:
| No, it will ask you for the bitlocker recovery key before
| booting. Many users probably don't know where to get it
| or need to involve IT.
| tjoff wrote:
| You most certainly do not need the recovery key every
| time you boot.
| Arnavion wrote:
| You don't have anything of value _on that machine_ , at
| least not yet. The user entered their Windows login creds
| into the fake prompt, but the Windows partition itself is
| still encrypted.
|
| Now, if this is a Microsoft account whose login creds
| you've stolen, and if the user doesn't have 2FA set up on
| their account / you are in a position to manipulate them
| into allowing the 2FA, then yes you can get into their
| Microsoft Account and access the data there. And if the
| recovery key is easily extractable from there as
| AshamedCaptain said in their comment, then yes you have
| access to the encrypted disk too. And of course if they
| reused those creds on other websites you have those too,
| yada yada.
|
| But still, we are still talking about default
| configurations, right? You still haven't addressed my
| point that this evil maid attack already works on any
| machine where the UEFI isn't password-protected by
| default.
| tjoff wrote:
| ... or you can just login on the device itself. (for
| which I certainly hope doesn't require todays crappy 2FA
| to work (unless you have something like a yubikey))
|
| Yes, that is still an issue - for now. Which is arguably
| why these steps are being made. To close that hole one
| step at a time.
| Arnavion wrote:
| So just to be clear, the hole you're hoping to be closed
| is not Lenovo's "Allow UEFI CA" checkbox. The hole you're
| hoping to be closed is a) the ability to change the CAs
| at all, and b) the ability to disable SB. In other words
| you're hoping for hardware that can only boot Windows in
| perpetuity, nothing else.
|
| It's fine if that's what you're hoping for, but I just
| want you to be aware of that in case you weren't already.
| trelane wrote:
| Can I hope for it? Would put an end to the "slapping
| Linux on a Windows box and complaining about how it
| doesn't work right" nonsense. (Probably in the bad way,
| and almost certainly with massive damage to the wider x86
| hardware market, but still....)
|
| One of the things Apple did kinda right was forcing you
| to buy Apple hardware to run OSX. It would be deeply
| ironic of Microsoft to cause the same end effect by
| locking Linux _out_ of all the Windows computers.
| AshamedCaptain wrote:
| Not to mention that you can use Windows itself as a base
| OS for your credentials phishing input screen.
| tjoff wrote:
| Yeesh, no. I'm against it.
|
| But I do think it is reasonable for a "windows PC" (one
| where the device is sold with windows preinstalled) only
| can boot windows by default. As that is what will benefit
| the absolute vast majority of users (though to be fair,
| there is plenty of lower hanging fruits than the boot
| process for most users).
|
| But it is wholly unreasonable for the owner of the PC not
| to be able to disable that by themselves (without
| internet access or anything). If the solution to that is
| to require a UEFI password to be setup (perhaps windows
| could set the UEFI-password to the same as the main user
| if it hadn't already been set) - and resetting the uefi-
| password would wipe any encryption keys in the TPM that
| is fine (as long as the option to reset the uefi password
| exist).
|
| And further, not allowing the owner the control to dual-
| boot windows and any other OS is also wholly unreasonable
| (but I'm fine with the owner having to enable it in UEFI
| first).
| trelane wrote:
| > MS actually keeps a copy of _your_ PC's recovery key on
| their servers when you install Windows
|
| Do you have a reference for this? I didn't realize this
| was the case. Is it part of their "pluton" stuff?
| AshamedCaptain wrote:
| First Google result: https://support.microsoft.com/en-
| us/windows/finding-your-bit...
|
| No, it's not Pluton, they've been doing this at least for
| a decade.
| bootsmann wrote:
| That is highly unlikely. The default configuration with a
| password includes a verification with the TPM. So the
| process is like this: power on -> BitLocker asks for
| password -> password unlocks the TPM -> TPM does its boot
| verification -> TPM releases the encryption key -> you
| can boot into win
|
| If you're on a win home installation the password thing
| isn't even an option, you just get boot verification and
| have to retrieve the recovery key from your microsoft
| account if TPM trips (imo somewhat questionable by MS).
| [deleted]
| helloooooooo wrote:
| Yes an attacker still could. BitLocker is handled within
| Microsoft binaries in the windows EFI partition. I believe
| it is specifically bootmgr.efi.
|
| You can still chain load up windows on KVM at this point,
| however getting the Windows partition decrypted may be
| difficult and requires faking up a few TPM measurements.
| AshamedCaptain wrote:
| You cannot "fake a few TPM measurements", it is the TPM
| itself which decides whether to give up the key or not.
| cptskippy wrote:
| > This sounds like a Lenovo issue.
|
| Lenovo locks down hardware. I tried to upgrade the WiFi card
| in my Yoga 2 and got an "unauthorized hardware" message from
| the UEFI and it refused to boot until I removed the hardware.
|
| I would not at all be surprised if they're just over
| reaching.
| mjg59 wrote:
| Macs never implemented UEFI Secure Boot. The Apple-specific
| Secure Boot can be disabled - https://support.apple.com/en-
| us/HT208198.
| downrightmike wrote:
| The real problem is lately we've been seeing malware that lives
| in UEFI from APT (Edit: Advanced Persistent Threat actor,
| usually state sponsored) groups. That means it is persistent
| and will typically disallow updating the UEFI once infected.
| And almost everyone hates OS updates, and the smallest
| percentage are willing to update firmware, because it can brick
| a device, so UEFI isn't going to get updated. This is one of
| the few things you MUST trust, even if you want to follow zero
| trust.
| legalcorrection wrote:
| > _the smallest percentage are willing to update firmware_
|
| Not commenting on the broader issue, but this attitude has to
| change. Firmware updates cannot be seen as optional anymore.
| phkahler wrote:
| Firmware should have a physical switch to enable updating
| it. Fuck self checked signatures. There, fixed all the BIOS
| and firmware exploits for you. You're welcome.
| downrightmike wrote:
| It is possible https://hackernoon.com/how-the-nintendo-
| switch-prevents-down...
| mjg59 wrote:
| Firmware vulnerabilities aren't necessarily used to
| target the firmware or to try to gain persistence -
| vulnerabilities in SMM handlers, for instance, can be
| used for privilege escalation at runtime.
| R0b0t1 wrote:
| That is true, but disabling firmware update (should)
| limit the available persistence for the malware.
| mjg59 wrote:
| Limit, but it doesn't remove all avenues of attack.
| Firmware config needs to be writable at runtime (things
| like cold boot attack protection require state to persist
| over power cycles, even if you don't think other firmware
| config should be modifiable without physical presence),
| and the code that parses that could still contain
| vulnerabilities. Making firmware mostly read-only would
| mitigate certain classes of attack, but not all of them.
| R0b0t1 wrote:
| Perfect is the enemy of good enough.
| legalcorrection wrote:
| That only works for IT-managed devices (and even then, is
| very expensive in terms of labor). Consumer devices need
| auto-update to protect them from known vulnerabilities.
| Auto-update is hard to get right, but your product is
| defective by design if it doesn't support it.
| metadat wrote:
| Sometimes firmware updates make the system worse or even
| completely bricked. If the machine already working and
| stable, I've learned it's a risky / bad idea to eagerly
| apply firmware updates.
| bayindirh wrote:
| Flash media is cheap nowadays, and HP EliteBook series
| laptops store a couple of previous BIOS versions on board
| to make rollback possible. Also these higher end laptops
| can try previous version of their firmware if they fail
| to boot with the latest one.
|
| Failing to see how Lenovo can't implement something like
| that.
| omegalulw wrote:
| I mean sure, but no one is forcing users to install software
| from APT groups. That's a choice people make. The general
| point is that you should be able to use hardware for general
| computing. There can be a switch that by default limits to
| software signed by your original manufacturer but that should
| toggleable by the end user.
| _jal wrote:
| > but no one is forcing users to install software from APT
| groups. That's a choice people make.
|
| ... what?
| vlovich123 wrote:
| OP probably misunderstood it as Advanced Pacakge Tool,
| the system Debian uses for package management (ie APT
| sources) instead of Advanced Persistent Threat which is
| what the quote is talking about (ie sophisticated
| hackers, usually state backed/state owned that attack
| your machine).
| babypuncher wrote:
| They said "APT _groups_ " which makes me think they were
| not talking about the package manager.
| bayindirh wrote:
| > I mean sure, but no one is forcing users to install
| software from APT groups.
|
| Yeah, the members of said groups handle that part, so the
| software installs automatically. No forcing and consent is
| necessary in most scenarios. :)
| Arnavion wrote:
| >I recently ran into this trying to boot linux on my old imac.
| Ubuntu actually works but forget about arch, manjaro, and a
| whole lot of other distributions. Imacs have no off-switch for
| secure boot that I know off.
|
| Does it also not let you use your own keys? Because if it does,
| you don't have to turn SB off, just use your key to sign the
| UKI and a bootloader like systemd-boot. It should work with any
| distro, especially one that uses dracut to create the initramfs
| because it's a couple of lines of dracut config to generate a
| (signed) UKI instead.
| jillesvangurp wrote:
| Not in a way that is obvious to me. I'm sure you can work
| around it but if you just want to boot a live image and run
| an installer, ubuntu works and not a whole lot of other
| distributions do (because their installers don't support
| secure boot). I assume this is because of how much of a PITA
| it is to get certified.
| Arnavion wrote:
| >I assume this is because of how much of a PITA it is to
| get certified.
|
| Distros don't have to do anything distro-specific to get
| signed. Most distros use (Microsoft-signed) shim to
| chainload to something like grub.
|
| But yes, it might be that the live CDs don't do that; I
| don't know. My experience with SB on all my machines has
| been to start with SB disabled and then I enable it
| afterwards with my own keys. I know the gparted and
| OpenSUSE live CDs support SB because I've booted off them
| after enabling SB.
|
| You _could_ boot the Ubuntu live CD (or something smaller
| like gparted), mount the other distro 's live CD, chroot
| into it, and run the other distro's installer that way.
| Just be sure that you enable SB support so that the
| installation actually boots afterwards.
| AshamedCaptain wrote:
| > Distros don't have to do anything distro-specific to
| get signed. Most distros use (Microsoft-signed) shim to
| chainload to something like grub.
|
| You still have to get your own version of shim signed if
| you want your distro to boot "Scary Boot Prompt"-free.
| I.e. if you just use RedHat's version of shim, that shim
| will transparently boot RedHat signed kernels, but refuse
| to boot SuSE's -- unless you whitelist SuSE's key
| manually into shim. It's not ideal in any way.
| Arnavion wrote:
| I believe for OpenSUSE it uses MokManager to get the user
| to trust the OpenSUSE CA. But it's been a while since I
| tried it so I might be misremembering. (MokManager is
| broken on my mobo so I switched to systemd-boot + my own
| signing keys, which is better for security anyway.)
| Kipters wrote:
| Not disagreeing with the general message, but IMHO if a user is
| willing to go through the hassle of installing another OS, as
| easy as it is nowadays, I don't think toggling a bios option is
| _that_ big of a deal.
|
| As far as I'm concerned as long as it's possible to re-enable
| the 3rd Party CA (or disable Secure Boot altogether) it's not
| tragic considering this only applies to a specific kind of
| machines ("Secured Core PCs") and not to mainstream ones
| jillesvangurp wrote:
| There's a difference between stick in a usb key to fiddle
| with bios in vendor specific way and then stick a usb key in.
| It's an extra hurdle.
|
| If your instructions read: "turn off secure boot", MS has
| already won. Some users will, most won't, and many company IT
| departments would not allow you to on principle (because it's
| company hardware and they want it secured because it is their
| problem if it isn't).
| Avamander wrote:
| > If your instructions read: "turn off secure boot"
|
| That's the thing, you don't have to disable that. You just
| have to re-enable that CA if you have a model that has
| Device Guard enabled by default.
|
| > It's an extra hurdle.
|
| Hurdle that doesn't matter at all. If you have the skillset
| to install an OS, changing a setting in UEFI is nothing.
| noisy_boy wrote:
| > Hurdle that doesn't matter at all. If you have the
| skillset to install an OS, changing a setting in UEFI is
| nothing.
|
| That assertion is a bit too absolute; I am comfortable
| installing an OS using the USB installer because I have
| done it many times. I haven't had to change UEFI settings
| yet and I'm worried that doing something wrong will lock
| me out (in case of a botched OS install, I can just start
| over).
| Avamander wrote:
| Fair, that fear can be real, but it does sound rare and I
| think that's what the user manual is for.
|
| If we take the model the initial blogpost was about it's
| nicely documented: https://download.lenovo.com/pccbbs/mob
| iles_pdf/Enable_Secure...
| noisy_boy wrote:
| I agree - based on the steps in the link, it is quite
| straightforward.
| chrsw wrote:
| >You just have to re-enable that CA if you have a model
| that has Device Guard enabled by default.
|
| I run Linux on a used ThinkPad I got on eBay and I have
| no idea what this sentence means.
| friendzis wrote:
| > If you have the skillset to install an OS
|
| This is an extremely weird argument. So called Live CDs
| come from an era where CD drives were ubiquitous and even
| back then installing an OS (provided you did not want to
| install two OSes at the same time) was as simple as
| installing any other piece of software. If anything, with
| all these secure boot shenanigans it requires _more_
| skill to install an OS than when a smartphone was not
| even a thing. This argument advocates for walled-garden
| IT. This argument used in support of restrictions under
| the hood arguments for IT stuff to be hard in principle.
| Avamander wrote:
| Yes, the removal of CD/DVD-drives is as much of an
| obstacle to installing Linux as having to toggle a
| setting on a Windows-preinstalled machine that someone
| bought. You are also free to buy a SKU that doesn't come
| with a Windows license and Windows preinstallation.
|
| Also please keep in mind that it's not Secure Boot you
| have to disable, it's a CA you have to re-enable on
| machines that came with Device Guard pre-enabled.
| friendzis wrote:
| You miss the entirety of the point. Today you have a USB
| drive, nothing stops SOHO routers by default starting PXE
| server with latest distros which would be even easier to
| use. This is an artificial obstacle.
|
| You keep arguing all over the place that this is an
| insignificant obstacle, but do not address the very core
| of the debate: whether only MS keys being installed by
| default is for security purposes in the first place and
| whether it does actually increase security. We are not
| arguing how many hoops to install Linux (or whatever) is
| too much. we are arguing whether certain OSes should be
| easier to install at all.
| Avamander wrote:
| Don't bring it up as an obstacle if it's not an obstacle,
| that you're instead concerned about Microsoft's keys.
|
| In that case though, it's not "only MS keys" really, it's
| not enabling one CA. In the end if there's a strong need,
| Canonical, Red Hat or the likes could start building
| their own CA and negotiate it to be included, would be
| very fair and probably wouldn't be affected by this
| toggle. But they do not seem interested however in the
| much easier MS UEFI CA-signed Secure Boot, Ubuntu does it
| fine, but Fedora can't sign DKMS modules and the rest are
| even worse.
|
| So the thing is, the problem of "trust" is very complex
| and putting in the work is very expensive. Microsoft has
| chosen to do this to improve their customers' security,
| they offer others the opportunity to participate and few
| are actually willing. That's not their fault really.
|
| In the end they'd get slapped so hard by antitrust if
| they ever truly removed that toggle and the option to run
| other software. (Unlike Apple or other mobile vendors,
| who can do whatever they wish, with no such uproar over
| what is way worse than the toggle discussed here.)
| mjg59 wrote:
| This is a brand new ThinkPad. It's not a low-end consumer
| device, but it's not some niche machine.
| Kipters wrote:
| It is a niche compared to the millions of consumer laptops
| that are being sold though, as is the whole category
| R0b0t1 wrote:
| The deal is I want to control the secure boot process so that
| I can make the OS I choose secure. This is not always an
| option or possible.
| Kipters wrote:
| In this case it is an option, you can still disable UEFI
| Secure Boot, re-enable the UEFI CA and enroll your own
| keys. The only thing that changes is a default in an option
| you would need to alter in any case if you wanted to
| control the boot yourself.
| feanaro wrote:
| We shouldn't allow to inch towards this kind of situation if
| for nothing else than for not sliding the Overton window in
| the wrong direction.
|
| It's either a neutral organization signing certs which you
| then _have_ to accept by default, or you get fined. Those are
| the only acceptable scenarios.
| isodev wrote:
| What matters more in this instance is the rhetoric and
| messaging being used. Microsoft is using "Secure-core" as a
| measurement and indicator of security posture while at the
| same time installing a Linux-based system somehow detracts
| from that objective. It's not just a matter of technical
| ability. Organizations and people, in general, will be
| exposed to this, which is simply not true. For enterprise IT,
| this will also mean that by default, they will need to
| justify alternatives, creating extra friction for competing
| solutions.
| Avamander wrote:
| > Microsoft is using "Secure-core" as a measurement and
| indicator of security posture while at the same time
| installing a Linux-based system somehow detracts from that
| objective
|
| If you read what Secured Core or even Device Guard consists
| of, Linux actually does detract from it. I use Linux daily
| on all my machines, I have no sympathy towards Windows at
| all, but Linux has certainly fallen behind in some aspects
| - boot integrity and boot anti-tampering is one of those
| aspects. And that's not all Secured Core provides in the
| end.
| R0b0t1 wrote:
| Linux has fallen behind in boot security and anti-
| tampering because all of the solutions in this area are
| proprietary and at least initially released under NDA.
| You're using the effects of this very program to justify
| itself.
| Avamander wrote:
| Firstly, it wasn't a justification, it was a description
| of the current state.
|
| Secondly, no, they aren't all proprietary. If we start
| from the bottom then Secure Boot is neither proprietary
| or NDA'd. There are even open-source implementations of
| Secure Boot. We simply have a significant amount of feet-
| dragging and misconceptions out there, pointlessly making
| using _just_ SB alone difficult and not the default, you
| can see a bunch of it in this thread as well.
|
| I won't even get into measured boot to auto-unlock
| FDE/LUKS or god forbid LIM, those aren't difficult
| because of some supposedly NDA'd specifications. Damn,
| enabling IOMMU isn't that difficult either. Nobody else
| should be blamed for the poor state of those.
|
| Lastly, some standard being initially released under NDA
| or being proprietary (which ones do you actually have in
| mind?) is a terrible justification to not improve things.
| Or find alternatives just as good.
| drekipus wrote:
| > some standard being initially released under NDA or
| being proprietary (which ones do you actually have in
| mind?) is a terrible justification to not improve things.
| Or find alternatives just as good.
|
| I think them being NDA / proprietary is a _reason_ we can
| 't improve things, not a justification for it.
| AshamedCaptain wrote:
| > if a user is willing to go through the hassle of installing
| another OS, as easy as it is nowadays, I don't think toggling
| a bios option is _that_ big of a deal.
|
| It is trivially easy to boot from a USB pendrive; most
| computers will do it by default if there's no preinstalled
| OS, many devices have a hotkey you can press/hold which
| redirects towards booting from USB, and even Windows itself
| will outright let you do it from the Settings app. You don't
| even have to interact with the system firmware setup program.
|
| On the other hand, disabling secure boot (or taking ownership
| of it) is designed to be as difficult as possible,
| intentionally. Many vendors will actually have a Scary Boot
| Prompt or the like which makes you double-acknowledge when
| you change Secure Boot settings, and even reminds you (on
| every boot) that you have Secure Boot disabled.
|
| It is also unfair by itself that MS OSes will boot without
| requiring the user to fiddle with the system firmware, but
| non-MS OSes won't. This puts a glass ceiling on non-MS
| operating systems regarding how easy their setup flow can be.
| jaywalk wrote:
| > It is also unfair by itself that MS OSes will boot
| without requiring the user to fiddle with the system
| firmware, but non-MS OSes won't
|
| Unfair? You're talking about systems that come with Windows
| pre-installed. Of course these systems are going to be
| configured for booting Windows out of the box.
| esoterae wrote:
| >> It is also unfair by itself that MS OSes will boot
| without requiring the user to fiddle with the system
| firmware, but non-MS OSes won't
|
| >Unfair? You're talking about systems that come with
| Windows pre-installed. Of course these systems are going
| to be configured for booting Windows out of the box.
|
| I think it more _accurate_ to have said "of course these
| systems are going to be configured to boot nothing but
| Windows out of the box", which is ... drum roll please..
| anti-competitive. Facially, and blatantly anti-
| competitive.
| mistrial9 wrote:
| .. first read through all these comments here, but I see no
| mention of MSFT commercially inserting Canonical OS
| products into desktop windows, with extra features added to
| Ubuntu to restrict and control the internals.. examples are
| partition type msft-private and msft-data; secretive
| systemd components; secretive vmx flag use; boot signing
| and signed applications; snapd container for libssh with
| auto-updates required to be on.. and more?
| james-redwood wrote:
| The lack of transparency over the definition of 'secured-core' is
| disturbing.
| [deleted]
| Joel_Mckay wrote:
| Digital-locks like UEFI signing have a singular flaw, in that it
| only truly offers security to the people holding the signing keys
| i.e. a firm that did not pay for the computer, shouldn't be tying
| unsolicited services to other peoples businesses, and should be
| classified as an adversarial threat vector.
|
| If Libreboot wasn't such a pain to install, it would have saved a
| lot of grief.
| trelane wrote:
| > If Libreboot wasn't such a pain to install, it would have
| saved a lot of grief.
|
| Dunno if you need LibreBoot specifically, but if CoreBoot is
| sufficient, several vendors offer it preinstalled....
| Joel_Mckay wrote:
| The models system76 offer are interesting, but as a business
| choice we are forced to ponder if it makes sense support
| wise.
| jsiepkes wrote:
| > in that it only truly offers security to the people holding
| the signing keys i.e. a firm that did not pay for the computer
|
| That's not true. Practically all servers and more high end
| motherboards (even my HP zbook allows it) allow you to install
| your own CA's. Allowing you to create your own trust chain from
| firmware to OS.
|
| By itself there is nothing wrong with wanting a chain of trust
| between firmware and OS.
| Joel_Mckay wrote:
| Sure.. if you can manage your own keys and still install a
| normal OS, than you have done 2 things most home PC users
| will never do... and others simply cannot with a crippled
| factory BIOS. Yet we are not talking about servers, as
| features like Backplane administrative subsystems and hot-
| swapping internal bus parts are not standard on most PCs.
| Also, the Intel management engine and Computrace decedent
| features are not always removable, include their own CVE, and
| companies like Toshiba and Sony would trip the permanent
| asset flag at the factory forcing end users to adopt features
| they never asked for.
|
| "chain of trust between firmware and OS" assumes physical
| security in logistics and co-locations is perfect, and given
| the number of unsolicited network appliances we would get
| from vendors in some places I worked... a CA no one ever
| checks is the least of peoples issues. We avoided HP after
| the quality dipped for their fragile laptops, and some server
| firmware would reject generic storage options. ;-)
| jsiepkes wrote:
| > Intel management engine and Computrace decedent features
| are not always removable
|
| Intel ME and Computrace have nothing to do with UEFI
| secureboot.
|
| > "chain of trust between firmware and OS" assumes physical
| security in logistics and co-locations is perfect
|
| Secureboot isn't just about physical security. It also
| (probably even more important) ensures malware can't modify
| anything in the chain of trust. Meaning malware can't
| backdoor the bootloader and in turn also can't install a
| rootkit in the kernel. If you would modify the binary of
| the bootloader or kernel their signatures would be
| modified. The firmware (ie. UEFI) won't load the bootloader
| anymore (because the signature check fails) and the
| bootloader (which verifies the kernel signature) won't boot
| the kernel.
| Joel_Mckay wrote:
| Except there are already POC UEFI level rootkits that
| can't be detected by the host OS. Thus, such systems
| would appear to function normally to the common users,
| but offers zero benefit and may actually worsen the
| situation. Are you sure you are not confusing this with
| the TPM extensions?
|
| Again, one wrongly assumes a supplier hardware comes into
| a facility clean in the first place, and historically
| this process has already proven problematic to secure
| (Acer, Asus, Lenovo, CISCO etc.) ;-)
| aosmith wrote:
| I would feel better if this was spun off into a b-corp with a
| perpetual grant.
| yellowapple wrote:
| I agree, and I don't know why anyone would disagree
| sufficiently strongly to downvote your comment for suggesting
| that. Microsoft being directly in control over what can boot by
| default on PCs was and still is a blatant conflict of interest,
| and transitioning that decisionmaking to an independent body
| with input/control from more than just Microsoft would
| alleviate that considerably.
| justinclift wrote:
| Possibly better not under US control? Though I kind of reckon
| it'd have to be some inter-governmental thing rather than "pick
| a better gov". ;)
| usr1106 wrote:
| https://en.m.wikipedia.org/wiki/Benefit_corporation for those
| not familiar with US terminology.
| lmm wrote:
| At what point will mjg59 be willing to write the whole thing off
| as the anti-Linux measure that most open source fans have
| realised it is for a decade or more?
| jsiepkes wrote:
| Secureboot by itself is needed because otherwise you have no
| way of making a boot chain from firmware to OS which can be
| validated on x86. Meaning Linux (servers) also have a use case
| for it.
|
| I also highly doubt Microsoft sees the Linux desktop as a
| credible threat to Windows. ChromeOS is an actual threat to
| Windows. And this does nothing for ChromeOS. It's more likely
| it's just a poor, uninformed decision from a team at MS.
| selfhoster11 wrote:
| You don't need Secure Boot or PKI for that. Simple proposal:
|
| 1. The system includes a TPM. The TPM measures all relevant
| pre-bootloader firmwares.
|
| 2. On first boot, the system firmware hashes the bootloader
| and stores the hash. A bootloader upgrade may be initiated by
| the old bootloader at boot time, and will update the stored
| hash to the one for the new bootloader.,
|
| 3. On subsequent boots, the system will refuse to boot unless
| the user overrides the boot device, the user resets the
| stored bootloader hash, or the bootloader hash matches. The
| boot process then proceeds.
|
| 4. The bootloader may choose to continue measuring the system
| and updating the TPM, or skip the process.
|
| This proposal is platform neutral (will work on every
| platform with a TPM and system firmware), extremely simple to
| implement, not user hostile, and will not require PKI nor be
| hostile to users by default.
| kmeisthax wrote:
| Wasn't this the original proposal for what TPMs were
| supposed to do? I remember that and secure attestation were
| considered radioactive to basically the whole free software
| community.
|
| The scheme you are mentioning sounds like a
| hardened/serious version of those old "boot sector virus
| protection" things that 90s-era motherboards had. They'd
| checksum the boot sector and scream at you if it changed.
| Regardless, this scheme won't really fix the problem we're
| talking about - installing Linux on top of machines with
| Windows preinstalled.
|
| Preinstalled systems will already have a Windows bootloader
| hash measured and locked before you even get at it. If it
| doesn't, that means you're building your own machine from
| an off-the-shelf motherboard, so none of this matters[0].
| If you want to seamlessly[1] install Linux on a machine
| that's already running Windows, you need PKI that trusts
| both - either with Microsoft cross-signing Linux distros'
| bootloaders, or OEMs including both Microsoft and common
| Linux distro certs.
|
| There's also a related problem here: if you _are_ first-
| booting a machine without an OS, you have no chain of trust
| at all. This is a trust-on-first-use scheme, the problem
| being that it has nothing to protect against, say, NSA /TAP
| implants[2]. You're trusting that the machine that
| downloaded your Ubuntu ISO and flashed it to a USB stick
| hasn't already been compromised and isn't slipstreaming in
| more malware onto your stick. Or that your machine with
| Linux preinstalled wasn't opened up and stealthily modified
| before you got to boot it. PKI has an advantage here in
| that it doesn't just validate that the bootloader hasn't
| changed - it also carries the reputation of the signer,
| which can be damaged if they sign malware.
|
| [0] Most motherboards for DIY builds don't even bother
| configuring Secure Boot - and the people buying them will
| know how to jump through whatever hoops are necessary to
| get Linux to run if they want it.
|
| [1] though tbf the Asahi Linux people really did a good job
| of getting the installer to be seamless and easy on M1
| Macs.
|
| [2] While a government could compel Microsoft to sign
| malware, that would also create irrefutable evidence that
| Microsoft's keys had been compromised. The spooks really
| don't want to do this because such things could easily be
| traced back to them.
| selfhoster11 wrote:
| > The scheme you are mentioning sounds like a
| hardened/serious version of those old "boot sector virus
| protection" things that 90s-era motherboards had
|
| Yes! In fact, I wanted to mention boot sector virus
| protection in my comment.
|
| > Regardless, this scheme won't really fix the problem
| we're talking about - installing Linux on top of machines
| with Windows preinstalled. Preinstalled systems will
| already have a Windows bootloader hash measured and
| locked before you even get at it.
|
| Part of this scheme is that the user is able to reset the
| bootloader hash at will, even on preinstalled and hand-
| me-down machines that were initialised or pre-initialised
| by somebody else already. So if one receives a machine
| with Windows preinstalled, then that shouldn't be a big
| deal as the bootloader hash can be reset in the firmware
| settings on boot. If the firmware doesn't let you do
| that, well... That's as bad as current Secure Boot for
| user hostility, but at least PKI is not injected into the
| mix to make it worse.
|
| > If you want to seamlessly[1] install Linux on a machine
| that's already running Windows, you need PKI that trusts
| both
|
| It's possible to dual-boot with chainloading, or simply
| update the system to support N hashes rather than just
| one. 1 kilobyte of storage will fit 32x 256-bit hashes,
| so that's not a lot of space even in NVRAM-constrained
| environments.
|
| The only issue I can see with dual-booting and
| chainloading, is if the change to the boot process messes
| with some TPM registers and the OS that is already
| present on the machine is unhappy about that - but it
| seems like a tractable engineering problem.
|
| > This is a trust-on-first-use scheme, the problem being
| that it has nothing to protect against, say, NSA/TAP
| implants[2]
|
| Correct. But that sounds like a Trusting Trust attack on
| your firmware, against which Secure Boot cannot stand
| either.
|
| > PKI has an advantage here in that it doesn't just
| validate that the bootloader hasn't changed - it also
| carries the reputation of the signer, which can be
| damaged if they sign malware.
|
| OK, I will admit that is one advantage. Counter-argument
| I would propose, is that you should be installing the OS
| with known-clean, preferably read-only bootable media in
| the first place. That way you can verify the hash and
| authenticity beforehand in any number of ways, and remove
| complexity from the boot chain. This used to be the main
| way to install the OS before the Secure Boot era, as
| everyone was distributing OS installers on WORM media.
|
| > I remember that and secure attestation were considered
| radioactive to basically the whole free software
| community.
|
| Can you blame us? ~~Android's~~Google's SafetyNet is
| essentially a remote attestation API that a great number
| of banking apps rely on, and they refuse to launch unless
| they can see that SafetyNet status is intact. What good
| is the ability to replace a ROM or gain admin access, if
| half of the security-sensitive apps on your phone stop
| working? Remote attestation is here, and it sucks.
| kmeisthax wrote:
| Totally agree with you on SafetyNet, and the fact that
| it's used by so many apps that don't need it feels like a
| betrayal of trust.
|
| What you mentioned about read-only media is how secure
| boot _should_ be implemented, too. Or at least it 's how
| Apple does it: all the boot chain verification code lives
| in mask ROM so the only way to compromise it is to either
| find a bug (rare and expensive) or compromise the chip
| vendor (very "loud", spooks don't like this). The only
| problem with this setup is that Apple does not give two
| hoots about vendor neutrality[0] and this sort of scheme
| requires trusted roots to be burned into the chip.
|
| Not being able to reset the boot hash is actually _worse_
| than current Secure Boot. The problem being complained
| about isn 't dualbooting. It's that Microsoft is making
| you jump through additional hoops. There's still the
| ability to turn off Secure Boot; that's the moral
| equivalent of "resetting the boot hash" in your proposal.
| But we don't want to make users do that; we want the
| machine to just say, "oh this is the trusted Linux build,
| go on right ahead" without any extra mess or fuss. Linux
| distros jumped through hoops a decade ago to get a secure
| boot path signed by Microsoft - not to enable it to run
| at all, but just to make installation and usage easier.
|
| [0] They _do_ provide an owner-override on Macintosh-
| fused chips, which is actually implemented in a really
| cool, user-friendly way. But that 's moreso for letting
| the user build their own kernels rather than a serious
| attempt at being vendor-neutral.
|
| Presumably in the alternate world where Microsoft hadn't
| signed over Windows on ARM to Qualcomm, Apple would be
| signing a Boot Camp bootloader that validates Microsoft
| keys.
| FeepingCreature wrote:
| How big do you think Microsoft's threshold is to fuck a
| competitor over? It sounds like you're saying Microsoft is
| slow to rouse to malice; I don't think that's how they work.
|
| If they can head off a competitor early for little
| investment, I believe they will do so - are doing so.
| AshamedCaptain wrote:
| Well, I guess the point of this "collaborateur" deal was that:
| by making Linux bootloaders and distributions go through the MS
| vetting, getting most Linux distributions signed by MS,
| perilous as the situation is, we'd still be getting at least a
| couple more years of Linux distributions booting hassle-free
| even on Secure Boot systems. We did get an extra decade at
| least, as you mention, so I think the "collaborateur" effort
| was not completely wasted.
|
| The only thing I would demand from these collaborateurs now is
| _not_ that they apologize, but that they simply make as much
| noise as possible since it was MS who changed the deal, not
| them.
| xenophonf wrote:
| _The apparent secured-core requirement for 2022 is that [...] out
| of the box, these systems will not boot anything other than
| Windows._
|
| I don't see how anyone can look at the history of Microsoft and
| not immediately judge this as being completely anti-competitive
| in nature.
| NoGravitas wrote:
| I'm shocked. Who could ever have foreseen Microsoft doing such a
| thing?
| nvr219 wrote:
| Re this website itself: Love seeing LiveJournal code base still
| in use.
| denton-scratch wrote:
| This seems to be MS's response to a rather serious mistake in
| GRUB2 - a howler, I'd say.
|
| I've never liked GRUB2 much. The configuration seems to freely
| mix executable code and data, which makes me tremble at the
| prospect of altering it. And I find it much harder to understand
| than GRUB Legacy (and that's saying something).
| password4321 wrote:
| I recently learned about EFISTUB thanks to
| https://news.ycombinator.com/item?id=31231968&p=2#31234648
|
| > _Load Linux directly as an EFI executable via the EFISTUB
| approach._
|
| > _the "Using UEFI directly" section [...]
| https://wiki.archlinux.org/title/EFISTUB _
| Arnavion wrote:
| As shitty as it is, it's nice of Lenovo to at least make it easy
| to enable the second CA. I wonder if all OEMs will be as "nice",
| or if any will require you to boot into Windows just to edit the
| EFI variables to add the second CA.
|
| Edit: Also, I've read a few horror stories of systems no longer
| displaying anything after the UEFI CA was removed from the
| trusted CAs, because there was no iGPU and the discrete GPU
| required an OpROM. No display meant no way to boot into the UEFI
| firmware to revert that change or even disable SB. How is that
| not a problem now?
| jsiepkes wrote:
| There used to be a requirement by MS mandating secure boot to
| be disable-able. Though I think they scrapped that requirement
| later on. No idea if third party CA enabling also has such a
| requirement.
| [deleted]
| cesarb wrote:
| > There used to be a requirement by MS mandating secure boot
| to be disable-able.
|
| Not always, in some situations there was a requirement by MS
| mandating secure boot NOT to be disable-able:
| https://softwarefreedom.org/blog/2012/jan/12/microsoft-
| confi... "Disabling Secure [Boot] MUST NOT be possible on ARM
| systems."
| usr1106 wrote:
| Disabling secure boot is one thing you should be able to do
| with hardware you own. Of course that's not a good idea if
| you want to run a non-Windows OS in a secure manner.
| Installing your own CA cert should also be possible. That's
| what we do at work with current UEFI implementations.
| AshamedCaptain wrote:
| On the early Surface Pros at least, you had to boot into
| Windows and run a PowerShell script to enable the MS UEFI CA
| certificate. These days it looks like they made it a option on
| the system firmware.
| Arnavion wrote:
| Yeesh. Yet another thing to check for before buying a mobo /
| laptop.
| trelane wrote:
| If you want to run Linux, _stop buying Windows hardware
| already_
| Harvesterify wrote:
| Previous discussion:
| https://news.ycombinator.com/item?id=32023868
| chr15p wrote:
| that was a discussion of a previous blog post by the same
| author (Mathew Garrett). Its on the same subject but this one
| is much longer and goes into much more detail.
| zzo38computer wrote:
| Secure boot is one problem with UEFI but it is not the only
| problem.
| ysnp wrote:
| >But unfortunately the 2022 requirements don't seem to be
| publicly available, so it's difficult to know what's being asked
| for and why.
|
| Where can we find the full requirements for a device to be
| Secured-core?
___________________________________________________________________
(page generated 2022-07-12 23:01 UTC)