On Fri, Jun 13, 2014 at 3:36 AM, David Herrmann dh.herrm...@gmail.com wrote:
Hi
This is v3 of the File-Sealing and memfd_create() patches. You can find v1
with
a longer introduction at gmane:
http://thread.gmane.org/gmane.comp.video.dri.devel/102241
An LWN article about memfd+sealing is
On Fri, Jun 13, 2014 at 8:15 AM, David Herrmann dh.herrm...@gmail.com wrote:
Hi
On Fri, Jun 13, 2014 at 5:10 PM, Andy Lutomirski l...@amacapital.net wrote:
On Fri, Jun 13, 2014 at 3:36 AM, David Herrmann dh.herrm...@gmail.com
wrote:
Hi
This is v3 of the File-Sealing and memfd_create
On Thu, Jun 12, 2014 at 10:39 PM, H. Peter Anvin h...@zytor.com wrote:
On 06/12/2014 09:36 PM, Andy Lutomirski wrote:
1. Parsing the vDSO is a PITA. What if we bundled the reference
parser inside the vdso? Concretely, we could have AT_VDSO_FINDENTRY
point to a function like:
void
On Fri, Jun 13, 2014 at 8:27 AM, David Herrmann dh.herrm...@gmail.com wrote:
Hi
On Fri, Jun 13, 2014 at 5:06 PM, Andy Lutomirski l...@amacapital.net wrote:
On Fri, Jun 13, 2014 at 3:36 AM, David Herrmann dh.herrm...@gmail.com
wrote:
When setting SEAL_WRITE, we must make sure nobody has
On Fri, Jun 13, 2014 at 10:24 AM, H. Peter Anvin h...@zytor.com wrote:
On 06/12/2014 10:01 AM, Josh Boyer wrote:
On Thu, Jun 12, 2014 at 11:28 AM, Andy Lutomirski l...@amacapital.net
wrote:
The filenames are different now. Inspired by a patch from
Sam Ravnborg.
Acked-by: Sam Ravnborg s
On Fri, Jun 13, 2014 at 2:45 AM, Michal Marek mma...@suse.cz wrote:
Dne 13.6.2014 11:39, Michal Marek napsal(a):
Based on a x86-only patch by Andy Lutomirski l...@amacapital.net
With modular kernels, 'make install' is going to need the installed
modules at some point to generate the initramfs
On Tue, Jun 10, 2014 at 8:25 PM, Kees Cook keesc...@chromium.org wrote:
This adds the new seccomp syscall with both an operation and flags
parameter for future expansion. The third argument is a pointer value,
used with the SECCOMP_SET_MODE_FILTER operation. Currently, flags must
be 0. This is
On Fri, Jun 13, 2014 at 2:22 PM, Alexei Starovoitov a...@plumgrid.com wrote:
On Tue, Jun 10, 2014 at 8:25 PM, Kees Cook keesc...@chromium.org wrote:
This adds the new seccomp syscall with both an operation and flags
parameter for future expansion. The third argument is a pointer value,
used
On Fri, Jun 13, 2014 at 2:37 PM, Alexei Starovoitov a...@plumgrid.com wrote:
On Fri, Jun 13, 2014 at 2:25 PM, Andy Lutomirski l...@amacapital.net wrote:
On Fri, Jun 13, 2014 at 2:22 PM, Alexei Starovoitov a...@plumgrid.com
wrote:
On Tue, Jun 10, 2014 at 8:25 PM, Kees Cook keesc
arch_vma_name is now completely gone from x86. Good riddance.
Signed-off-by: Andy Lutomirski l...@amacapital.net
---
arch/x86/mm/init_64.c | 17 +
1 file changed, 9 insertions(+), 8 deletions(-)
diff --git a/arch/x86/mm/init_64.c b/arch/x86/mm/init_64.c
index 9deb59b..bdcde58
Cc: Pavel Emelyanov xe...@parallels.com
Signed-off-by: Andy Lutomirski l...@amacapital.net
---
arch/x86/include/asm/vdso.h | 6 ++-
arch/x86/mm/init_64.c| 3 --
arch/x86/vdso/vdso2c.h | 5 ++-
arch/x86/vdso/vdso32-setup.c | 7
arch/x86/vdso/vma.c | 25
...@seibold.net
Reported-by: Sasha Levin sasha.le...@oracle.com
Signed-off-by: Andy Lutomirski l...@amacapital.net
---
arch/x86/vdso/vma.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/arch/x86/vdso/vma.c b/arch/x86/vdso/vma.c
index e915eae..8ad0081 100644
--- a/arch/x86/vdso
install_special_mapping with
a new install_vdso_mapping function that hardcodes the [vdso]
name, to separately fix all the other arch_vma_name users (maybe
just ARM?) and then kill arch_vma_name completely.
NB: This touches core mm code. I'd appreciate some review by the mm
folks.
Andy Lutomirski (4):
x86
it. The
followup patches will remove all uses of arch_vma_name on x86,
fixing a couple of annoyances in the process.
Signed-off-by: Andy Lutomirski l...@amacapital.net
---
fs/binfmt_elf.c| 8
fs/proc/task_mmu.c | 6 ++
include/linux/mm.h | 6 ++
3 files changed, 20 insertions(+)
diff
On Tue, May 20, 2014 at 10:21 AM, Cyrill Gorcunov gorcu...@gmail.com wrote:
On Mon, May 19, 2014 at 03:58:33PM -0700, Andy Lutomirski wrote:
Using arch_vma_name to give special mappings a name is awkward. x86
currently implements it by comparing the start address of the vma to
the expected
On Tue, May 20, 2014 at 10:47 AM, Cyrill Gorcunov gorcu...@gmail.com wrote:
On Tue, May 20, 2014 at 10:24:49AM -0700, Andy Lutomirski wrote:
On Tue, May 20, 2014 at 10:21 AM, Cyrill Gorcunov gorcu...@gmail.com wrote:
On Mon, May 19, 2014 at 03:58:33PM -0700, Andy Lutomirski wrote:
Using
On Tue, May 20, 2014 at 11:18 AM, H. Peter Anvin h...@zytor.com wrote:
On 05/20/2014 11:01 AM, Cyrill Gorcunov wrote:
This patch should fix this issue, at least. If there's still a way to
get a native vdso that doesn't say [vdso], please let me know/
Yes, having a native procfs way to
On Tue, May 20, 2014 at 11:27 AM, H. Peter Anvin h...@zytor.com wrote:
On 05/20/2014 11:24 AM, Andy Lutomirski wrote:
On Tue, May 20, 2014 at 11:18 AM, H. Peter Anvin h...@zytor.com wrote:
On 05/20/2014 11:01 AM, Cyrill Gorcunov wrote:
This patch should fix this issue, at least. If there's
Here's a real proposal for iret-less return. If this is correct, then
NMIs will never nest, which will probably delete a lot more scariness
than is added by the code I'm describing.
The rest of this email is valid markdown :) If I end up implementing
this, this text will go straight into
On Tue, May 20, 2014 at 7:27 PM, Steven Rostedt rost...@goodmis.org wrote:
On Tue, 2014-05-20 at 17:53 -0700, Andy Lutomirski wrote:
If there's an NMI on the stack, we must use `RET` until we're ready
to re-enabled NMIs.
I'm a little confused by NMI on the stack. Do you mean NMI
On May 21, 2014 2:46 AM, Borislav Petkov b...@alien8.de wrote:
On Tue, May 20, 2014 at 07:39:31PM -0700, Andy Lutomirski wrote:
So the issue here is that we can have an NMI followed immediately by
an MCE.
That part might need clarification for me: #MC is higher prio interrupt
than NMI so
On May 21, 2014 7:58 AM, Vojtech Pavlik vojt...@suse.cz wrote:
On Wed, May 21, 2014 at 04:20:55PM +0200, Borislav Petkov wrote:
On Wed, May 21, 2014 at 03:42:24PM +0200, Jiri Kosina wrote:
Alright, Andy's iret optimization efforts do immediately bring a
followup question -- why is this
On May 21, 2014 5:51 AM, Jiri Kosina jkos...@suse.cz wrote:
On Tue, 20 May 2014, Andy Lutomirski wrote:
So the issue here is that we can have an NMI followed immediately by
an MCE. The MCE code can call force_sig
This is interesting by itself. force_sig() takes siglock spinlock
On Wed, May 21, 2014 at 9:30 AM, Borislav Petkov b...@alien8.de wrote:
On Wed, May 21, 2014 at 08:21:08AM -0700, Andy Lutomirski wrote:
On May 21, 2014 2:46 AM, Borislav Petkov b...@alien8.de wrote:
On Tue, May 20, 2014 at 07:39:31PM -0700, Andy Lutomirski wrote:
So the issue here
On Tue, May 20, 2014 at 5:53 PM, Andy Lutomirski l...@amacapital.net wrote:
Here's a real proposal for iret-less return. If this is correct, then
NMIs will never nest, which will probably delete a lot more scariness
than is added by the code I'm describing.
OK, here's a case where I'm wrong
be used by seccomp to explicitely set syscall filters for this ABI.
Link: http://sourceforge.net/p/libseccomp/mailman/message/32239040/
Cc: Andy Lutomirski l...@amacapital.net
Cc: Eric Paris epa...@redhat.com
Cc: Paul Moore pmo...@redhat.com
Cc: Ralf Baechle r...@linux-mips.org
Signed-off
On Wed, May 21, 2014 at 2:25 PM, Jiri Kosina jkos...@suse.cz wrote:
On Wed, 21 May 2014, Borislav Petkov wrote:
ISTM the do_machine_check code ought to consider any kill-worthy MCE
from kernel space to be non-recoverable, but I want to keep the scope
of these patches under control.
MCA
On Wed, May 21, 2014 at 2:45 PM, H. Peter Anvin h...@zytor.com wrote:
Adding Tony.
On 05/21/2014 02:43 PM, Borislav Petkov wrote:
On Thu, May 22, 2014 at 06:37:26AM +0900, Linus Torvalds wrote:
Seriously. If an NMI is interrupted by an MCE, you might as well
consider the machine dead. Don't
On Wed, May 21, 2014 at 2:48 PM, Borislav Petkov b...@alien8.de wrote:
On Wed, May 21, 2014 at 02:35:59PM -0700, Andy Lutomirski wrote:
If RIPV is set but we interrupted *kernel* code, SIGBUS doesn't seem
like the right solution anyway.
Are there any machine check exceptions for which
On Wed, May 21, 2014 at 2:55 PM, Borislav Petkov b...@alien8.de wrote:
On Wed, May 21, 2014 at 02:52:55PM -0700, Andy Lutomirski wrote:
Why is it a problem if user_mode_vm(regs)? Conversely, why is sending
a signal a remotely reasonable thing to do if !user_mode_vm(regs)?
Let me quote Jiri
One more specialized entry function is now gone. Again, this seems
to only change line numbers in entry_64.o.
Signed-off-by: Andy Lutomirski l...@amacapital.net
---
arch/x86/kernel/entry_64.S | 47 ++
1 file changed, 22 insertions(+), 25 deletions
The paranoidzeroentry macros were missing them. I'm not at all
convinced that these annotations are correct and/or necessary, but
this makes the macros more consistent with each other.
Signed-off-by: Andy Lutomirski l...@amacapital.net
---
arch/x86/kernel/entry_64.S | 2 ++
1 file changed, 2
I haven't touched the device interrupt code, which is different
enough that it's probably not worth merging, and I haven't done
anything about paranoidzeroentry_ist yet.
This appears to produce an entry_64.o file that differs only in the
debug info line numbers.
Signed-off-by: Andy Lutomirski l
a major
benefit: you can now look at the code and see how, say, the
has_error_code and !has_error_code cases differ.
Andy Lutomirski (3):
x86_64: Add missing 'DEFAULT_FRAME 0' entry annotations
x86_64: Merge most 64-bit asm entry macros
x86_64: Merge paranoidzeroentry_ist into idtentry
arch/x86
.
--Andy
The force_sig() there is legacy code - and perhaps should just move off to
mce_notify_process()
too (need to save worst so it will know what to do).
-Tony
--
Andy Lutomirski
AMA Capital Management, LLC
--
To unsubscribe from this list: send the line unsubscribe linux-kernel
On Wed, May 21, 2014 at 3:17 PM, Borislav Petkov b...@alien8.de wrote:
On Wed, May 21, 2014 at 03:13:16PM -0700, Andy Lutomirski wrote:
Why is this necessary?
If the MCE hit kernel code, then we're going to die anyway. If the
MCE hit user code, then we should be in a completely sensible
On Wed, May 21, 2014 at 3:18 PM, Luck, Tony tony.l...@intel.com wrote:
That TIF_MCE_NOTIFY prevents the return to user mode, and we end up in
mce_notify_process().
Why is this necessary?
The recovery path has to do more than just send a signal - it needs to walk
processes and
mms to see
On Wed, May 21, 2014 at 3:25 PM, Andi Kleen a...@firstfloor.org wrote:
Seems like a lot of effort and risk to essentially only optimize in kernel
interrupt handlers.
The idea is that it might allow us to remove a bunch of scary nested
NMI code as well as speeding things up.
AFAIK the most
On Wed, May 21, 2014 at 3:32 PM, Luck, Tony tony.l...@intel.com wrote:
The recovery path has to do more than just send a signal - it needs to walk
processes and
mms to see which have mapped the physical address that the h/w told us
has gone bad.
I still feel like I'm missing something. If
On Wed, May 21, 2014 at 3:36 PM, H. Peter Anvin h...@zytor.com wrote:
On 05/21/2014 11:11 AM, Andy Lutomirski wrote:
On Tue, May 20, 2014 at 5:53 PM, Andy Lutomirski l...@amacapital.net wrote:
Here's a real proposal for iret-less return. If this is correct, then
NMIs will never nest, which
On Mon, May 19, 2014 at 10:59 PM, Jet Chen jet.c...@intel.com wrote:
Hi Andy,
FYI, we noticed the below changes on
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86/vdso
commit cfda7bb9ecbf9d96264bb5bade33a842966d1062 (x86, vdso: Move syscall
and sysenter setup into
On Wed, May 21, 2014 at 3:48 PM, Borislav Petkov b...@alien8.de wrote:
On Wed, May 21, 2014 at 03:39:11PM -0700, Andy Lutomirski wrote:
But if we get a new MCE in here, it will be an MCE from kernel context
and it's fatal. So, yes, we'll clobber the stack, but we'll never
return (unless
On Wed, May 21, 2014 at 4:05 PM, Luck, Tony tony.l...@intel.com wrote:
On Wed, May 21, 2014 at 03:39:11PM -0700, Andy Lutomirski wrote:
But if we get a new MCE in here, it will be an MCE from kernel context
and it's fatal. So, yes, we'll clobber the stack, but we'll never
return (unless
On Wed, May 21, 2014 at 4:51 PM, Borislav Petkov b...@alien8.de wrote:
On Thu, May 22, 2014 at 08:30:33AM +0900, Linus Torvalds wrote:
If the OS then decides to take down the whole machine, the OS - not
the hardware - can choose to do something that will punch through
other CPU's NMI blocking
This turns the vsyscall page all the way off in vsyscall=none mode
and fixes a bug in warn_bad_vsyscall that resulted in corrupt log
lines.
With this series applied, vsyscall=none results in a tidier
/proc/PID/maps.
Andy Lutomirski (3):
x86_64,vsyscall: Move all of the gate_area code
of the
line. Revert the bad part of it.
The printk in question isn't actually bare; the level is %s.
Signed-off-by: Andy Lutomirski l...@amacapital.net
---
arch/x86/kernel/vsyscall_64.c | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/x86/kernel/vsyscall_64.c b/arch/x86
This code exists for the sole purpose of making the vsyscall page
look sort of like real userspace memory. Move it so that it lives
with the rest of the vsyscall code.
Signed-off-by: Andy Lutomirski l...@amacapital.net
---
arch/x86/kernel/vsyscall_64.c | 49
-by: Andy Lutomirski l...@amacapital.net
---
arch/x86/kernel/vsyscall_64.c | 14 +-
1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a/arch/x86/kernel/vsyscall_64.c b/arch/x86/kernel/vsyscall_64.c
index ad84894..8d38eb5 100644
--- a/arch/x86/kernel/vsyscall_64.c
+++ b/arch
It would be nice to have a way for new programs to declare that they
don't need vsyscalls. What's the right way to do this? An ELF header
entry in the loader? An ELF header entry in the program? A new
arch_prctl?
As background, there's an old part of the x86_64 ABI that allows
programs to do
.
Signed-off-by: Kees Cook keesc...@chromium.org
Acked-by: Andy Lutomirski l...@amacapital.net
--
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
On Thu, May 22, 2014 at 4:05 PM, Kees Cook keesc...@chromium.org wrote:
Applying restrictive seccomp filter programs to large or diverse
codebases often requires handling threads which may be started early in
the process lifetime (e.g., by code that is linked in). While it is
possible to apply
On Wed, May 14, 2014 at 5:28 PM, H. Peter Anvin h...@zytor.com wrote:
On 05/14/2014 01:56 PM, Davidlohr Bueso wrote:
However, unless I'm sorely mistaken, the larger problem is that glibc
removed the futex() call entirely, so these man pages don't describe
I don't think futex() ever was in
On May 14, 2014 8:36 PM, Pavel Emelyanov xe...@parallels.com wrote:
On 05/15/2014 02:23 AM, Andy Lutomirski wrote:
On Wed, May 14, 2014 at 3:11 PM, Cyrill Gorcunov gorcu...@gmail.com wrote:
On Wed, May 14, 2014 at 02:33:54PM -0700, Andy Lutomirski wrote:
On Wed, May 14, 2014 at 2:31 PM
On Thu, May 15, 2014 at 1:45 AM, Cyrill Gorcunov gorcu...@gmail.com wrote:
On Wed, May 14, 2014 at 03:23:27PM -0700, Andy Lutomirski wrote:
I can summarize:
On 3.14 and before, the vdso is just a bunch of ELF headers and
executable data. When executed by 64-bit binaries, it reads from
On Thu, May 15, 2014 at 12:53 PM, Cyrill Gorcunov gorcu...@gmail.com wrote:
On Thu, May 15, 2014 at 12:46:34PM -0700, Andy Lutomirski wrote:
On Thu, May 15, 2014 at 1:45 AM, Cyrill Gorcunov gorcu...@gmail.com wrote:
On Wed, May 14, 2014 at 03:23:27PM -0700, Andy Lutomirski wrote:
I can
On Thu, May 15, 2014 at 2:31 PM, Cyrill Gorcunov gorcu...@gmail.com wrote:
On Fri, May 16, 2014 at 12:19:14AM +0400, Cyrill Gorcunov wrote:
I see what you mean. We're rather targeting on bare x86-64 at the moment
but compat mode is needed as well (not yet implemented though). I'll take
a
On Thu, May 15, 2014 at 2:57 PM, Cyrill Gorcunov gorcu...@gmail.com wrote:
On Thu, May 15, 2014 at 02:42:48PM -0700, Andy Lutomirski wrote:
Looking forward the question appear -- will VDSO_PREV_PAGES and rest of
variables
be kind of immutable constants? If yes, we could calculate where
On Thu, May 15, 2014 at 3:15 PM, Andy Lutomirski l...@amacapital.net wrote:
On Thu, May 15, 2014 at 2:57 PM, Cyrill Gorcunov gorcu...@gmail.com wrote:
On Thu, May 15, 2014 at 02:42:48PM -0700, Andy Lutomirski wrote:
Looking forward the question appear -- will VDSO_PREV_PAGES and rest
On 05/15/2014 02:09 PM, Erik Bosman wrote:
Architecture independent code for signal canaries
Add support for canary values in user-space signal frames. These canaries
function much like stack canaries/cookies, making it harder for an attacker to
fake a call to {rt_,}sigreturn()
This
On May 15, 2014 1:26 PM, Serge E. Hallyn se...@hallyn.com wrote:
Quoting Richard Weinberger (rich...@nod.at):
Am 15.05.2014 21:50, schrieb Serge Hallyn:
Quoting Richard Weinberger (richard.weinber...@gmail.com):
On Thu, May 15, 2014 at 4:08 PM, Greg Kroah-Hartman
On 05/28/2014 05:19 AM, Philipp Kern wrote:
audit_filter_syscall uses the syscall number to reference into a
bitmask (e-rule.mask[word]). Not removing the x32 bit before passing
the number to this architecture independent codepath will fail to
lookup the proper audit bit. Furthermore it will
On Wed, May 28, 2014 at 2:01 PM, H. Peter Anvin h...@linux.intel.com wrote:
On 05/28/2014 01:47 PM, Andy Lutomirski wrote:
On 05/28/2014 05:19 AM, Philipp Kern wrote:
audit_filter_syscall uses the syscall number to reference into a
bitmask (e-rule.mask[word]). Not removing the x32 bit before
On Wed, May 28, 2014 at 2:19 PM, H. Peter Anvin h...@linux.intel.com wrote:
On 05/28/2014 02:15 PM, Andy Lutomirski wrote:
3. The OOPS you're fixing doesn't seem like it's fixed. What if some
other random high bits are set?
There is a range check in entry_*.S for the system call.
I can
On Wed, May 28, 2014 at 2:53 PM, Philipp Kern pk...@google.com wrote:
On Wed, May 28, 2014 at 11:43 PM, Andy Lutomirski l...@amacapital.net wrote:
However: are you sure that entry_64.S handles this? It looks like
tracesys has higher priority than badsys. And strace can certainly
see out
.
- Its approach to memory allocation is terrifying.
I considered marking it BROKEN, but that might be too harsh.
Signed-off-by: Andy Lutomirski l...@amacapital.net
---
init/Kconfig | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/init/Kconfig b/init/Kconfig
index
CONFIG_AUDITSYSCALL is awful. Patch 2 enumerates some reasons.
Patch 1 fixes a nasty DoS and possible information leak. It should
be applied and backported.
Patch 2 is optional. I leave it to other peoples' judgment.
Andy Lutomirski (2):
auditsc: audit_krule mask accesses need bounds
Fixes an easy DoS and possible information disclosure.
This does nothing about the broken state of x32 auditing.
Cc: sta...@vger.kernel.org
Signed-off-by: Andy Lutomirski l...@amacapital.net
---
kernel/auditsc.c | 27 ++-
1 file changed, 18 insertions(+), 9 deletions
| _TIF_NEED_RESCHED);
+ if (old == val)
+ return true;
+ val = old;
+ }
+}
Do you have an updated patch? After fixing the MIME flow damage
(sigh), it doesn't apply to sched/core, which is my best guess for
what it's based on.
--Andy
--
Andy
.
- Its approach to freeing memory is terrifying.
Signed-off-by: Andy Lutomirski l...@amacapital.net
---
init/Kconfig | 13 -
1 file changed, 8 insertions(+), 5 deletions(-)
diff --git a/init/Kconfig b/init/Kconfig
index 9d3585b..24d4b53 100644
--- a/init/Kconfig
+++ b/init/Kconfig
Fixes an easy DoS and possible information disclosure.
This does nothing about the broken state of x32 auditing.
Cc: sta...@vger.kernel.org
Signed-off-by: Andy Lutomirski l...@amacapital.net
---
kernel/auditsc.c | 27 ++-
1 file changed, 18 insertions(+), 9 deletions
CONFIG_AUDITSYSCALL is awful. Patch 2 enumerates some reasons.
Patch 1 fixes a nasty DoS and possible information leak. It should
be applied and backported.
Patch 2 is optional. I leave it to other peoples' judgment.
Andy Lutomirski (2):
auditsc: audit_krule mask accesses need bounds
On Wed, May 28, 2014 at 7:23 PM, Eric Paris epa...@redhat.com wrote:
On Wed, 2014-05-28 at 18:44 -0700, Andy Lutomirski wrote:
Fixes an easy DoS and possible information disclosure.
This does nothing about the broken state of x32 auditing.
Cc: sta...@vger.kernel.org
Signed-off-by: Andy
On Wed, May 28, 2014 at 7:09 PM, Eric Paris epa...@redhat.com wrote:
NAK
On Wed, 2014-05-28 at 18:44 -0700, Andy Lutomirski wrote:
Here are some issues with the code:
- It thinks that syscalls have four arguments.
Not true at all. It records the registers that would hold the first 4
On Wed, May 28, 2014 at 7:43 PM, Eric Paris epa...@redhat.com wrote:
On Wed, 2014-05-28 at 19:27 -0700, Andy Lutomirski wrote:
On Wed, May 28, 2014 at 7:23 PM, Eric Paris epa...@redhat.com wrote:
On Wed, 2014-05-28 at 18:44 -0700, Andy Lutomirski wrote:
Fixes an easy DoS and possible
On Wed, May 28, 2014 at 7:54 PM, Eric Paris epa...@redhat.com wrote:
On Wed, 2014-05-28 at 19:40 -0700, Andy Lutomirski wrote:
On Wed, May 28, 2014 at 7:09 PM, Eric Paris epa...@redhat.com wrote:
NAK
On Wed, 2014-05-28 at 18:44 -0700, Andy Lutomirski wrote:
Here are some issues
On Thu, May 29, 2014 at 6:05 AM, Steve Grubb sgr...@redhat.com wrote:
On Wednesday, May 28, 2014 07:40:57 PM Andy Lutomirski wrote:
- It assumes that syscall numbers are between 0 and 2048.
There could well be a bug here. Not questioning that. Although that
would be patch 1/2
Even
On Thu, May 29, 2014 at 9:25 AM, Steve Grubb sgr...@redhat.com wrote:
On Thursday, May 29, 2014 09:04:10 AM Andy Lutomirski wrote:
On Thu, May 29, 2014 at 6:05 AM, Steve Grubb sgr...@redhat.com wrote:
On Wednesday, May 28, 2014 07:40:57 PM Andy Lutomirski wrote:
- It assumes that syscall
On Thu, May 29, 2014 at 12:17 PM, Paul Gortmaker
paul.gortma...@windriver.com wrote:
On Mon, May 5, 2014 at 6:25 PM, tip-bot for Andy Lutomirski
tip...@zytor.com wrote:
Commit-ID: 6f121e548f83674ab4920a4e60afb58d4f61b829
Gitweb:
http://git.kernel.org/tip
On Thu, May 29, 2014 at 12:43 PM, H. Peter Anvin h...@zytor.com wrote:
On 05/29/2014 12:32 PM, Andy Lutomirski wrote:
On Thu, May 29, 2014 at 12:17 PM, Paul Gortmaker
paul.gortma...@windriver.com wrote:
On Mon, May 5, 2014 at 6:25 PM, tip-bot for Andy Lutomirski
tip...@zytor.com wrote
This adds a macro GET(x) to convert x from big-endian to
little-endian. Hopefully I put it everywhere it needs to go and got
all the cases needed for everyone's linux/elf.h.
Signed-off-by: Andy Lutomirski l...@amacapital.net
---
arch/x86/vdso/vdso2c.c | 15 +
arch/x86/vdso/vdso2c.h
Patch 1 causes make;make to behave similarly to make if vdso2c fails.
Patch 2 hopefully fixes x86 crossbuilds on big-endian machines. I don't
have a big-endian machine to test on, though.
Andy Lutomirski (2):
x86,vdso: When vdso2c fails, unlink the output
x86,vdso: Fix cross-compilation from
This avoids bizarre failures if make is run again.
Signed-off-by: Andy Lutomirski l...@amacapital.net
---
arch/x86/vdso/vdso2c.c | 20 +++-
arch/x86/vdso/vdso2c.h | 10 +++---
2 files changed, 14 insertions(+), 16 deletions(-)
diff --git a/arch/x86/vdso/vdso2c.c b/arch/x86
On Thu, May 29, 2014 at 3:41 PM, Paul Gortmaker
paul.gortma...@windriver.com wrote:
On 14-05-29 05:57 PM, Andy Lutomirski wrote:
Patch 1 causes make;make to behave similarly to make if vdso2c fails.
Patch 2 hopefully fixes x86 crossbuilds on big-endian machines. I don't
have a big-endian
On Thu, May 29, 2014 at 10:42 PM, Stephen Rothwell s...@canb.auug.org.au
wrote:
Hi Andy,
On Thu, 29 May 2014 15:49:52 -0700 Andy Lutomirski l...@amacapital.net
wrote:
On Thu, May 29, 2014 at 3:41 PM, Paul Gortmaker
paul.gortma...@windriver.com wrote:
On 14-05-29 05:57 PM, Andy
This adds a macro GET(x) to convert x from big-endian to
little-endian. Hopefully I put it everywhere it needs to go and got
all the cases needed for everyone's linux/elf.h.
Signed-off-by: Andy Lutomirski l...@amacapital.net
---
arch/x86/vdso/vdso2c.c | 15
arch/x86/vdso/vdso2c.h
Patch 1 causes make;make to behave similarly to make if vdso2c fails.
Patch 2 hopefully fixes x86 crossbuilds on big-endian machines. I don't
have a big-endian machine to test on, though.
Changes from v1: Add two missing endian fixes
Andy Lutomirski (2):
x86,vdso: When vdso2c fails, unlink
This avoids bizarre failures if make is run again.
Signed-off-by: Andy Lutomirski l...@amacapital.net
---
arch/x86/vdso/vdso2c.c | 20 +++-
arch/x86/vdso/vdso2c.h | 10 +++---
2 files changed, 14 insertions(+), 16 deletions(-)
diff --git a/arch/x86/vdso/vdso2c.c b/arch/x86
On Wed, May 28, 2014 at 2:45 PM, H. Peter Anvin h...@zytor.com wrote:
On 05/23/2014 09:40 AM, Andy Lutomirski wrote:
I don't think this should be something configured by the
administrator, unless the administrator is the builder of a kiosky
thing like Chromium OS. In that case
On Fri, May 30, 2014 at 1:02 PM, H. Peter Anvin h...@zytor.com wrote:
On 05/30/2014 08:48 AM, Andy Lutomirski wrote:
This adds a macro GET(x) to convert x from big-endian to
little-endian. Hopefully I put it everywhere it needs to go and got
all the cases needed for everyone's linux/elf.h
On Fri, May 30, 2014 at 1:05 PM, H. Peter Anvin h...@zytor.com wrote:
On 05/30/2014 01:00 PM, Andy Lutomirski wrote:
Do the flags go in the ELF loader or in the executable we're running?
Or both (and, if both, do we and them or or them)?
I think the interpreter makes a little more sense
On Fri, May 30, 2014 at 1:21 PM, H. Peter Anvin h...@zytor.com wrote:
On 05/30/2014 01:09 PM, Andy Lutomirski wrote:
I came up with the following, it seems like a reasonable simplification:
#define _LE(x, bits, ifnot) \
__builtin_choose_expr
On Fri, May 30, 2014 at 1:20 PM, H. Peter Anvin h...@zytor.com wrote:
On 05/30/2014 01:11 PM, Andy Lutomirski wrote:
On Fri, May 30, 2014 at 1:05 PM, H. Peter Anvin h...@zytor.com wrote:
On 05/30/2014 01:00 PM, Andy Lutomirski wrote:
Do the flags go in the ELF loader or in the executable
syscall_in_syscall will return true if we're in a real syscall and
will return false if we're not in a syscall. If we're in a bad
syscall, the return value can vary.
The idea is to use this to come up with a much simpler replacement
for syscall auditing.
Signed-off-by: Andy Lutomirski l
think.
Andy Lutomirski (2):
x86,syscall: Add syscall_in_syscall to test whether we're in a syscall
audit: Syscall auditing lite
arch/x86/Kconfig | 1 +
arch/x86/include/asm/syscall.h | 21
init/Kconfig | 3 +++
kernel/audit.c
fields (arch, syscall, and a0..a5) will only be logged if we
are in a syscall but we aren't otherwise building an auditsc context.
This is only supported on x86 for now. Other architectures can get
this if they implement syscall_in_syscall.
Signed-off-by: Andy Lutomirski l...@amacapital.net
On Fri, May 23, 2014 at 6:16 AM, James Bottomley
james.bottom...@hansenpartnership.com wrote:
On Fri, 2014-05-23 at 11:20 +0300, Marian Marinov wrote:
On 05/20/2014 05:19 PM, Serge Hallyn wrote:
Quoting Andy Lutomirski (l...@amacapital.net):
On May 15, 2014 1:26 PM, Serge E. Hallyn se
On Thu, May 22, 2014 at 7:44 PM, Marian Marinov m...@1h.com wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 05/23/2014 02:04 AM, Andy Lutomirski wrote:
It would be nice to have a way for new programs to declare that they don't
need vsyscalls. What's the right way to
do
On Mon, May 26, 2014 at 4:06 AM, Borislav Petkov b...@alien8.de wrote:
On Mon, May 26, 2014 at 12:51:10PM +0200, Jiri Kosina wrote:
I think the comment is still not explaining the big part of what the
discussion was about -- i.e. if it was in kernel context, we always
panic.
I thought the
On Mon, May 26, 2014 at 6:27 AM, Djalal Harouni tix...@opendz.org wrote:
Add the deny or allow flags, so we can perform proper permission checks
and set the result accordingly. These flags are needed in case we have
to cache the result of permission checks that are done during -open()
time.
On Mon, May 26, 2014 at 6:27 AM, Djalal Harouni tix...@opendz.org wrote:
Add the helper pid_entry_access() to unify the permission checks during
-open()
This is a preparation patch.
Signed-off-by: Djalal Harouni tix...@opendz.org
---
fs/proc/generic.c | 22 ++
701 - 800 of 19466 matches
Mail list logo
