> Yes, I think we've all agreed we can do it ... it's now a question of
> whether we can stomach the ick factor of actually initiating a
> transaction in close ... I'm still feeling queasy.
NFS does transactions - including figuring out if the data will fit - on
file close. It does that for real d
> > look further into the options I have set in my kernel build, I may have
> > changed something else without remembering between booting with and
> > without the CSM enabled.
> >
>
> It could also be that the non-CSM BIOS somehow remaps the CMOS registers.
I don't believe there is anything whi
On Mon, 9 Jun 2014 13:08:00 +0200
Daniel Kiper wrote:
> Hi,
>
> As I can see efi_set_rtc_mmss() is never used to set RTC.
> Even on EFI platform mach_set_rtc_mmss() is called and does
> that thing. Why it is done in that way? It is a bug or it was
> done intentionally. Am I missing something?
E
> Whether Microsoft would actually follow through on blacklisting their
> own signatures is obviously an unknown - they've told us they would, but
> commercial concerns etc who knows. They *will* blacklist our signatures.
I think that becomes an irrelevant debate. It's going to end up being
argued
> Capabilities can be seen as related to this patch set, but it cannot
> be seen as a blocker. This logic is needed today, it's implemented,
> and it clearly marks where the known problems are. If an overhaul of
> capabilities happens, it can happen separately.
A working version is needed today -
> So as far as the narrow question of whether we should accept these
> patches, I think it's a good thing. Personally, I'm always going to
> be disabling UEFI secure boot (even if it doesn't brick my laptop),
> because for me, the security guarantees it provides isn't worth it.
> But there will be
On Fri, 14 Mar 2014 22:15:45 +
Matthew Garrett wrote:
> On Fri, 2014-03-14 at 22:08 +0000, One Thousand Gnomes wrote:
> > On Fri, 14 Mar 2014 21:56:33 +
> > Matthew Garrett wrote:
> > > Signed userspace is not a requirement, and therefore any solution that
On Fri, 14 Mar 2014 21:56:33 +
Matthew Garrett wrote:
> On Fri, 2014-03-14 at 21:48 +0000, One Thousand Gnomes wrote:
>
> > In your particularly implementation maybe you've got a weak setup where
> > you don't measure down to your initrd. That's a *flaw*
On Fri, 14 Mar 2014 19:24:55 +
Matthew Garrett wrote:
> On Fri, 2014-03-14 at 14:11 -0400, Matthew Garrett wrote:
>
> > The fact that you keep saying measured really does make me suspect that
> > you misunderstand the problem. There's no measurement involved, there's
> > simply an assertion
> I have a set of patches that appear acceptable to the security
> maintainer. I've rewritten them multiple times in response to various
> levels of bikeshedding. They solve a real problem and are being shipped
> by multiple distributions.
And ? I've seen some of the other "extra" stuff distributi
> But you keep talking about MSRs despite there being a patch that limits
> access to MSRs. If you have specific examples of privilege escalations
> that are possible even with these patches then please, mention them.
I mentioned MSRs once, and then you kept going on about it.
Your patches are a
> The command line problem here is a total red herring. If you've got a
> measured kernel, you have a measured command line. (If not, you don't
That would be the sensible approach, but it has some quite drastic
ramifications.
> have a measured kernel.) Dealing with the command line has nothing to
> Have you actually looked at these patches? I've looked at every case of
> RAWIO in the kernel. For cases that are hardware specific and tied to
> fairly old hardware, I've ignored them. For cases which provide an
Yes I have - and it's not exactly localised: it modifies stuff all over
the tree wh
On Thu, 13 Mar 2014 21:30:48 +
Matthew Garrett wrote:
> On Thu, 2014-03-13 at 21:24 +0000, One Thousand Gnomes wrote:
>
> > If I have CAP_SYS_RAWIO I can make arbitary ring 0 calls from userspace,
> > trivially and in a fashion well known and documented.
>
> How?
> On the other hand, disabling CAP_SYS_RAWIO *definitely* breaks expected
> functionality - firmware loading and the fibmap ioctl are probably the
> most obvious. And changing the use of CAP_SYS_RAWIO potentially breaks
> userspace expectations, so we're kind of stuck there.
Actually I know how to
On Thu, 13 Mar 2014 15:59:24 +
Matthew Garrett wrote:
> On Thu, 2014-03-13 at 20:33 +1100, James Morris wrote:
>
> > I'll take it, but there's unanswered review feedback (your response to the
> > first question), and Alan raised some doubts about the patches which I'm
> > not sure have bee
On Thu, 13 Mar 2014 20:33:06 +1100 (EST)
James Morris wrote:
> On Wed, 12 Mar 2014, Kees Cook wrote:
>
> > On Wed, Mar 12, 2014 at 10:01 PM, Matthew Garrett
> > wrote:
> > > On Fri, 2014-02-28 at 14:03 +1100, James Morris wrote:
> > >
> > >> Ok, which tree should take this? I'm happy to, altho
On Wed, 26 Feb 2014 15:11:13 -0500
Matthew Garrett wrote:
> UEFI Secure Boot provides a mechanism for ensuring that the firmware will
> only load signed bootloaders and kernels. Certain use cases may also
> require that the kernel prevent userspace from inserting untrusted kernel
> code at runtim
> > kernel was trusted - untrusted userspace could have set it on an untrusted
> > kernel, but by the same metric an untrusted kernel could just set it itself.
> >
> > If people object to this name then I swear to god that I will open a poll
> > on Phoronix to decide the next attempt and you will l
On Thu, 19 Dec 2013 21:32:19 +0800
joeyli wrote:
> 於 四，2013-12-19 於 10:49 +，Matt Fleming 提到：
> > On Thu, 19 Dec, at 06:20:16PM, Lee, Chun-Yi wrote:
> > > From: Jan Beulich
> > >
> > > Other than ix86, x86-64 on EFI so far didn't set the
> > > {g,s}et_wallclock accessors to the EFI routines,
20 matches
Mail list logo
