Hacker News new | past | comments | ask | show | jobs | submit login

Hi guys, I am part of the team working on all things T2. [1]

The checkra1n support is just in a PoC state, it will successfully exploit and boot the T2. The payload support is partially broken, but being worked on.

Additionally, we have SSH working over usbmuxd from a tethered device [2] and SSH working from macOS on device, with an SDK in the works [3].

Some key takeaways from the T2 being jailbroken:

- Custom Bootloaders (OpenCore, Coreboot, etc) are now possible as the T2 validates/sends the UEFI payload to PCH using a bridgeOS binary called MacEFIUtil, which can trivially have its signature checks patched.

- Filevault and by extension Touch ID are more or less crippled, especially in light of the recent SEP exploits. Amusingly, Apple uses a hardcoded "passcode", analogous to an iDevice's unlock pin in plain text within the UEFI firmware.

- Support for In-System Debugging of the PCH/Intel processor over USB. This works in a similar fashion to those Bonobo cable used for debugging iDevices [4]. We are working on building an accessory that you can purchase and plug into your Mac with a USB male endpoint exposing Intel's DCI debugging protocol.

- Lightweight AppleSilicon Tinkering environment. With SSH support from macOS on device, and the T2's modest specs, its a nice sandbox for messing with arm64 stuff. It's a pretty peppy chip, at times coming close to my 8th gen i7...yikes.

1. https://www.theiphonewiki.com/wiki/T8012_checkm8

2. https://twitter.com/qwertyoruiopz/status/1237904335184564224

3. https://twitter.com/su_rickmark/status/1286886010681462784

4. http://bonoboswd.com/

> Filevault and by extension Touch ID are more or less crippled

Sorry, what does this sentence mean? That someone with physical access to my machine can now unencrypt my FileVault encrypted hard drive?

The Secure Enclave on the T2 chip was used to store secrets that were supposed to stay inaccessible, even to someone with physical access.

If you use a strong password to encrypt your drive you should still be safe, unless Apple did something really stupid. The password is used as a one-way hash to generate the key.

However if you can login with Touch ID and they find a way to use known SE exploits, it's compromised. Your fingerprint isn't a secret that gets hashed – instead it's verified by the SE which also holds the secret key for the drive.

Isn't a password always required to decrypt on a cold boot?

Yes, but that doesn't help you if someone steals your MacBook when it's asleep.

Someone would have to DFU your laptop before hand and jailbreak the chip, since booting into DFU requires shutting the system down.

Wouldn't this mean the 'secure' values for these two processes within are now visible/ readable with the right tool/protocol availability?

Some one from Apple, I'm sure you read this. Please answer this ASAP. I rely on mac and FileValute for professional use at work. Need to know the state of this exploit.

lol good luck and god bless with all that.

> I rely on Mac and FileVault for professional use

... then phase out your use, because proprietary systems will always get cracked given enough time.

Good point, let’s switch to unbreakable open source systems based on OpenSSL instead.

This kind of advocacy is not only unhelpful but actually counterproductive

Software encryption is very often much easier to rotate than integrated solutions. When all the TPM chips were broken, Windows stopped using them for BitLocker, but didn't reencrypt any of the affected disks. They're just as vulnerable as they were.

Software encryption is also harder to protect without a trusted boot path. My point was just that this isn't a simple binary decision but rather something which requires review and defense in depth.

>FileVault for professional use

Probably not the best choice :) you never want to use proprietary software if security is a concern

Go count how many CVEs have come out for OpenSSL, GNUTLS, LUKS, etc. and ask whether you’re offering helpful advice. Security is expensive and there are no silver bullets: at the end of the day you need a lot of skilled work and being open source doesn’t magically get that for free.

That's apples and oranges.

Counting published vulnerabilities in open source systems vs closed source systems says nothing about the relative true ratio of vulnerabilities.

Are you seriously claiming that anything short of omniscience is useless? In most fields people deal with incomplete data on a daily basis and this is no different. CVEs don’t tell you everything but they definitely give you more than zero, and more to the point, the many vulnerabilities in open source projects suggests that the very broad but completely unsupported claim I was responding to is based on ideology rather than reasoned analysis.

> the many vulnerabilities in open source projects suggests that the very broad but completely unsupported claim I was responding to is based on ideology rather than reasoned analysis

Does it? In order to claim that, one would have to have some idea of (a) the ratio of disclosed vulnerabilities to true vulnerabilities discovered in both open source, accessible code vs closed source, hardware locked code, and (b) the relative ratios of disclosed vulnerabilities.

