* Dave Hansen:
> On 05/07/2015 12:11 PM, One Thousand Gnomes wrote:
>>> diff -puN
>>> include/uapi/asm-generic/mman-common.h~pkeys-11-user-abi-bits
>>> include/uapi/asm-generic/mman-common.h
>>> --- a/include/uapi/asm-generic/mman-common.h~pkeys-11-user-abi-bits
>>> 2015-05-07 10:31:43.367276719
* Dave Hansen:
> On 05/07/2015 12:11 PM, One Thousand Gnomes wrote:
>>> diff -puN
>>> include/uapi/asm-generic/mman-common.h~pkeys-11-user-abi-bits
>>> include/uapi/asm-generic/mman-common.h
>>> --- a/include/uapi/asm-generic/mman-common.h~pkeys-11-user-abi-bits
>>> 2015-05-07 10:31:43.367276719
* Dave Hansen:
> On 09/04/2015 01:13 PM, Florian Weimer wrote:
> ...
>>>>> >>> #define PROT_WRITE 0x2 /* page can be written */
>>>>> >>> #define PROT_EXEC0x4 /* page can be executed */
>>>
ed something we can select(2)/poll(2) on.
Thanks for the clarification. I agree that this is a separate and quite
sensible use case.
--
Florian Weimer / Red Hat Product Security
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message
that this is a separate and quite
sensible use case.
--
Florian Weimer / Red Hat Product Security
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ
a waitpid(2) (or similar) explicitly specifying the
PID. Is this not the case?
--
Florian Weimer / Red Hat Product Security
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://v
the
PID. Is this not the case?
--
Florian Weimer / Red Hat Product Security
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ
* Andy Lutomirski:
> On Nov 30, 2014 1:47 AM, "Florian Weimer" wrote:
>>
>> * Andy Lutomirski:
>>
>> > The initial implementation is straightforward: highpid is simply a
>> > 64-bit counter. If a high-end system can fork every 3 ns (which
>&g
* David Herrmann:
> On Sun, Nov 30, 2014 at 10:02 AM, Florian Weimer wrote:
>> * Greg Kroah-Hartman:
>>
>>> +7.4 Receiving messages
>> What happens if this is not possible because the file descriptor limit
>> of the processes would be exceeded? EMFILE, and
* David Herrmann:
> poll(2) and friends cannot return data for changed descriptors. I
> think a single trap for each KDBUS_CMD_MSG_RECV is acceptable. If this
> turns out to be a bottleneck, we can provide bulk-operations in the
> future. Anyway, I don't see how a _shared_ pool would change any
* Andy Lutomirski:
> At the risk of opening a can of worms, wouldn't this be much more
> useful if you could share a pool between multiple connections?
They would also be useful to reduce context switches when receiving
data from all kinds of descriptors. At present, when polling, you
receive
* Andy Lutomirski:
> The initial implementation is straightforward: highpid is simply a
> 64-bit counter. If a high-end system can fork every 3 ns (which
> would be amazing, given that just allocating a pid requires at
> atomic operation), it would take well over 1000 years for highpid to
> wrap.
* Greg Kroah-Hartman:
> +7.4 Receiving messages
> +Also, if the connection allowed for file descriptor to be passed
> +(KDBUS_HELLO_ACCEPT_FD), and if the message contained any, they will be
> +installed into the receiving process after the KDBUS_CMD_MSG_RECV ioctl
> +returns. The receiving task
* Greg Kroah-Hartman:
> +The focus of this document is an overview of the low-level, native kernel
> D-Bus
> +transport called kdbus. Kdbus exposes its functionality via files in a
> +filesystem called 'kdbusfs'. All communication between processes takes place
> +via ioctls on files exposed
* Greg Kroah-Hartman:
+The focus of this document is an overview of the low-level, native kernel
D-Bus
+transport called kdbus. Kdbus exposes its functionality via files in a
+filesystem called 'kdbusfs'. All communication between processes takes place
+via ioctls on files exposed through
* Greg Kroah-Hartman:
+7.4 Receiving messages
+Also, if the connection allowed for file descriptor to be passed
+(KDBUS_HELLO_ACCEPT_FD), and if the message contained any, they will be
+installed into the receiving process after the KDBUS_CMD_MSG_RECV ioctl
+returns. The receiving task is
* Andy Lutomirski:
The initial implementation is straightforward: highpid is simply a
64-bit counter. If a high-end system can fork every 3 ns (which
would be amazing, given that just allocating a pid requires at
atomic operation), it would take well over 1000 years for highpid to
wrap.
I'm
* Andy Lutomirski:
At the risk of opening a can of worms, wouldn't this be much more
useful if you could share a pool between multiple connections?
They would also be useful to reduce context switches when receiving
data from all kinds of descriptors. At present, when polling, you
receive
* David Herrmann:
poll(2) and friends cannot return data for changed descriptors. I
think a single trap for each KDBUS_CMD_MSG_RECV is acceptable. If this
turns out to be a bottleneck, we can provide bulk-operations in the
future. Anyway, I don't see how a _shared_ pool would change any of
* David Herrmann:
On Sun, Nov 30, 2014 at 10:02 AM, Florian Weimer f...@deneb.enyo.de wrote:
* Greg Kroah-Hartman:
+7.4 Receiving messages
What happens if this is not possible because the file descriptor limit
of the processes would be exceeded? EMFILE, and the message
* Andy Lutomirski:
On Nov 30, 2014 1:47 AM, Florian Weimer f...@deneb.enyo.de wrote:
* Andy Lutomirski:
The initial implementation is straightforward: highpid is simply a
64-bit counter. If a high-end system can fork every 3 ns (which
would be amazing, given that just allocating a pid
or something like that which means
"block/return EAGAIN until the kernel pool is initialized"? Thanks.
(See the previous discussion about pool initialization.)
--
Florian Weimer / Red Hat Product Security
--
To unsubscribe from this list: send the line "unsubscribe linux-kern
or something like that which means
block/return EAGAIN until the kernel pool is initialized? Thanks.
(See the previous discussion about pool initialization.)
--
Florian Weimer / Red Hat Product Security
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body
?
--
Florian Weimer / Red Hat Product Security Team
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
not imply that.
or mlock() to make the kernel lock them in memory.
See above for why that does not work.
I think you should eliminate the holes on sealing and report ENOMEM
there if necessary.
--
Florian Weimer / Red Hat Product Security Team
--
To unsubscribe from this list: send the line
ot available to them.
A couple of weeks ago, sealing was to be applied to anonymous shared
memory. Has this changed? Why should *reading* it trigger OOM?
--
Florian Weimer / Red Hat Product Security Team
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
t
se to plug
the O_RDONLY hole while leaving the O_PATH hole open.
--
Florian Weimer / Red Hat Product Security Team
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majord
the O_RDONLY hole while leaving the O_PATH hole open.
--
Florian Weimer / Red Hat Product Security Team
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please
are not available to them.
A couple of weeks ago, sealing was to be applied to anonymous shared
memory. Has this changed? Why should *reading* it trigger OOM?
--
Florian Weimer / Red Hat Product Security Team
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message
not imply that.
or mlock() to make the kernel lock them in memory.
See above for why that does not work.
I think you should eliminate the holes on sealing and report ENOMEM
there if necessary.
--
Florian Weimer / Red Hat Product Security Team
--
To unsubscribe from this list: send the line
?
--
Florian Weimer / Red Hat Product Security Team
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
On 04/28/2014 11:41 PM, Theodore Ts'o wrote:
On Mon, Apr 28, 2014 at 09:52:11PM +0200, Florian Weimer wrote:
Before this change, you had to check kernel log messages to see if the
non-blocking pool had been properly initialized. With this change, you
can consult the file /proc/sys/kernel
On 04/28/2014 11:41 PM, Theodore Ts'o wrote:
On Mon, Apr 28, 2014 at 09:52:11PM +0200, Florian Weimer wrote:
Before this change, you had to check kernel log messages to see if the
non-blocking pool had been properly initialized. With this change, you
can consult the file /proc/sys/kernel
Before this change, you had to check kernel log messages to see if the
non-blocking pool had been properly initialized. With this change, you
can consult the file /proc/sys/kernel/random/intialized instead.
Signed-off-by: Florian Weimer
---
drivers/char/random.c | 19 +++
1
Before this change, you had to check kernel log messages to see if the
non-blocking pool had been properly initialized. With this change, you
can consult the file /proc/sys/kernel/random/intialized instead.
Signed-off-by: Florian Weimer fwei...@redhat.com
---
drivers/char/random.c | 19
On 04/22/2014 01:55 PM, David Herrmann wrote:
Hi
On Tue, Apr 22, 2014 at 11:10 AM, Florian Weimer wrote:
Ah. What do you recommend for recipient to recognize such descriptors?
Would they just try to seal them and reject them if this fails?
This highly depends on your use-case. Please see
o clean up this mess, but it's not clear to me
where to start.
Please show me one user of that and declare it brain dead.
Safely and demonstratively relinquishing elevated privileges.
POSIX or not it just does not have any real programming mining
at all.
What do you mean with "mining"
On 04/09/2014 11:31 PM, David Herrmann wrote:
On Tue, Apr 8, 2014 at 3:00 PM, Florian Weimer wrote:
How do you keep these promises on network and FUSE file systems?
I don't. This is shmem only.
Ah. What do you recommend for recipient to recognize such descriptors?
Would they just try
On 04/09/2014 11:31 PM, David Herrmann wrote:
On Tue, Apr 8, 2014 at 3:00 PM, Florian Weimer fwei...@redhat.com wrote:
How do you keep these promises on network and FUSE file systems?
I don't. This is shmem only.
Ah. What do you recommend for recipient to recognize such descriptors
not clear to me
where to start.
Please show me one user of that and declare it brain dead.
Safely and demonstratively relinquishing elevated privileges.
POSIX or not it just does not have any real programming mining
at all.
What do you mean with mining in this context?
--
Florian Weimer
On 04/22/2014 01:55 PM, David Herrmann wrote:
Hi
On Tue, Apr 22, 2014 at 11:10 AM, Florian Weimer fwei...@redhat.com wrote:
Ah. What do you recommend for recipient to recognize such descriptors?
Would they just try to seal them and reject them if this fails?
This highly depends on your use
would be interesting for many things
(not just libffi bypassing SELinux-enforced NX restrictions :-).
--
Florian Weimer / Red Hat Product Security Team
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More
would be interesting for many things
(not just libffi bypassing SELinux-enforced NX restrictions :-).
--
Florian Weimer / Red Hat Product Security Team
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info
it results in something like
five RCU callbacks per impersonation round-trip.
Do you mean setfsuid instead of setresuid?
--
Florian Weimer / Red Hat Product Security Team
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kerne
the kernel perspective, this is not really a problem
because the credentials are always per-task. It's just that a
conforming user space needs the process-wide credentials.
--
Florian Weimer / Red Hat Product Security Team
--
To unsubscribe from this list: send the line "unsubscribe
iginal process state in case of
partial failure. We really need kernel support to perform the
process-wide switch in an all-or-nothing manner.
--
Florian Weimer / Red Hat Product Security Team
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a messag
of
partial failure. We really need kernel support to perform the
process-wide switch in an all-or-nothing manner.
--
Florian Weimer / Red Hat Product Security Team
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More
the kernel perspective, this is not really a problem
because the credentials are always per-task. It's just that a
conforming user space needs the process-wide credentials.
--
Florian Weimer / Red Hat Product Security Team
--
To unsubscribe from this list: send the line unsubscribe linux
it results in something like
five RCU callbacks per impersonation round-trip.
Do you mean setfsuid instead of setresuid?
--
Florian Weimer / Red Hat Product Security Team
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More
* One Thousand Gnomes:
>> For the Chrome OS use-case, it might be better described as "untrusted
>> userspace", but that seems unfriendly. :) The "trusted kernel" name
>> seems fine to me.
>
> Trusted is rather misleading. It's not trusted, it's *measured*.
I don't think anyone is doing any
* Theodore Ts'o:
> Right now, even though Lenovo laptops are shipping with Windows
> 8. UEFI secure boot is not made mandatory (although it is on enough to
> brick the laptop when it runs into bugs wwith the UEFI BIOS code,
> sigh). But sooner or later, UEFI secure boot will be on by default,
>
* Theodore Ts'o:
Right now, even though Lenovo laptops are shipping with Windows
8. UEFI secure boot is not made mandatory (although it is on enough to
brick the laptop when it runs into bugs wwith the UEFI BIOS code,
sigh). But sooner or later, UEFI secure boot will be on by default,
and
* One Thousand Gnomes:
For the Chrome OS use-case, it might be better described as untrusted
userspace, but that seems unfriendly. :) The trusted kernel name
seems fine to me.
Trusted is rather misleading. It's not trusted, it's *measured*.
I don't think anyone is doing any measurement. In
ted already open descriptors and
might not always be possible (the file system might be mounted
read-only, but still be modifiable beneath).
--
Florian Weimer / Red Hat Product Security Team
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
duplicates pages in the page
cache, so this does not seem to be possible, but DAX support might
change this.
--
Florian Weimer / Red Hat Product Security Team
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More
duplicates pages in the page
cache, so this does not seem to be possible, but DAX support might
change this.
--
Florian Weimer / Red Hat Product Security Team
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo
and
might not always be possible (the file system might be mounted
read-only, but still be modifiable beneath).
--
Florian Weimer / Red Hat Product Security Team
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More
-up).
--
Florian Weimer / Red Hat Product Security Team
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
-up).
--
Florian Weimer / Red Hat Product Security Team
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Cc: Al Viro
Signed-off-by: Florian Weimer
---
arch/x86/syscalls/syscall_32.tbl | 4
arch/x86/syscalls/syscall_64.tbl | 4
2 files changed, 8 insertions(+)
diff --git a/arch/x86/syscalls/syscall_32.tbl b/arch/x86/syscalls/syscall_32.tbl
index aabfb83..e9232bb 100644
--- a/arch/x86
This will be used to separate the xattr operations from the AT_* flags.
Cc: Alexander Viro
Signed-off-by: Florian Weimer
---
fs/xattr.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/fs/xattr.c b/fs/xattr.c
index 3377dff..9e44641 100644
--- a/fs/xattr.c
+++ b/fs/xattr.c
AT_SYMLINK_NOFOLLOW | XATTR_CREATE));
EXPECT_FAIL(ENOENT, syscall(__NR_fgetxattrat, fd, "", attrname,
buf, sizeof(buf), AT_SYMLINK_NOFOLLOW));
EXPECT_FAIL(ENOENT, syscall(__NR_flistxattrat, fd, "",
buf,
The implementation closely mirrors the existing fchownat system call.
Cc: Alexander Viro
Signed-off-by: Florian Weimer
---
fs/xattr.c | 122 +
1 file changed, 122 insertions(+)
diff --git a/fs/xattr.c b/fs/xattr.c
index 9e44641
The implementation closely mirrors the existing fchownat system call.
Cc: Alexander Viro v...@zeniv.linux.org.uk
Signed-off-by: Florian Weimer fwei...@redhat.com
---
fs/xattr.c | 122 +
1 file changed, 122 insertions(+)
diff --git a/fs
(void)
{
setup();
check_without_at();
check_at_directory();
cleanup();
setup();
check_at_path_file(file1);
cleanup();
setup();
check_at_path_file(symlink1);
cleanup();
setup();
check_at_path_symlink();
cleanup();
return 0;
}
Florian Weimer (3):
vfs: Introduce
This will be used to separate the xattr operations from the AT_* flags.
Cc: Alexander Viro v...@zeniv.linux.org.uk
Signed-off-by: Florian Weimer fwei...@redhat.com
---
fs/xattr.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/fs/xattr.c b/fs/xattr.c
index 3377dff..9e44641
Cc: Al Viro v...@zeniv.linux.org.uk
Signed-off-by: Florian Weimer fwei...@redhat.com
---
arch/x86/syscalls/syscall_32.tbl | 4
arch/x86/syscalls/syscall_64.tbl | 4
2 files changed, 8 insertions(+)
diff --git a/arch/x86/syscalls/syscall_32.tbl b/arch/x86/syscalls/syscall_32.tbl
index
in user space, so I
wonder if this could be applied, and if not, why. Thanks.
--
Florian Weimer / Red Hat Product Security Team
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo inf
in user space, so I
wonder if this could be applied, and if not, why. Thanks.
--
Florian Weimer / Red Hat Product Security Team
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org
* Matthew Garrett:
> On Sun, Sep 01, 2013 at 12:41:22PM +0200, Florian Weimer wrote:
>
>> But if you don't generate fresh keys on every boot, the persistent
>> keys are mor exposed to other UEFI applications. Correct me if I'm
>> wrong, but I don't think UEFI variable
* joeyli:
> Yes, Matthew raised this concern at before. I modified patch to load
> private key in efi stub kernel, before ExitBootServices(), that means we
> don't need generate key-pair at every system boot. So, the above
> procedure of efi bootloader will only run one time.
But if you don't
* joeyli:
Yes, Matthew raised this concern at before. I modified patch to load
private key in efi stub kernel, before ExitBootServices(), that means we
don't need generate key-pair at every system boot. So, the above
procedure of efi bootloader will only run one time.
But if you don't
* Matthew Garrett:
On Sun, Sep 01, 2013 at 12:41:22PM +0200, Florian Weimer wrote:
But if you don't generate fresh keys on every boot, the persistent
keys are mor exposed to other UEFI applications. Correct me if I'm
wrong, but I don't think UEFI variables are segregated between
different
* Chun-Yi Lee:
> + EFI bootloader must generate RSA key-pair when system boot:
>- Bootloader store the public key to EFI boottime variable by itself
>- Bootloader put The private key to S4SignKey EFI variable for forward to
> kernel.
Is the UEFI NVRAM really suited for such regular
* Chun-Yi Lee:
+ EFI bootloader must generate RSA key-pair when system boot:
- Bootloader store the public key to EFI boottime variable by itself
- Bootloader put The private key to S4SignKey EFI variable for forward to
kernel.
Is the UEFI NVRAM really suited for such regular
stabilize further?
--
Florian Weimer / Red Hat Product Security Team
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FA
stabilize further?
--
Florian Weimer / Red Hat Product Security Team
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http
* Matthew Garrett:
> On Thu, Feb 28, 2013 at 08:41:13PM +0100, Florian Weimer wrote:
>> * Matthew Garrett:
>>
>> >> Would it be possible to have a signed bootloader that allows booting
>> >> Win8 from within the secure environment, or it could exit the se
* Matthew Garrett:
>> Would it be possible to have a signed bootloader that allows booting
>> Win8 from within the secure environment, or it could exit the secure
>> environment and run unsigned grub?
>
> What would stop the unsigned grub from installing a firmware hook that
> lies about whether
* Chris Friesen:
> On 02/28/2013 01:57 AM, Florian Weimer wrote:
>
>> In any case, there's another reading of the UEFI Secure Boot
>> requirements: you may run any code you wish after calling
>> ExitBootServices(). That could be an unsigned, traditional GRUB. But
&g
* Greg KH:
> On Tue, Feb 26, 2013 at 03:13:38AM +, Matthew Garrett wrote:
>> Because Microsoft have indicated that they'd be taking a reactive
>> approach to blacklisting and because, so far, nobody has decided to
>> write the trivial proof of concept that demonstrates the problem.
>
> So,
* Greg KH:
On Tue, Feb 26, 2013 at 03:13:38AM +, Matthew Garrett wrote:
Because Microsoft have indicated that they'd be taking a reactive
approach to blacklisting and because, so far, nobody has decided to
write the trivial proof of concept that demonstrates the problem.
So, once that
* Chris Friesen:
On 02/28/2013 01:57 AM, Florian Weimer wrote:
In any case, there's another reading of the UEFI Secure Boot
requirements: you may run any code you wish after calling
ExitBootServices(). That could be an unsigned, traditional GRUB. But
this will not generally address
* Matthew Garrett:
Would it be possible to have a signed bootloader that allows booting
Win8 from within the secure environment, or it could exit the secure
environment and run unsigned grub?
What would stop the unsigned grub from installing a firmware hook that
lies about whether or not
* Matthew Garrett:
On Thu, Feb 28, 2013 at 08:41:13PM +0100, Florian Weimer wrote:
* Matthew Garrett:
Would it be possible to have a signed bootloader that allows booting
Win8 from within the secure environment, or it could exit the secure
environment and run unsigned grub?
What
* Chris Friesen:
> On 02/25/2013 10:14 AM, Matthew Garrett wrote:
>> Windows 8 will not load unsigned drivers if Secure Boot is enabled.
>
> For reference:
>
> http://msdn.microsoft.com/en-us/library/windows/desktop/hh848062%28v=vs.85%29.aspx
Thanks. Do you know perchance of any other Microsoft
* Linus Torvalds:
> So here's what I would suggest, and it is based on REAL SECURITY and
> on PUTTING THE USER FIRST instead of your continual "let's please
> microsoft by doing idiotic crap" approach.
I think the real question is this one: Is there *any* device out there
which comes with
* Matthew Garrett:
> On Mon, Feb 25, 2013 at 03:28:32PM +0100, Florian Weimer wrote:
>
>> But what puzzles me most is why anyone would assume that the UEFI
>> application signing process somehow ensures that the embedded
>> certificate is non-malicious. We c
* Theodore Ts'o:
> On Tue, Feb 26, 2013 at 02:25:55PM +1000, Dave Airlie wrote:
>>
>> Its a simple argument, MS can revoke our keys for whatever reason,
>> reducing the surface area of reasons for them to do so seems like a
>> good idea. Unless someone can read the mind of the MS guy that
>>
* Matthew Garrett:
> On Mon, Feb 25, 2013 at 10:25:08PM -0500, Theodore Ts'o wrote:
>> On Tue, Feb 26, 2013 at 03:13:38AM +, Matthew Garrett wrote:
>> >
>> > Because Microsoft have indicated that they'd be taking a reactive
>> > approach to blacklisting and because, so far, nobody has
* Matthew Garrett:
On Mon, Feb 25, 2013 at 10:25:08PM -0500, Theodore Ts'o wrote:
On Tue, Feb 26, 2013 at 03:13:38AM +, Matthew Garrett wrote:
Because Microsoft have indicated that they'd be taking a reactive
approach to blacklisting and because, so far, nobody has decided to
* Theodore Ts'o:
On Tue, Feb 26, 2013 at 02:25:55PM +1000, Dave Airlie wrote:
Its a simple argument, MS can revoke our keys for whatever reason,
reducing the surface area of reasons for them to do so seems like a
good idea. Unless someone can read the mind of the MS guy that
arbitrarily
* Matthew Garrett:
On Mon, Feb 25, 2013 at 03:28:32PM +0100, Florian Weimer wrote:
But what puzzles me most is why anyone would assume that the UEFI
application signing process somehow ensures that the embedded
certificate is non-malicious. We cannot even track it back to the
submitter
* Linus Torvalds:
So here's what I would suggest, and it is based on REAL SECURITY and
on PUTTING THE USER FIRST instead of your continual let's please
microsoft by doing idiotic crap approach.
I think the real question is this one: Is there *any* device out there
which comes with Microsoft
* Chris Friesen:
On 02/25/2013 10:14 AM, Matthew Garrett wrote:
Windows 8 will not load unsigned drivers if Secure Boot is enabled.
For reference:
http://msdn.microsoft.com/en-us/library/windows/desktop/hh848062%28v=vs.85%29.aspx
Thanks. Do you know perchance of any other Microsoft
* Matthew Garrett:
> On Mon, Feb 25, 2013 at 03:46:14PM +0100, Florian Weimer wrote:
>
>> You could just drop the requirement that ring 0 code must be signed.
>> I don't think Windows 8 enforces this, but I'm not yet sure if there
>> is a physical presence check bef
* Peter Jones:
> I just want to make sure this doesn't go unresponded to - Red Hat
> will not sign kernel modules built by an outside source. We're simply
> not going to sign these kernel modules. That's one of the big reasons
> we want a setup where they can sign their own modules in the first
* Matthew Garrett:
> I don't think that's a problem. Just put the original binary hash in the
> certificate before signing it, and extend the X.509 parser to refuse
> certificates that have a tag that's present in dbx.
Why would Microsoft put a hash of something into dbx which they
haven't
* Matthew Garrett:
> There's only one signing authority, and they only sign PE binaries.
There are at least two, with different policies, albeit run by the
same organization. Actually, we don't know how many authorities are
out there which have non-localized reach, so it's ... interesting to
* Matthew Garrett:
There's only one signing authority, and they only sign PE binaries.
There are at least two, with different policies, albeit run by the
same organization. Actually, we don't know how many authorities are
out there which have non-localized reach, so it's ... interesting to
501 - 600 of 698 matches
Mail list logo
