Date: Tue, 25 Nov 2014 18:35:40 +0000 From: Mark R V Murray <mark@grondar.org> To: Warner Losh <imp@bsdimp.com> Cc: =?windows-1252?Q?Dag-Erling_Sm=F8rgrav?= <des@des.no>, Ian Lepore <ian@FreeBSD.org>, arch@freebsd.org Subject: Re: svn commit: r274739 - head/sys/mips/conf Message-ID: <EBD544D1-BABA-4C9A-BE38-8543D1F9AF84@grondar.org> In-Reply-To: <18F34536-CA8B-4365-BDD9-C2D23E6067AA@bsdimp.com> References: <201411200552.sAK5qnXP063073@svn.freebsd.org> <20141120084832.GE24601@funkthat.com> <AE8F2D30-7F91-4C90-B79A-D99857D8AED8@grondar.org> <20141121092245.GI99957@funkthat.com> <1416582989.1147.250.camel@revolution.hippie.lan> <026FEB8A-CA8C-472F-A8E4-DA3D0AC44B34@grondar.org> <1416596266.1147.290.camel@revolution.hippie.lan> <F017033A-B761-4435-A7F8-264D2F4662A0@grondar.org> <1416598889.1147.297.camel@revolution.hippie.lan> <86egsvueqk.fsf@nine.des.no> <1416691274.1147.339.camel@revolution.hippie.lan> <398A380D-49AF-480C-8842-8835F81EF641@grondar.org> <1416806894.1147.362.camel@revolution.hippie.lan> <18B8A926-59C0-49B4-ADA3-A11688609852@grondar.org> <1416841268.1147.386.camel@revolution.hippie.lan> <CC6B67E1-55A2-4952-AB43-5F6C787F629B@grondar.org> <86wq6k9okk.fsf@nine.des.no> <F60907B5-433F-4800-82B4-5D882AF0B3BB@grondar.org> <8661e3wtk6.fsf@nine.des.no> <D928DF64-2C5D-4D31-A7BE-62482A53A7EA@grondar.org> <86oarvvaet.fsf@nine.des.no> <86egsrxypx.fsf@nine.des.no> <1416925387 .1147.437.camel@revolution.hippie.lan> <18F34536-CA8B-4365-BDD9-C2D23E6067AA@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> On 25 Nov 2014, at 17:11, Warner Losh <imp@bsdimp.com> wrote: >> The repeatability of the boot sequence of hardware like this is = nearly >> perfect at the resolution we're measuring. While that may be bad for >> gathering entropy, it's a wonderful thing when you're debugging, = because >> problems that would be almost impossible to nail down on modern = complex >> hardware are 100% reproducible by just hitting the reset button. = That >> reproducibility extends all the way into multiuser mode unless there = is >> a network connection where packet arrival times start adding >> interrupt-based entropy. >=20 > Yea, every boot it is the same registers that are being read, in the > same sequence, resulting in very similar cache patterns and = performance > profiles. I=92d be surprised if anything apart from the ethernet = chip=92s > state was different between boots. And even the ethernet=92s stuff has > a low variance until interrupts are turned on=85 Things are far from perfect, but not entirely unexpected. I=92m well aware that PCs are low-entropy beasties at the best of times as we have to struggle like crazy to get what we have. The bottom-end boxes with no high-resolution timers are clearly going to be much worse. For real security, I guess the answer is cached entropy in files that are preserved over a boot and deleted straight after boot. Ian=92s case, where security is not an issue, should be solvable by getting the random(4) driver to be content with whatever it gets from the boot entropy, crappy as it is, in a way that doesn=92t offer an attack vector. This should be doable. M --=20 Mark R V Murray
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?EBD544D1-BABA-4C9A-BE38-8543D1F9AF84>