Do you have any idea what either ratio might be? 1:1? 4:1? 1:4? 100:1?

Again, the comment I responded to made an absolute claim but, like you, had no supporting evidence. Unless one of you can produce some evidence it’s hard to support the belief that this is based on data.

If you read the thread, note that I’m not taking a side other than finding it absurd to claim that all open source products are inherently better than all proprietary products with no analysis or data.

Unless you know the true ratio, you can't claim that open source projects are better either. Or that one has advantages over the other when it comes to cryptographic security.

I'm not GP and I'm not arguing for either side, just pointing i tout.

I disagree. There are times when either no open-source solution is available, or the open-source solution is unmaintained, or not popular (thus not under much scrutiny) and you don't have the resources (time and skill) to audit it yourself.

As long as the incentives of the developer of the security scheme and the end-user are aligned (so no backdoors), I would trust a widespread, proprietary solution which appears to stand up to significant attacks (the solution being widespread means there are lots of efforts underway to crack it) more than an open-source implementation that nobody uses.

As it stands now, from my understanding, the failure case of the proprietary solution is the same level of security as the best case of the open source solution. So I don't see your point. Open source isn't any better.

Open source full disk encryption can be password cracked without limitations just like a hacked T2 chip. A sleeping open source full disk encryption machine can be accessed with enough skill to pull things out of frozen ram, etc.

What is a non-proprietary solution for full-disk encryption?


luks or zfs.

I want not note, that ZFS is not full disk encryption. ZFS native encryption was designed to allow secure backups via "zfs send | zfs receive" mechanism, so it encrypt only data blocks, and not metadata.

LUKS and GEIL are full-disk encryption systems, and if you need FDE, you must use them under ZFS, not ZFS native encryption.



ZFS native encryption on Root is ~IS full disk encryption minus the boot-loader, i would say that's "full" interesting data encryption.

Technically true but what is the situation that become problem?

Or Veracrypt.

Incredible work.

> It's a pretty peppy chip, at times coming close to my 8th gen i7...yikes.

Have you got any benchmarks? It is passively cooled right? I am really surprised to hear a ~2016 arm64 CPU can can beat a 2019 Intel i7 in even synthetic benchmarks.

Some synthetic benchmarks are so simple that they almost reduce to a measure of CPU clock speed and instruction parallelism. Find a benchmark that uses a unique instruction combination on one CPU and it will heavily disadvantage the other CPU.

Add a real world workload to the mix with heavy memory access and mixed compute workloads and the chips will diverge significantly in performance.

I work with some cross-platform code that has to run on mobile devices and desktop platforms. The advances Apple has made in low power performance are incredible, but the idea that their iPhone chips are as fast as desktop computers is still far from the truth unless you’re measuring specific, heavily optimized workloads.

I’m still excited to see what Apple can do with a full desktop level power budget though.

I suspect the "benchmarks are stupid" comments will die down the moment people start running desktop software on these chips, because it will cease to be a convenient excuse. While benchmarks may occasionally be slightly misleading, they are usually a good indicator of performance if done well–and if you've ever actually run desktop-class software on one of these chips you'll see that the divergence is just not there.

Not to be stickler but he said come close, not beat. Not that it's any less impressive.

Mostly synthetics and some program compilation (configure+make) tests. Yes, it is passively cooled. To clarify, it does not match the host Intel CPU (i7-8750H @ 2.2GHz) but in some synthetics, i.e. Coremark, the T2 does come close. I would attribute the i7's lackluster performance mainly to thermal throttling issues.

A ~2017 i7 is only 4% slower than a ~2019 i7:


Userbenchmark is not a good site to use. Although it is typically the first search result, most hardware subreddits have banned it or issued notices on how biased or even false their content is (eg. An i3 considered better than a Ryzen 9 3900x).

Thanks for the heads-up, TIL.

T2 was first introduced in 2018 MacBooks. 2016-7 iBridges run on T1

>Custom bootloaders are now possible

This is interesting; does this mean Apple isn't enabling Intel Boot Guard, relying only on the checks enforced by MacEFIUtil?

Fantastic work, by the way.

They aren’t, they’ve removed much of the Intel software that is usually included with UEFI except what is required for DRMed video. If the T2 is compromised, they say that one could compromise UEFI on the device permanently as well.


...this is starting to feel like a major screwup on Apple’s part, is there a reason to think otherwise?

