<nh2>
elvishjerricco: why are you doing stuff with TPM on AMDs? It sounds like we have have overlapping interests
<elvishjerricco>
nh2: Mostly I'm interested in testing out password-less disk encryption
<nh2>
elvishjerricco: perfect, me too
<elvishjerricco>
nh2: Do you have a dedicated tpm chip, or are you using a firmware one in the CPU?
<nh2>
elvishjerricco I got an EPYC on Hetzner but haven't managed to test it out yet. Have you already figured out which userspace tools work with the on-die TPM?
<clever>
nh2: disasm from devops is has a presentation
<elvishjerricco>
I'm having problems with the Threadripper's fTPM
<nh2>
elvishjerricco: what's the `f` for?
<elvishjerricco>
"firmware." Just a shorthand for the firmware implementations of TPM
<elvishjerricco>
I get this:
<elvishjerricco>
tpm_crb MSFT0101:00: can't request region for resource [mem 0x79406000-0x79406fff]
<elvishjerricco>
tpm_crb: probe of MSFT0101:00 failed with error -16
<elvishjerricco>
I'm thinking it's the kernel, but I have no idea.
<nh2>
elvishjerricco: regarding your firmware update, the TPM runs in AMD's equivalent of the Intel Management Engine (ME), so whatever updates AMDs ME equivalent should also update the TPM I think
<elvishjerricco>
nh2: What are the chances that would be the microcode? That's what I've already updated :P
<clever>
elvishjerricco: TPM firmware in microcode is a recipe for security nightmares :P
<clever>
the bootloader can give the linux kernel a copy of the microcode to run under
<clever>
and if you can load custom TPM firmware that easily, then its pointless to have the TPM be a gatekeeper for secrets
<nh2>
elvishjerricco: I'd expect the CPU microcode and the ME are separate. Like if you want to fix the numerous ME vulnerabilities Intel has, you always have to do a special update for that. Also remember the thing runs even if the computer is powered off, so likely not microcode
<clever>
nh2: yeah, that sounds right
<elvishjerricco>
Ah, yea. Especially since TPM is extended based on the boot loader, IIRC, I would guess the firmware can't come after the boot loader.
<clever>
it would have to be done with a bios update, and then a TOTAL reset of the machine, including the parts that dont normally reset during reboot
<elvishjerricco>
Like, I think the whole idea of TPM is that the hash of the boot loader is extended into TPM before the boot loader is run.
<clever>
depending on how crappy it is, you may even need to pull the plug :P
<clever>
elvishjerricco: thats just one feature it does, measured boot
<elvishjerricco>
Right
<elvishjerricco>
But yea, my error message makes it look like there's just some other part of the kernel eating up the same address space as the TPM driver is attempting to use. Sounds like a bug to me, but I'm not sure
<nh2>
elvishjerricco: not sure your argument makes sense though, the TPM measuring stuff is aleays about stuff happening *before* the next step; after you've completed your whole boot, you can modify anything at will (like, change your full disk encryption password), so changing microcode after boot wouldn't be illegal in that logic in any sense
<nh2>
(I'm referring to the "the firmware can't come after the boot loader" justification)
<elvishjerricco>
Hm.
<nh2>
but in any case, I think we're all quite sure that the microcode won't update your "ME-TPM"
<elvishjerricco>
You'd have to verify the initrd with the original TPM before you could load it if that were true. Otherwise the microcode on the boot partition could be replaced with something malicious
<elvishjerricco>
But yea, that point still stands; likely not the microcode
<clever>
i think ARM calls it trustzone, and its more of a hypervisor then a second core that runs always
<elvishjerricco>
clever: That god mode was a really specific CPU though wasn't it? Or am I thinking of a different story?
<clever>
elvishjerricco: other CPU's might have similiar undiscovered god modes
<elvishjerricco>
Fair enough
<nh2>
clever: interesting! But is it related to the TPM stuff?
<clever>
2018-09-03 21:56:32 < graphitemaster> microcode is signed
<clever>
2018-09-03 21:56:37 < graphitemaster> with a private key
<nh2>
or do you mean that the sentence "It has unrestricted access to the x86" might also mean "it can do stuff to the TPM"
<nh2>
ah
<clever>
nh2: measured boot assumes that the hash of a kernel that has signed module loading enabled, means untrusted code can never run in ring0 and talk to the TPM
<clever>
so your keys are safe
<clever>
but with the above god mode, i get free ring0, and then i can talk to the TPM
<clever>
and because the TPM thinks i'm a trusted kernel, it allows it
<nh2>
clever: I still don't understand how that's relevant -- in general, why is it imortant to prevent untrusted code from talking to the TPM for the purpose of passphrase-free full-disk-encryption boot?
<nh2>
in general, which untrusted code are we talking about? At the time any form of untrusted code could run, you'd already have completed your boot and disk unlock
<clever>
nh2: i could just plug my own USB in, ask the TPM for the password, and then decrypt the clone of the disk
<clever>
2018-09-03 21:58:36 < graphitemaster> if you already have that then there's much easier ways to backdoor ;-)
<clever>
2018-09-03 21:58:43 -!- Siddharth_Gautam is now known as S_Gautam
<clever>
2018-09-03 21:59:19 < graphitemaster> not really, no one really exactly understands the microcode
<clever>
2018-09-03 21:59:38 < graphitemaster> I mean not even the people at Intel writing microcode fully understand the microcode
<clever>
2018-09-03 21:59:56 < graphitemaster> so how should people with no documentation with preassembled ihex figure it out
<clever>
2018-09-03 22:00:19 < graphitemaster> then be smart enough to figure out how to put a backdoor into it
<clever>
2018-09-03 22:00:46 < graphitemaster> especially when cpus are such a moving target and microcode is keyed to literal microarch
<clever>
missed the question at the start, 2018-09-03 21:58:28 < clever> graphitemaster: prior to signing, was the microcode flexible enough to actually allow such a thing?
<clever>
nh2: so its not really feasible to attack anything via microcode, lol
<clever>
2018-09-03 22:01:27 < graphitemaster> but it would be easier for the government to just ask intel to put backdoor into CPUs
<clever>
2018-09-03 22:01:33 < graphitemaster> which they have done already
<elvishjerricco>
Hm. Well you'd hope that once any untrusted code is running, it has invalidly extended the TPM.
<elvishjerricco>
Right?
<clever>
elvishjerricco: measured boot requires the hashes being fed into the TPM to match an existing recording, to unlock the key material
<clever>
and the protocol requires that you inform the TPM about the hash of something, before you execute it
<clever>
so if any untrusted code is ran, the series of hashes wont match, and the TPM wont unlock
<elvishjerricco>
clever: Yea. So what's the attack there involving a USB stick?
<clever>
i think i got things mixed up a bit, talking in 2 channels at once
<elvishjerricco>
Also, you have to do most of it manually, right? Like TPM will start with the boot loader, but the rest is on you?
<clever>
the motherboard firmware is responsible for informing the TPM about the bootloader hash, then running the bootloader
<clever>
the bootloader must then inform the TPM about your kernel hash, before running that
<elvishjerricco>
Cool, so that sounds fine then
<clever>
and the kernel must be configured to only load modules that are signed by keys the firmware trusts
<clever>
but a ring0 god mode like above, would then allow you to query the TPM and read the keys
<elvishjerricco>
Ah, got it
<nh2>
clever: I think in that setup, the motherboard firmware is also responsible for NOT booting your USB
<elvishjerricco>
So it becomes essential to disable reading the keys after initrd. Otherwise it's just too big an attack surface
<clever>
nh2: i think that situation, when it boots from the usb, it reports the usb bootloader hash
<clever>
and then the TPM detects the hash is wrong, and just refuses to unlock
<elvishjerricco>
And hopefully some information about the medium booted, right?
<disasm>
are you guys talking about osx or something else using TPM?
<elvishjerricco>
OSX hasn't used TPM since 2006, apparently
<clever>
TPM on nixos i believe
<disasm>
ah
<elvishjerricco>
clever: But yea, so it'd be good to ensure that only trusted modules are in initrd, then you can just extend again with something else to keep it consistent, but disallow access to the stage 1 keys for untrusted code in stage 1
<elvishjerricco>
for untrusted code in stage 2*
<clever>
elvishjerricco: not sure, but you may be able to tell the TPM to re-lock the keys until a full power cycle
<clever>
so once you unlock the disk, you could lock the TPM
<elvishjerricco>
clever: I saw one article where they did that by just writing invalid data to some NVRAM
<elvishjerricco>
It required a certain TPM setting to be set though
<elvishjerricco>
One that locks the TPM on such an invalid write
<nh2>
clever: can't you relock again trivially by just exending the TPM a bit more with some arbitrary data?
<clever>
also of note, secure-boot only works in one direction, and people often misunderstand how it works
<elvishjerricco>
nh2: I think that would be effectively the same thing, except that it'd still allow you to unlock another set of keys
<clever>
secure-boot is entirely about only executing signed binaries (bootloader, kernel)
MarkRBM has joined #nixos-chat
<clever>
and while uefi has a method (returning boolean), that says if you are booting via secure-boot or not
<elvishjerricco>
clever: But they can only be signed by, like, microsoft or something on most hardware, right?
<clever>
there is absolutely no verification on that method
<clever>
elvishjerricco: you can load custom public keys into the firmware, using the bios config
<clever>
but part of the misunderstanding, is that while the linux kernel can ask the firmware, "did i boot via secure-boot?"
<clever>
it is trivial to have a fake uefi shim, that lies
<clever>
once secure-boot has been defeated, you can have a bootloader that mutates the efi function table, and claims secure-boot still works
<nh2>
I have to sleep but elvishjerricco ping me if you can get rid of the kernel error message, and I'll ping you in case it works out of the box on my EPYC
<elvishjerricco>
nh2: That'd be great, thanks. And will do
<elvishjerricco>
Checking the bios for info on the PSP on my system... Is the bios where I could find such info?
<gchristensen>
no need to use zfs on the controller
* clever
heads to bed
__monty__ has quit [Read error: Connection reset by peer]
__monty__ has joined #nixos-chat
tertl3 has quit [Quit: Connection closed for inactivity]
drakonis_ has joined #nixos-chat
__monty__ has quit [Quit: leaving]
kisik21 has quit [Ping timeout: 272 seconds]
<sphalerite>
gchristensen: this looks to me like it's aiming to destroy your data, which I think is pretty trivial for a HDD controller. It could probably even destroy the platters physically x)
<sphalerite>
gchristensen: the hack in what I linked fiddles with /etc/passwd :)
<gchristensen>
ahh
<andi->
Nixos on your disks!
<andi->
Reminds me of that project that bundles disks with an 64bit arm, gigabit ethernet and a bit of RAM to run ceph on them..
<gchristensen>
wat
<andi->
Yes, WD or Hitachi or so do that..
<andi->
You'll need a few 48port switches per rack unit.. m(
<gchristensen>
I feel like there is a cost / benefit sweet spot between "every disk is a computer" and "one big computer which exposes its disks and a massive blast radius if it fails"
<simpson>
The spectrum's got more width to it than that, because there's also "nobody has local disks, only SaaS"
<maurer>
I mean, there's also the other version, which is a GFS-like environment, where every machine has local disks, but a global namespace
<maurer>
and they just keep locally whatever they think they're using at the moment, plus some other stuff for redundancy fo rother machines
<simpson>
maurer: Right, that's like the internals of any sufficiently-big cloud provider. But we could go a littler further and have no disk API, just a way to alloc TiB-sized "in-memory" extents. And then the SaaS is the *only* persistent storage.
<andi->
There is probably a use-case for all of these.
<maurer>
simpson: It is useful at the programming level to be aware of what is close and what is potentially far
<maurer>
This is what killed DCOM and CORBA
<maurer>
(they tried to make the programmer oblivious to this)
<simpson>
maurer: Sure. This is why members of the E family distinguish between "near" and "far" references to objects; it's not possible to call a far ref, only send messages to it.
<maurer>
simpson: I also think the cloud service API is a little different - there, the "canonical" copy lives on some network store, there's a checked out copy on exactly one VM bearing machine, and that's it
<maurer>
simpson: The GFS model is a bit more uniform, with every machine holding data for others, and finer grained write access
<simpson>
maurer: Well, that's the *illusion* that's presented, but there's no reason why that must be the case. For example, at Matador Cloud, we use Tahoe-LAFS as SaaS internally; data lives not on one machine, but on many machines, erasure-encoded so that only a few machines are needed to reconstruct the data.
<maurer>
Also, if you want TiB "in-memory" extents, you might want to watch Intel's optane stuff for when the price goes down
<gchristensen>
I feel like gTLDs has really spoiled something about the internet
<gchristensen>
Google owns .docs, Amazon owns .book, but you can't actually get domains with either of them
<gchristensen>
and the only valid use case for http://under.construction/ is a geocities style page full of under construction gifs
<maurer>
Yeah, I think it's fine that e.g. .google is only for google, but if you buy out a general word
<maurer>
I think you should have to register subdomains
<maurer>
e.g. "rust.book" or "dragon.book" seem like good uses of the tld
__monty__ has joined #nixos-chat
<joepie91>
gchristensen: it's just a continuation of spoilage that has been ongoing for years now :/
<joepie91>
towards a corporately-oriented internet
<joepie91>
broadcast services, consumer-based rather than creator-based, etc.
{`-`} has joined #nixos-chat
<andi->
NAT killed the internet ;)
<gchristensen>
lol
<andi->
And asymmetric consumer access..
<maurer>
andi-: The problem is, even as IPv6 rolls out, which means you don't _need_ NAT, people still want it
<andi->
Imagine what would have happend if people would have been able to serve stuff from at home for the last 20y without ant expertise knowledge..
<maurer>
because everyone's security is partially based on the fact that their home machines _aren't_ addressible from the open internet
<maurer>
well, not everyone's, but all the normal people
<andi->
maurer: I know I know... I quit working at an ISP because I couldn't take it anymore.. People are "dumb" :(
<__monty__>
maurer: Couldn't that just be replaced with a firewall that refuses incoming connections on the routers?
<maurer>
__monty__: No, because at the moment, autonegotiation for various programs (games, office collab software) is done by allowing "related" connections back through
<__monty__>
How is related defined?
<maurer>
Hrm, you might be able to do this without NAT, though you would still need a stateful firewall
<andi->
Device security nonsense..
<joepie91>
andi-: related annoyance: crippled upload speed
<__monty__>
You'd think having to pump tons of data into the cloud would get people upset about the upload situation.
<maurer>
andi-: In any case, true P2P internet won't happen until a you can put a fresh install of windows, mac, or ubuntu not behind a nat on a network for a day without patching
<maurer>
and come back and none of them are owned
<maurer>
because until then, everyone will tell you to keep them behind a nat/restrictive firewall
<maurer>
either of which will stop the rise of self-hosted sites etc
<joepie91>
__monty__: nah, because when your target is $randomPersistentExternalStorageService, the slowness can nicely be amortized behind the scenes
<joepie91>
(and every ~cloud storage~ provider targeting end users does)
<__monty__>
But the data loss potential...
<joepie91>
it just has to go right most of the time :) people have become accustomed to buggy software and inexplicable failures, however sad that is
<joepie91>
so long as they don't happen too often, for extremely variable and subjective values of 'often', nobody complains
<maurer>
__monty__: Think of all the people you know who use computers. Now think of how many have a backup system. Now think of how many of _those_ have ever tested their backup system.
<maurer>
That last class of people are the only ones who will ever know.
<maurer>
And even for them, the error has to hit them unlucky
<__monty__>
True.
rain1 has joined #nixos-chat
drakonis_ has quit [Remote host closed the connection]
<samueldr>
well, github ruined their interface
<samueldr>
on some projects I see a scrollbar in the file listing at the root of the repo
<samueldr>
incognito does for nixpkgs
<__monty__>
Hmm, I'm not sure I hate it.
<__monty__>
Tbh I'm usually looking for the README, not the things in the repo.
<__monty__>
So as long as the "show all files" is remembered in a cookie or something I don't think I'll mind.
<samueldr>
it's for that page view only (AFAICT)
<samueldr>
an issue I can see is how scrollbars are being hidden by default in more and more systems
<__monty__>
Hmm, true. The show all files link should be a decent hint though.
<samueldr>
we'll see weird bugs when scrollbars are shown (see gitlab and their label pickers which have two scrollbars into a popover)
<samueldr>
though I hate it, I can understand why they did it, but do not agree :/
<samueldr>
AFAICT the rule seems to be that if you can edit the repo you won't see that new page :/
<__monty__>
Ah, that's why I didn't see it on mine.
<gchristensen>
wat
<gchristensen>
eeewwwww
<gchristensen>
samueldr: new backgrounds look great btw :