Yes, although now the Mac is as secure as any PC with UEFI Secure Boot (and no Intel ME), which isn’t necessarily the end of the world if you have a long firmware password (which protects the Recovery Mode secure boot utility) and login password (which protects FileVault). If you’re in a position where you could be compromised by a state actor or a hacker group (that can find a public flaw in Secure Boot that isn’t just turning it off), perhaps throw away your Mac, but everyone else should still be “okay”.

Part of me wonders if there could be a way to permanently disable DFU mode (preferably outside of epoxy in the upper left USB-C port). That would prevent someone from jailbreaking the T2, albeit you would no longer be able to replace the SSD or Touch ID sensor (not that you’d want to anyway if you were at risk).

Unfortunately, physically obstructing the primary port would not completely prevent DFU from being accessed. With the aforementioned accessory device, the ACE Type-C controllers within Macs can automatically reroute the DFU, DCI, and PCH/T2 UARTs to any of the other ports, irrespective of the T2 and PCH. Apple uses this technique as part of their factory test harness.

Also the USB-C ports are not on the MLB, they are on I/O boards that can fairly easily be replaced …

You guys are fighting the good fight for everything that owning hardware and being a user used to mean. Thank you.

I never understood this sentiment, if people choose to pay their way into a walled garden, why should they still care about hardware ownership/repairabilty, etc.?

It's a trade-off. I buy MBPs for the great form-factor and OS, not for the walled-garden shenanigans. If those shenanigans can be somewhat reduced, the trade-off balance looks better.

I don't mean to me facetious, but I am genuinely curious: why should you get to have it your way? You are attempting to buy a product they do not sell.

After you buy your hardware it's yours to do with as you will. If these hacks result in the ability to load whatever you like on the T2 and intel proper then why not? Hackers like to hack. A lot of programmers are also hackers (in the traditional sense, not the negative sentiments that the press gives it)

Then perhaps they should sell it, and stop ignoring people who want it?

Benign neglect (not creating limitations) is not the same as active interference (actively preventing) and Apple is much more on the side of active interference. They could simply do nothing (which is cheaper). They choose not to, at which point we get to question their motives.

In the end your question reduces to "why do you want anything at all that someone doesn't already make?" and that doesn't make alot of sense given that new products come out on the market all the time.

Why would I not? Why should I accept everything companies do without ever complaining? Am I not allowed to tell the fishmonger that his fish doesn’t look that fresh to me? In the same way, I’m free to tell Apple their fish would taste better with some adjustments.

Because a hardware vendor telling you what you can and can't do with the stuff you own is immoral.

Then don’t buy it? It’s not like Apple is the only vendor.

Kind of hard to have diversity/options if everyone keeps insisting all vendors do everything the same way.

I can buy what I want and also do what I want to what I purcwhased.

People can use their mouths to say at least the fact of flaws the product and services you purchased which acts as an advice to not purchase them

The downvote button on Hacker News doesn't work like a dislike button by the way

Or instead of that, people can engage in the entirely legal act of both purchasing it, and the entirely legal act of hacking it.

Customers have a legal right to do basically anything they want with something that they own.

First sale doctrine says if I buy something, I now completely own it and I can do as I please with it, even if it goes against any of the former owner's wishes or intent.

Apple bossing around its users doesn't increase diversity for anyone, it only artificially reduces its users' options.

I'm a happy iPhone, iPad and Mac user but have also jailbroken some of my old iPhones before so they could be used by family in China.

In the arguments about opening up the iPhone and forcing Apple to allow third party app stores and allow side loading I'm on Apple's side. I think Apple should decide what products they design, how they design them and what features they should have. If I like the feature set, I'll buy the. I do not think it's reasonable for other people to dictate to Apple what code they should write and how it should work, health and safety or deceptive marketing aside. The ability to side load apps would be a software feature that needs to be designed, coded, QA tested, secured etc. Who gets to make all those decisions? I don't think it makes sense to force Apple into doing these things if it doesn't want to do them. You don't like the inability to side load? Buy another phone.

On the other hand once I own a device, it's mine. If I have the ability to jailbreak it, or hack it, or do whatever to it that's my business, not Apple's.

> The ability to side load apps would be a software feature that needs to be designed, coded, QA tested, secured etc.

Apple of course has an internal version of iOS that lets you do this.

Would the current side loading capability, requiring a hard link to a Mac and an install of XCode, satisfy those calling for a side loading capability for consumers? I doubt it, but that's my point. Who gets to decide what satisfies any such requirement? Building in the features to support third party app stores is even more of a can of worms.

The state decides obviously, the entity in charge of making the rules.

The public version lets you do this. Just a week at a time.

"if people choose to pay their way into a walled garden, why should they still care about hardware ownership/repairabilty, etc.?"

I don't like the walled garden but i still brought a iPhone because iPhones get updates for really long time(3 years minimum). Iphone SE(1st gen) released in 2016 got the iOS14 update.

I'm in the same boat as well :) . I keep a mac laptop for work/consulting stuff and otherwise have a linux box and several rpi's for my linux hacking hobbies :)

We don't live in a world with a robust operating system market where people can pick and choose the perfect option for them. You have three choices and they are each going to be a mixed bad of good and bad features for almost everyone.

Mac hardware traditionally holds resale value. The T2 chip threatens to turn that hardware into a brick once resold. So beyond that jailbreaking ultimately makes the user's data more secure once Apple repairs and releases a fix (likely only going forward with new hardware) the jailbreak will cure the problem with aftermarket bricks for hardware with this T2 chip.

Where and how do you see the T2 chip being the mechanism that Apple stops reselling of hardware?

Yes it could be used that way. But they have never even indicated that they've been thinking of using the secure enclave for that purpose.

It's not an intentional anti-resale feature, but it does make repair a lot harder, because it locks (or at least, can lock) specific hardware components to the motherboard. This means if something on the laptop breaks, you can't repair it without the T2 chip knowing about it and potentially refusing to work. Apple has at least told their authorized repair partners that failing to register the repair with Apple may brick the device should Apple choose to further lock down unauthorized repairs in future firmware updates.

The T2 also has a particularly wonky approach to disk encryption. It uses a key management approach where neither you nor Apple control the actual key material. This means that a dead T2 takes your data with it and there is no recovery. In pre-T2 MacBooks, Apple had a lifeboat connector which could be used for data recovery from the soldered-on SSD. They got rid of this with the T2, because there's no point - only that specific T2 in that specific motherboard is ever able to decrypt the data.

Data recovery - in an era where you have to go out of your way to keep your data out of the cloud, backups are easier than ever and can be done wirelessly - this is going to be your major objection?

Please. As for matching parts to the motherboard, they have a point when it comes to I/O devices. It’s probably way more cloak and dagger than most people will ever have to worry about but it’s not unheard of. Again, if you don’t want to think about such things and want a device that trades ease of repair for improved base security why isn’t that something that shouldn’t be a choice?

I’m generally pretty pro right to repair, but as with anything there are pro’s and con’s to all choices and I’m not fond of several of the right to repair arguments for government regulation being made. Apple is far from the only maker of computers out there. It is the only maker of macOS, but that still doesn’t justify people trying to dictate their business model - especially when many aspects of their business models are major reasons why I prefer their platforms.

The cloud is not going to replace local storage until low-latency, high-bandwidth internet connections become widespread and you can do iSCSI or similar with your cloud service. This is not going to happen anytime soon.

Until then, clouds operate on a best-effort basis, some of which rely on hacks or break common use-cases (I can't put a Git repo in iCloud for example, and it doesn't perform well with lots of small files, and accessing the iCloud folder from the terminal apparently has problems). Why is iCloud still not a supported target for Time Machine, Apple's official backup solution for macOS?

But isn't the repair being harder a net-benefit for the consumer? It's not like the repair is arbitrarily harder. It's harder because the repairs in question deal with the TouchID sensor and the SSD, like you said. I wouldn't want someone being able to access my data just by replacing a component on the computer that then bypassed all the security systems present on the computer. It's the same situation as when replaced displays on iPhones were causing issues because repair shops weren't moving over the TouchID sensor. The cost of that security is that I need to have my data backed up but that's a best practice anyways for anyone that values their data.

"You should have had a backup" is not an acceptable excuse for not having a data recovery mechanism. Furthermore, full disk encryption is not bypassable in the way you suggest. Your login password is (supposed to be) the key material for the encryption, which is stored off-device, preferably in your head. In other disk encryption systems that are not locked to a particular encryption chip, if you take the disk out of the machine and plug it into another machine, it won't be readable unless you have that password.

Furthermore, most people do not make this calculation in their head of "Okay, anything I put behind the T2 is Apple's property now so I'd better have unencrypted backups". They just buy the computer that works and says that it keeps thieves and snoops out of their data. Everything we're talking about with backups comes as a post-purchase surprise, usually AFTER the data is already lost.

>Your login password is (supposed to be) the key material for the encryption, which is stored off-device, preferably in your head.

This is referencing the Touch Bar repair which means that the user has encrypted their drive with Touch ID. The only reason any repair would be harder is because the Touch ID sensor is paired to the secure enclave. The same goes for the SSD. Without the key, as you stated, you shouldn't be able to access the data so I don't see how that's any different than "having a data recovery mechanism". A data recovery mechanism shouldn't exist if you don't have the proper keys.

They also indicated they'd never ever use Mac's notarization requirement to block legitimate software.

Then they got in a legal fracas with Epic and immediately retaliated against Epic by banning all their software from all Apple hardware!

Apple has shown they are very eager to use their position of power to strong-arm the competition, and these kinds of chips only add to their power.

That's a very disingenuous assessment of the situation at hand. Epic knowingly violated their developer agreement. There was no retaliation. There was the consequences that were written into the developer agreement that Epic agreed to.

Apple revoked the developer accounts that Epic uses, so Epic could no longer notarize their (unrelated, MacOS desktop) software. No matter what you think about the lawsuit, you have to admit that Apple used their position of power to strong-arm the competition, and went against their promises to end-users regarding notarization.

They revoked the developer accounts because Epic intentionally violated the rules of those accounts. What you're doing by blaming Apple amounts to blaming the police for arresting a criminal that broke the law. Epic knew ahead of the time what the consequences were for violating the agreement and they knowingly did that. There was no strong-arming involved. The judge even stated in her initial briefing that Epic overstepped their bounds and didn't even need to do what they did to file their lawsuit. The only reason they did it was to try and stir up a PR storm but that backfired on them.

Sure, whatever.

Apple promised to the users (not Epic) they would only use notarization to block harmful software. Epic's software is not harmful to the user, and the lawsuit didn't change anything about that.

> Epic knowingly violated their developer agreement. There was no retaliation

I think you don't understand how this works. The agreement itself is the subject of the lawsuit and thus MUST be violated in order to show harm. Epic did it on purpose in order to sue Apple and whether you agree with that or not, it is the only mechanism the law allows to make the agreement itself the subject of the suit. And Epic does have a right to sue Apple for whatever reason they choose.

This is quite incorrect. Epic can already demonstrate financial harm due to the 30% fee that Apple has been collecting. They did not also need to break the agreement in order to bring the lawsuit. The judge literally recommended they cure the breach and put Fortnite back on the App Store while the lawsuit was pending.

>Epic can already demonstrate financial harm due to the 30% fee that Apple has been collecting

Not to the consumer.

No they did not do that at all.

macOS will deprecate older Macs 6-7 years after their release. You can use older Macs as Linux machines, with one of the BSDs, or with Windows.

The T2 chip can prevent people from putting their OS of choice on their hardware once Apple deprecates support for their machine.

> macOS will deprecate older Macs 6-7 years after their release.

This is substantially inaccurate. Current versions of macOS run on nearly all Apple systems from 2012 (8 years old), with the exception of some 2012 Mac Pros. The limiting factor in most cases is GPUs -- macOS 10.14 and later require some GPU capabilities which weren't reliably available in 2012.

No, it is substantially accurate.

Catalina, released in October 2019, dropped support for MacBooks released before 2015, MacBook Air models from before mid-2012, MacBook Pro models from before mid-2012, Mac Minis from before late 2012, and Mac Pros from before late 2013[1]. Do the math and that is 5 to 7 years between initial release of the hardware and deprecation by macOS.

[1] https://www.macworld.co.uk/feature/mac-software/what-version...

> dropped support for MacBooks released before 2015

Those machines were all sold in 2011 or earlier. Saying "before 2015" is misleading, because the MacBook name was used during two disjoint periods to refer to two completely different machines.

Between 2006 and mid-2011, the MacBook brand name was used for a line of low-cost Core 2 laptops, most of which had plastic cases. (Some sales to schools continued through 2012.) These are the laptops which were not supported by macOS 10.14 and later.

Between mid-2011 and 2015, there were no computers sold under the MacBook brand. Apple only sold laptops under the MacBook Air and MacBook Pro brands during this period.

In 2015, Apple reused the MacBook brand name for a line of 12" ultraportable laptops. These are supported under current releases of macOS.

> Those machines were all sold in 2011 or earlier. Saying "before 2015" is misleading

No, models release before 2015 were deprecated. Same thing with the models of other lines that only had 7 years before being deprecated by macOS.

My point is that, in this context, "models released before 2015" really means "models released before 2012", because there were no MacBook computers on the market between 2012 and 2015. Using the phrasing "released before 2015" implies that there were some MacBooks from 2014 which Apple dropped support for, which is not the case.

There is no evidence that is going to be the case. I can still use bootcamp on legacy machines, I don’t see that changing with the T2.

There are people who want to run Linux on their Macs with the T2 chip, but can't.

They can by turning off secure boot.

Probably comes down to definition of choice. Up thread someone else is describing how a particular macbook is the only hardware meeting their criteria but the OS is hobbling them.

I'd be interested in a real study that actually measured how often people are explicitly choosing the walled garden, and how often they're choosing something else that the walled garden "happens to come with".

My money is on the second option but AFAIK there's no study like this.

My guess is most people have no idea what a walled garden is.

because they want a macbook, just disagree with apple on who should be able to fix it. the choice you mention doesn't exist, it's an illusion. you can't buy a macbook that apple allows you to fix yourself.

For the same reason some people will buy a BMW and swap out the exhaust or add a turbo with their own two hands. Because it gives them the combination of customization, challenge, and capabilities they want.

Thank you for your work!

Do you have any thoughts about what Apple's switch to own-brand ARM chips in laptops and desktops will mean for T2/T3/etc?

The T2 was more or less a stopgap solution between their current Intel-based offerings and the AppleSilicon devices in regards to their security aspirations. My understanding is that there will be no T3, as evidenced in the DTK, which makes a lot of sense considering how identical these chips will be to their mobile counterparts.

I'm a user on a 2019 16-inch MBP (MacBookPro16,1) who hopes to move to Linux as my base OS on this hardware full-time over the next 12 months. (https://github.com/Dunedan/mbp-2016-linux)

This is because I honestly cannot find a laptop with the combination of 64+ GB RAM, a non-NDIVIA GPU (edit: to clarify, this is because of NVIDIA's notoriously bad compatibility with Linux), and other premium hardware aspects like its market-leading trackpad at this time - and I doubt that will change anytime soon.

I live with the debilitating T2 kernel panic hardware bug every week. There's also a very bad graphics bug that I and many others are facing. (Not sure if that one can be avoided by simply using Linux.)

I just want to do away with this T2 chip, and whatever it does to get in the way of an otherwise great Intel-based computing experience. The CPU can handle all my encryption just fine...

Thank you to your team for what you're doing. I assume Apple will constantly patch T2 jailbreaks with future macOS system updates (as that's how firmware is updated), and play a long-term cat and mouse game.

While it doesn't entirely meet your specs you can get a T495 with 32GB of RAM [0] and Vega graphics. We're getting close, I am holding on to my T470 as a daily driver and it's one of the best laptops I've owned (I'm forced to use a 16" MBP for work as well - and I still prefer the T470).

One of these years we'll get a comparable AMD laptop. Fingers crossed.

[0] https://www.lenovo.com/us/en/laptops/thinkpad/thinkpad-t-ser...

The T495 is my daily driver. I love this machine and I plan on using it for many years to come.

How can you all handle the low-resolution screen? I want one of those Lenovo laptops but with a higher resolution screen

Well I have slightly lower vision than most people so it prob doesn't bother me as much as it would most. But yeah that's an issue. I was actually so excited about the other components when I bought it that I kind of overlooked the resolution specs. I was / am disappointed about that aspect of it, but everything else is awesome.

Why without an Nvidia GPU? Just go with an XPS 15 or 17 and embrace Nvidia on Linux. I have three developers running Linux on HP zBooks with Nvidia GPUs without any hassle.

You can also buy any newer Thinkpad (my recommendation). They are also available with AMD CPUs.

It's pretty easy to buy Linux laptops these days.

Everyone in the Linux space, from what I regularly read and hear, says that NVIDIA GPUs are notorious and a bad idea for using Linux. They're saying go with AMD. (As well as Ryzen instead of Intel for CPUs, where possible.) The only open-source nouveau drivers are absolutely terrible, I can attest to that fact myself. There's several benefits to not relying on NVIDIA's proprietary and non-in-built drivers for a decent experience. You'll know this already, depending on how deeply and regularly you use Linux.

I will anecdotally agree; I've been a Linux laptop user for... well, 2 decades maybe? and explicitly choose Dell Mobile Precision and/or IBM/Lenovo T-series laptops with ATI/AMD, dealing with NVIDIA graphics is just a pain in the ass once we passed the GeForce era (ish).

I'd rather just have/use Intel GPU over them as well, I am not a laptop gamer to need anything NVIDIA offers in exchange for the pain in maintenance using out of tree modules to me.

I will anecdotally disagree.

Depending on which distro you use NVIDIA grapics can be quite painless. Using Pop!_OS, I just had to download the correct iso from their downloads page.

I believe most other distros have NVIDIA's drivers in their non FL/OSS repos as well.

Optimus graphics will even work with the most current drivers.

I'll agree here as well. While I'd love to get more AMD centric options without Nvidia - they're not as bad these days as it was years ago. In fact I use an Intel NUC (Skull Canyon) as my daily desktop driver. The kicker is I wanted to do some OpenCV with Nvidia and run the NUC with an eGPU on Linux. I've been doing it for years and it works surprisingly well. It's gotten even better with 'egpu-switcher' [0].

[0] https://github.com/hertg/egpu-switcher

I’m using Pop!Os (preinstalled) with a sys76 laptop. Works great (can even game) battery life is terrible (though it looks fantastic and can drive a 32 inch high dpi external)

I can switch to built in Intel video for better battery but it requires a reboot. I see this as a stopgap. My home machine has an amd video.

It's definitely sub-optimal needing to reboot.

I only need the NVIDIA graphics every so often on my laptop though, so it's fine for me.

On desktop I've had no issues.

This is also the distro my employees are using.

I've used nvidia GPUs on Ubuntu with the proprietary drivers.

In my experience they're largely OK. There are some rough edges - you'll struggle to get Steam and CUDA working at the same time, for example - but no showstopping problems.

I certainly don't have a debilitating kernel panic every week :)

I'm in the Linux space. My GTX 1060 works just fine.

What's your experience been with amdgpu?

At my end, that's what I have to start testing on my 2019 MBP as I plan a transition to bare metal Linux fully on it, using the tools at https://github.com/Dunedan/mbp-2016-linux. (Will take several months.) I'll be sure to document it in that community and share tips when extensive testing is done.

It's only MBP NVIDIA GPU in Linux (older model) that I have extensive experience on so far, and it's been terrible with nouveau.

Nvidia gpus require proprietary drivers that are only provided for specific distros and are only supported for a small amount of time. And if you find any bug well tough luck, nobody can help you. For a work setup that you rely on someone else in the company for support they might be fine but I wouldn't recommend them for a personal setup.

All this is on top of the fact that they still don't support Wayland and you have to reboot to switch between the igpu and the nvidia gpu.

10 years of support on the latest driver branch (current branch goes back to the 600 series, and the 400 series was dropped in June) doesn’t exactly seem like a small amount of time.

Yes that's what they say officially. You'd be hard pressed to run any of those old cards without issues.

> that are only provided for specific distros

Last time I looked, it was perfectly possible to install them directly, without support by the distro. Yes, it's more work.

> Nvidia gpus require proprietary drivers

There's an open source driver, nouveau, but of course it's behind the newest hardware.

>Last time I looked, it was perfectly possible to install them directly, without support by the distro. Yes, it's more work.

Yes, you can install them and they will break with every single update and you need to re-install them. And you will encounter bugs that no-one has any idea why they are there and no-one will help you with.

>There's an open source driver, nouveau, but of course it's behind the newest hardware.

It's not just behind, it's actively sabotaged by nvidia by locking basic hardware functions behind closed firmware that it encrypted.

It's pretty easy to buy Linux laptops these days.

Yes but to GP’s stated requirements, the trackpad feels like trying to push a marble around in peanut butter.

> I honestly cannot find a laptop with the combination of 64 GB RAM, a non-NDIVIA GPU, and other premium hardware like its market-leading trackpad at this time

Only 14”, and perhaps less performant, but here is this one: https://puri.sm/products/librem-14/.

The linked laptop lacks a GPU.

It's trackpad probably isn't as good as that of the MBP.

This is true. But it has many other advantages related to users’ freedom and security, e.g., you can open it and upgrade, it has Coreboot, kill switches: https://puri.sm/posts/librem-14-shipping-in-december/.

Yes, I'm after 15"+ too.

They also have a 15” version, but it’s much less performant. They will probably present a new model soon with the same specs like the one above.

I really hope so. I'm even willing to give up the Apple trackpad if something else comes that lines everything else up. I tried so hard a couple of weeks ago to find something non-Apple that ticked all the boxes, and was shocked my existing MBP was the only one that ticked enough of them. I'm waiting and waiting for an explicitly Linux-supporting manufacturer to offer a truly high end and Linux-friendly laptop. It's a holy grail right now.

I'm stuck with a 15" 2018 macbook pro running macOS because of T2. I feel your pain.

Firstly, thanks so much for your hard work. All I want is to run Arch on an MBP 15,1. I've given your repos on Github a try--do you have a functioning bootloader config? T2 just freezes GRUB for me no matter what I try. Thanks again

The T2 Mac startup chime is located in /System/Library/PrivateFrameworks/BridgeAccessibilitySupport.framework/AXEFIAudio_VoiceOver_Boot.aiff . I think it will only be months until someone manages to change the 'bong' sound into a custom startup chime. This will be very interesting...

I hope you have reported the issue to Apple so they can fix it ASAP ?

They are well aware of the issue and have been for some time. There’s not all that much they can do to fix this, although they have certainly tried.

> There’s not all that much they can do to fix this, although they have certainly tried.

Forgive my ignorance, why is there not much they can do and what have they tried?

Apple tried to use a side channel in their security coprocessor to detect if the device had booted out of DFU (which is part of how the exploit worked). This didn't work because people found a vulnerability in that processor itself.

My understanding is that because this is a hardware-based issue, there’s no way to release a software patch to fix it.

>Hi guys, I am part of the team working on all things T2.

So there is a team working on this? What is the incentive model? Are you paid to do this work? What is the revenue model?

I woke up today learning my MacBook Pro is now substantially less secure but why? So I can run games on the touch bar? So I can use the T2 as a raspberry pi?

Your MacBook Pro didn't now become less secure. It always was. We should be thankful to these people for making the vulnerability clear to us.

There is a team taking advantage (jailbreaking on iOS) of the security flaw in all A-series chips up to A11 in the hardware-level bootloader. The T2 in your 2018 or newer Mac is a variant of the A10.

The bootROM flaw allows for an exploit that can only be executed with physical access, another Mac and DFU mode. It's not persistent.

The main use of this exploit was to install unsigned code on iOS devices (jailbreaking.) The team is doing it for free, however many contributors take advantage of Apple's bug bounty program for income, therefore making newer devices more secure.

I would say it is persistent enough to be malicious. The T2 does not reboot, with the exception occuring during a DFU restore, extremely drained battery, or firmware update. With that in mind, a party intending harm would have more than enough time.

Why do you believe it's moral for you to do work which is making people's data less secure, helping law authority crack iPhones, etc?

It could be argued that work like this actually helps make people's data more secure.

Granted, owners of the affected hardware might not like it, but this sheds light on issues that are actually present in the hardware. Who's to say that "law authority" or some criminal organization didn't do any work on this without intention to publish their results?

If people have sensitive data and were counting the T2 chip to keep it secure, now they know there are limitations to this security model. They can now weigh the pros and cons and, if applicable, set up an alternative that will be more secure. This could also push Apple to provide better security in upcoming products.

I'm glad they released their jailbreak, because otherwise, those exploits would be sold and traded on the black market or collected and used by malicious groups, and we would be none the wiser. We'd walk around believing our machines are secure, and act like it, while that clearly isn't the truth.

The same work allows users to have control over the hardware they own as well.

So only the NSA should be able to do this and then also keep it a secret?

Imagine if their "evil twins" working in the dark or for the NSA, KGB or Red Army, have cracked this but not tweeted about it. Now the Apple security is just as broken but you don't know about it. Is your data more or less secure?

Law enforcement has been going apeshit about legally forcing Apple to build in hardware backdoors to their products. If this jailbreak didn't exist, they'd be putting a gun to Apple's head and demanding decryption tools for all iPhones.

Furthermore, the entire point of a jailbreak is to regain root access to your own device - Apple provides no way for a user to do so, which I find at least somewhat irksome. The way it currently stands, all iOS devices ship with Apple having total control over the device, and a jailbreak lets you claw back control by force if you so choose.

The T2 isn’t used in the iPhone or iOS devices.

What makes you think state actors with inifinite budgets didn't do what this one guy is doing?

Everything he exposes will be fixed and improved. If anything he's helping make Apple devices more secure.

It's work which is enabling freedom, something that people are unfortunately giving up far too much of these days...

I think that over-simplifies the idea too much. "Freedom" on its own isn't a constant positive. We don't give people the "freedom" to murder each other or modify their cars in whatever ways they want. In fact, some people choose Apple because it doesn't provide them the freedom to do anything they want which includes breaking their devices in ways that they don't know. Having that freedom isn't necessarily a net positive for some people.

Go back and do your homework.

Showing security problems is the opposite of making Technology less secure. Maybe ask Apple why they think it's a good idea to have closed source special chip at all.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact