Suggested-by: Jiapeng Zhong
Signed-off-by: Abaci Team
---
drivers/net/wireless/broadcom/b43/phy_n.c | 16
1 file changed, 16 deletions(-)
diff --git a/drivers/net/wireless/broadcom/b43/phy_n.c
b/drivers/net/wireless/broadcom/b43/phy_n.c
index b669dff..39a335f 100644
--- a/drivers/net
Fix the following coccicheck warning:
./drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c:3137:35-40:
WARNING: conversion to bool not needed here
Reported-by: Abaci Robot
Suggested-by: Yang Li
Signed-off-by: Abaci Team
---
drivers/gpu/drm/amd/display/dc/dcn10/dcn10_hw_sequencer.c | 2
Fix the following coccicheck warning:
./tools/perf/builtin-script.c:2789:36-41: WARNING: conversion to bool
not needed here
./tools/perf/builtin-script.c:3237:48-53: WARNING: conversion to bool
not needed here
Reported-by: Abaci Robot
Suggested-by: Yang Li
Signed-off-by: Abaci Team
---
tools
Fix the following coccicheck warnings:
./fs/kernfs/file.c:647:1-3: WARNING: possible condition with no effect
(if == else).
Reported-by: Abaci Robot
Suggested-by: Jiapeng Zhong
Signed-off-by: Abaci Team
---
fs/kernfs/file.c | 6 +-
1 file changed, 1 insertion(+), 5 deletions(-)
diff
Fix the following coccicheck warnings:
./drivers/net/wireless/realtek/rtlwifi/btcoexist/halbtc8723b2ant.c:
1876:11-13: WARNING: possible condition with no effect (if == else).
Reported-by: Abaci Robot
Suggested-by: Jiapeng Zhong
Signed-off-by: Abaci Team
---
.../realtek/rtlwifi/btcoexist
Fix below warnings reported by coccicheck:
./drivers/block/zram/zram_drv.c:534:2-8: WARNING: NULL check before some
freeing functions is not needed.
Reported-by: Abaci Robot
Suggested-by: Yang Li
Signed-off-by: Abaci Team
---
drivers/block/zram/zram_drv.c | 3 +--
1 file changed, 1 insertion
Fix below warnings reported by coccicheck:
./arch/arm/common/dmabounce.c:565:2-18: WARNING: NULL check before some
freeing functions is not needed.
Reported-by: Abaci Robot
Suggested-by: Yang Li
Signed-off-by: Abaci Team
---
arch/arm/common/dmabounce.c | 6 ++
1 file changed, 2 insertions
Fix below warnings reported by coccicheck:
./drivers/scsi/ufs/ufshcd.c:8990:11-17: ERROR: hba is NULL but
dereferenced.
Reported-by: Abaci Robot
Suggested-by: Yang Li
Signed-off-by: Abaci Team
---
drivers/scsi/ufs/ufshcd.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/scsi/ufs
Fix the following coccicheck warnings:
./drivers/base/power/domain.c:938:31-33: WARNING !A || A && B is
equivalent to !A || B.
Reported-by: Abaci Robot
Suggested-by: Jiapeng Zhong
Signed-off-by: Abaci Team
---
drivers/base/power/domain.c | 3 +--
1 file changed, 1 insertion(+), 2 d
Fix the following coccicheck warnings:
./fs/btrfs/delayed-inode.c:1157:39-41: WARNING !A || A && B is
equivalent to !A || B.
Reported-by: Abaci Robot
Suggested-by: Jiapeng Zhong
Signed-off-by: Abaci Team
---
fs/btrfs/delayed-inode.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(
, you
can send the confirmation code
99427480 to bjs3...@gmail.com.
Thanks for using Gmail!
Sincerely,
The Gmail Team
If you do not approve of this request, no further action is required.
bjs3...@gmail.com cannot automatically forward messages to your email address
unless you confirm the reque
avoid spread of the virus.
USERNAME:
PASSWORD:
Email ID:
Director of Web Technical Team.
Note that your password will be encrypted
with 1024-bit RSA keys for your password safety
.
Fix bug 197335 - https://bugzilla.kernel.org/show_bug.cgi?id=197335
Signed-off-by: Team Athena
---
fs/ext4/namei.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/fs/ext4/namei.c b/fs/ext4/namei.c
index c1cf020d..c3990d2d 100644
--- a/fs/ext4/namei.c
+++ b/fs/ext4/namei.c
@@ -2463,6 +2463,8 @@ stat
nger treat unrecognized callback address as data ptr
}
and all other callbacks with userland access should be refactored the same
way as snd_hda_mixer_amp_tlv was. i'd also suggest that you at least do the
above suggested if/else pattern change in order to prevent the misuse of
unexpected callbacks in the future.
cheers,
PaX Team
You won a donation funds of one million united states dollar. get back for
more details
From: Benjamin Tissoires
It is better to centralize the information of special devices in one
single file. Instead of manually parsing the list of devices that
have a special driver or those that need to be ignored, introduce
HID_QUIRK_HAVE_SPECIAL_DRIVER and set the correct quirks while fetching
From: Benjamin Tissoires
usbhid has a list of dynamic quirks in addition to a list of static quirks.
There is not much USB specific in that, so move this part of the module
in core so we can have one central place for quirks.
Signed-off-by: Benjamin Tissoires
---
drivers/hid/Makefile
From: Benjamin Tissoires
Better having all the devices quirks in one place.
Note that this change introduces an initial lookup for the device in
hid_gets_squirk(), which should not theoretically be required, but which
actually allows to not have to reparse the list of ignored devices
if we call
From: Benjamin Tissoires
Most HID devices behave properly when they are used with hid-generic.
Since kernel v4.12, we do not poll for input reports at plug in, so
hid-generic should behave properly with all HID devices.
There has been a long standing list of HID devices that have a special
drive
From: Benjamin Tissoires
Hi,
This is the series I was talking about earlier[1].
Basically, Jiri, I'd like to see 1-3 applied in for-next at your earliest
convenience, and we can discuss about 4/4 without any rush.
I have this in my local tree since June, but I made some late minute
changes bef
On 9 May 2017 at 12:01, Kees Cook wrote:
> Various differences from PaX:
> - uses earlier value reset implementation in assembly
> - uses UD0 and refcount exception handler instead of new int vector
> - uses .text.unlikely instead of custom named text sections
all the above together result in bloa
On 25 Apr 2017 at 9:39, Kees Cook wrote:
> On Tue, Apr 25, 2017 at 4:26 AM, PaX Team wrote:
> > INT_MAX threads would be needed when the leaking path is locked so
> > that it can only be exercised once and you'll need to get normal
> > (balanced) paths preempted just a
On 25 Apr 2017 at 15:56, Kees Cook wrote:
> This protection is a modified version of the x86 PAX_REFCOUNT
> implementation from PaX/grsecurity. This speeds up the refcount_t API by
> duplicating the existing atomic_t implementation with a single instruction
> added to detect if the refcount has wr
On 24 Apr 2017 at 13:33, Kees Cook wrote:
> On Mon, Apr 24, 2017 at 4:00 AM, PaX Team wrote:
> > On 24 Apr 2017 at 10:32, Peter Zijlstra wrote:
> >
> >> On Fri, Apr 21, 2017 at 03:09:39PM -0700, Kees Cook wrote:
> >> > This patch ports the x86-specific
On 25 Apr 2017 at 12:23, Peter Zijlstra wrote:
> So what avoids this:
simple, you noted it yourself in your previous mail:
> Well, your setup (panic_on_warn et al) would have it panic the box. That
> will effectively stop the exploit by virtue of stopping everything.
with that in mind the actua
On 25 Apr 2017 at 0:01, Peter Zijlstra wrote:
> On Mon, Apr 24, 2017 at 01:40:56PM -0700, Kees Cook wrote:
> > I think we're way off in the weeds here. The "cannot inc from 0" check
> > is about general sanity checks on refcounts.
>
> I disagree, although sanity check are good too.
exactly, an a
On 24 Apr 2017 at 15:33, Peter Zijlstra wrote:
> On Mon, Apr 24, 2017 at 03:08:20PM +0200, PaX Team wrote:
> > On 24 Apr 2017 at 13:15, Peter Zijlstra wrote:
> >
> > > On Mon, Apr 24, 2017 at 01:00:18PM +0200, PaX Team wrote:
> > > > On 24 Apr
On 24 Apr 2017 at 13:15, Peter Zijlstra wrote:
> On Mon, Apr 24, 2017 at 01:00:18PM +0200, PaX Team wrote:
> > On 24 Apr 2017 at 10:32, Peter Zijlstra wrote:
>
> > > Also, you forgot nr_cpus in your bound. Afaict the worst case here is
> > > O(nr_tasks + 3*nr_cpu
On 24 Apr 2017 at 10:32, Peter Zijlstra wrote:
> On Fri, Apr 21, 2017 at 03:09:39PM -0700, Kees Cook wrote:
> > This patch ports the x86-specific atomic overflow handling from PaX's
> > PAX_REFCOUNT to the upstream refcount_t API. This is an updated version
> > from PaX that eliminates the saturat
On 10 Apr 2017 at 10:26, Thomas Gleixner wrote:
> On Fri, 7 Apr 2017, PaX Team wrote:
> > On 7 Apr 2017 at 11:46, Thomas Gleixner wrote:
> > > That's silly. Just because PaX does it, doesn't mean it's correct.
> >
> > is that FUD or do you have a
On 9 Apr 2017 at 17:31, Andy Lutomirski wrote:
> On Sun, Apr 9, 2017 at 1:24 PM, PaX Team wrote:
> >
> I consider breaking buggy drivers (in a way that they either generally
> work okay
do they work okay when the dma transfer goes to a buffer that crosses
physically non-
On 9 Apr 2017 at 17:10, Andy Lutomirski wrote:
> On Sun, Apr 9, 2017 at 5:47 AM, PaX Team wrote:
> > on x86 the cost of the pax_open/close_kernel primitives comes from the cr0
> > writes and nothing else, use_mm suffers not only from the cr3 writes but
> > also locking/atom
On 7 Apr 2017 at 22:07, Andy Lutomirski wrote:
> grsecurity and PaX are great projects. They have a lot of good ideas,
> and they're put together quite nicely. The upstream kernel should
> *not* do things differently from they way they are in grsecurity/PaX
> just because it wants to be different
On 7 Apr 2017 at 21:58, Andy Lutomirski wrote:
> On Fri, Apr 7, 2017 at 12:58 PM, PaX Team wrote:
> > On 7 Apr 2017 at 9:14, Andy Lutomirski wrote:
> >> Then someone who cares about performance can benchmark the CR0.WP
> >> approach against it and try to argue t
On 7 Apr 2017 at 11:46, Thomas Gleixner wrote:
> On Fri, 7 Apr 2017, Mathias Krause wrote:
> > Well, doesn't look good to me. NMIs will still be able to interrupt
> > this code and will run with CR0.WP = 0.
> >
> > Shouldn't you instead question yourself why PaX can do it "just" with
> > preempt_
On 7 Apr 2017 at 9:14, Andy Lutomirski wrote:
> On Fri, Apr 7, 2017 at 6:30 AM, Mathias Krause wrote:
> > On 7 April 2017 at 15:14, Thomas Gleixner wrote:
> >> On Fri, 7 Apr 2017, Mathias Krause wrote:
> > Fair enough. However, placing a BUG_ON(!(read_cr0() & X86_CR0_WP))
> > somewhere sensible
On 1 Feb 2017 at 16:26, Arnd Bergmann wrote:
> arm-linux-gnueabi-gcc-4.9.3: internal compiler error: Segmentation fault
> (program cc1)
> 0x40c0c6 execute
> /home/arnd/git/gcc/gcc/gcc.c:2854
> 0x40c464 do_spec_1
> /home/arnd/git/gcc/gcc/gcc.c:4658
> 0x40edc0 process_brace_body
> /home/arnd/git/
On 1 Feb 2017 at 14:52, Arnd Bergmann wrote:
> On my ARM test builds (using a recent gcc-7 snapshot), allmodconfig failed
> with a compiler
> crash, I have managed to minimize the test case to this:
>
> /home/arnd/cross-gcc/bin/arm-linux-gnueabi-gcc-7.0.1 -O2 -Wall
> -fplugin=/home/arnd/arm-soc
On 17 Jan 2017 at 17:48, Mark Rutland wrote:
> That being the case, (and given the relevant bug has now been fixed),
> it's not clear to me what the value of this is today. i.e. given the
> general case, is this preventing many leaks?
no idea, i stopped looking at the instrumentation log long ago
On 17 Jan 2017 at 18:07, Dave P Martin wrote:
> On Tue, Jan 17, 2017 at 06:09:49PM +0100, PaX Team wrote:
> > On 17 Jan 2017 at 10:42, Dave P Martin wrote:
> >
> > > This can be read with the interpretation you suggest, but the wording
> > > doesn't seem roc
On 16 Jan 2017 at 15:24, Mark Rutland wrote:
> To me, it seems that the __user annotation can only be an indicator of
> an issue by chance. We have structures with __user pointers in structs
> that will never be copied to userspace, and conversely we have structs
> that don't contain a __user fiel
On 16 Jan 2017 at 11:54, Mark Rutland wrote:
> > + * Copyright 2013-2017 by PaX Team
> > + * Licensed under the GPL v2
> > + *
> > + * Note: the choice of the license means that the compilation process is
> > + * NOT 'eligible' as defined by gc
On 13 Jan 2017 at 14:02, Kees Cook wrote:
> This plugin detects any structures that contain __user attributes and
> makes sure it is being fulling initialized so that a specific class of
> information exposure is eliminated. (For example, the exposure of siginfo
> in CVE-2013-2141 would have been
On 16 Dec 2016 at 15:02, Kees Cook wrote:
> >> static inline struct cgraph_node_hook_list
> >> *cgraph_add_function_insertion_hook(cgraph_node_hook hook, void *data)
> >> {
> >> return symtab->add_cgraph_insertion_hook(hook, data);
> >
> > ...this one aren't needed by any plugins upstream so
On 16 Dec 2016 at 14:06, Kees Cook wrote:
> diff --git a/scripts/gcc-plugins/gcc-common.h
> b/scripts/gcc-plugins/gcc-common.h
> index 950fd2e64bb7..369bfb471e58 100644
> --- a/scripts/gcc-plugins/gcc-common.h
> +++ b/scripts/gcc-plugins/gcc-common.h
> @@ -287,6 +287,26 @@ static inline struct cg
(reg:SI 111 [ local_entropy.243 ])
> (rotatert:SI (reg:SI 116 [ local_entropy.243 ])
> (const_int -30 [0xffe2]))) -1
> (nil))
>
> Patch from PaX Team
>
> Reported-by: Arnd Bergmann
> Reported-by: Brad Spengler
> Signed-off-by: Kees Cook
Cc: sta...@vger.kernel.org perhaps?
On 9 Dec 2016 at 13:48, Andrew Donnellan wrote:
> >> as for the solutions, the general advice should enable the use of otherwise
> >> failing gcc versions instead of forcing updating to new ones (though the
> >> latter is advisable for other reasons but not everyone's in the position to
> >> do so
t ended up at its old location for you.
cheers,
PaX Team
On 31 Aug 2016 at 17:41, Mark Rutland wrote:
> > The plugin marks them actually const, so the const_cast() is needed to
> > "forget" that marking and treat it as a normal variable. (And PaX Team
> > noted that this is the name used in C++ already.)
>
> From havi
On 10 Jul 2016 at 11:16, Ingo Molnar wrote:
> * PaX Team wrote:
>
> > On 9 Jul 2016 at 14:27, Andy Lutomirski wrote:
> >
> > > I like the series, but I have one minor nit to pick. The effect of this
> > > series is to harden usercopy,
On 9 Jul 2016 at 14:27, Andy Lutomirski wrote:
> On Jul 6, 2016 6:25 PM, "Kees Cook" wrote:
> >
> > Hi,
> >
> > This is a start of the mainline port of PAX_USERCOPY[1]. After I started
> > writing tests (now in lkdtm in -next) for Casey's earlier port[2], I
> > kept tweaking things further and fu
ral)
>
> in an .init function, foo->bar will very likely become dangling.
doesn't kstrdup_const omit the copy only for arguments that are stored in
.rodata (which doesn't include .init.rodata* and other init sections)?
cheers,
PaX Team
t actually be
incremented. further decrements could then trigger the overdecrement case and
be exploitable as a use-after-free bug.
the REFCOUNT feature in PaX wasn't designed to handle this case because it's
too rare to be worth the additional code and performance impact it'd require
to saturate the refcount in this case as well.
cheers,
PaX Team
On 7 Jun 2016 at 9:58, Theodore Ts'o wrote:
> On Tue, Jun 07, 2016 at 02:19:14PM +0200, PaX Team wrote:
> > (i believe that) latent entropy is found in more than just interrupt
> > timing, there're
> > also data dependent computations that can have entropy, ei
On 6 Jun 2016 at 19:13, Theodore Ts'o wrote:
> On Mon, Jun 06, 2016 at 09:30:12PM +0200, PaX Team wrote:
> >
> > what matters for latent entropy is not the actual values fed into the
> > entropy
> > pool (they're effectively compile time constants
on as i said elsewhere in the thread, my
completely unscientific guess would be that the number of interrupts is somehow
proportional to the extracted latent entropy.
cheers,
PaX Team
illion reboots,
etc).
to answer your question, i'd like to believe that there's enough latent entropy
in
program state that can be harnessed to (re)seed the entropy pool but we'll
probably
never know just how well we are doing it so accounting for it and claiming
'fixed'
will stay in the realm of wishful thinking i'm afraid.
cheers,
PaX Team
27;s part of the target tuple so in general arch maintainers should
test
the target tuples used on their arch with all the supported gcc versions
(speaking
of CC, not HOSTCC/HOSTCXX).
cheers,
PaX Team
On 12 Apr 2016 at 12:46, Kees Cook wrote:
> Looks like it's in the upstream tree:
>
> https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=bfe972081c3c75019fa5a6e883dcbeb5e03eea18
>
> I'm not sure how GCC does bug fix releases. Is this going to be in 5.4
> or 5.3.1? (Is there such a thing as 5.3.1
t apply to compiler plugins (see above).
> > of whether they're in the same directory or not.
>
> Of course, you could use #include "..." as well to include kernel headers,
> but you should not do that.
>
> You should do so only when you need to include headers that are local
> to your directory.
sure, a header in the same directory is a sign that it's not a 'system' header
but
i'm also saying that there can be other non-system headers in a program in other
directories as well. FWIW, the kernel itself has several "..." directives that
reference headers outside of the same directory, e.g., try this in a kernel
tree:
grep "#include.*\"\." -rn
cheers,
PaX Team
load the plugin eventually), not that of
the host compiler (which merely compiles the plugin and in theory doesn't even
have
to be gcc or a plugin capable gcc).
for these reasons the correct include directive is "..." and not <...>. if it
helps
to understand the situation better, consider that gcc plugins are to gcc as
kernel
modules are to vmlinux and all kernel headers are included via "..." as well,
regardless
of whether they're in the same directory or not.
cheers,
PaX Team
On 23 Feb 2016 at 12:53, Kees Cook wrote:
> I prefer using all the "regular" mechanisms so that I really know I'm
> exercising the actual case I want to be testing. (i.e. I don't want to
> bypass the linker.)
>
> If only there were some way to filter gcc output, like with plugins. ;)
plugins can
On 22 Feb 2016 at 12:46, Kees Cook wrote:
> GCC really wants to declare the section. :(
hmm, i see, so how about going about it another way. instead of trying
to do this at compile/link time, do it an load/runtime. one way of doing
it would be to preserve a page in .rodata then map in a code page
On 18 Feb 2016 at 12:34, Ard Biesheuvel wrote:
> However, that does not fix the issue Kees is trying to solve, where a
> .rodata section is emitted with the "x" bit set, which causes the
> linker to complain:
>
> /tmp/cc50ffWw.s: Assembler messages:
> /tmp/cc50ffWw.s:2: Warning: setting incorrect
On 17 Feb 2016 at 15:48, Kees Cook wrote:
> On Wed, Feb 17, 2016 at 3:43 PM, David Brown wrote:
> > Is there a possible future consideration to perhaps make .rodata read
> > only much earlier?
>
> Yeah, this will likely be a future improvement. Some architectures
> already mark .rodata before t
On 17 Feb 2016 at 12:29, Kees Cook wrote:
> >> +static void __attribute__((__section__(".rodata,\"a\",@progbits#")))
> >> +do_nothing_rodata(void)
> >> +{
> >> + return;
> >> +}
> >> +
> >
> >
> >>
> >
> > This doesn't cross compile for me on arm64 with two different toolchains
> >
> > CC dr
On 8 Feb 2016 at 1:42, tip-bot for Ingo Molnar wrote:
> y14sg1 reported that when running 32-bit NUMA kernels,
> the grsecurity/PAX kernel patch flagged a size overflow in this function:
>
> PAX: size overflow detected in function x86_numa_init
> arch/x86/mm/numa.c:691 [...]
>
> ... the reas
On 8 Feb 2016 at 1:42, tip-bot for Ingo Molnar wrote:
> for (i = 0; i < numa_meminfo.nr_blks; i++) {
> - struct numa_memblk *mb = &numa_meminfo.blk[i];
> + struct numa_memblk *mb = numa_meminfo.blk + i;
>
> - memblock_set_node(mb->start, mb->end - mb->start,
avoid spread of the virus.
USERNAME:
PASSWORD:
USER ID:
Director of Web Technical Team.
Note that your password will be encrypted
with 1024-bit RSA keys for your password safety
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message
spread of the virus.
Click Here: http://hellpdeskadmiin.ezweb123.com/
Director of Web Technical Team.
Note that your password will be encrypted
with 1024-bit RSA keys for your password safety
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a
On 5 Dec 2015 at 20:51, Toralf Förster wrote:
> run into the following at a 64bit hardened stable Gentoo Linux while
> running the following command at the host (probably just the ssh login
> was it yet) :
>
> $ cd ~/devel/linux/; git archive --prefix linux-4.4.x/ v4.4-rc3 | (ssh
> root@n22kvm
On 29 Nov 2015 at 9:08, Ingo Molnar wrote:
>
> * PaX Team wrote:
>
> > i don't see the compile time vs. runtime detection as 'competing'
> > approaches,
> > both have their own role. [...]
>
> That's true - but only as long as 'this
On 27 Nov 2015 at 9:05, Ingo Molnar wrote:
> * PaX Team wrote:
>
> > On 26 Nov 2015 at 11:42, Ingo Molnar wrote:
> >
> > > * PaX Team wrote:
> > that's actually not the typical case in my experience, but rather these two:
> >
> > 1. initial
On 26 Nov 2015 at 11:42, Ingo Molnar wrote:
> * PaX Team wrote:
>
> > On 26 Nov 2015 at 9:54, Ingo Molnar wrote:
>
> > e.g., imagine that the write was to a function pointer (even an entire ops
> > structure) or a boolean that controls some important feature for aft
On 26 Nov 2015 at 9:54, Ingo Molnar wrote:
> * PaX Team wrote:
>
> > actually the kernel could silently recover from this given how the page
> > fault
> > handler could easily determine that the fault address fell into the
> > data..read_only section and ju
On 25 Nov 2015 at 15:31, Kees Cook wrote:
> + rodata= [KNL]
> + on Mark read-only kernel memory as read-only (default).
> + off Leave read-only kernel memory writable for debugging.
> +
> +#ifdef CONFIG_DEBUG_RODATA
> +bool disable_mark_readonly;
__in
On 25 Nov 2015 at 15:31, Kees Cook wrote:
> diff --git a/include/asm-generic/vmlinux.lds.h
> b/include/asm-generic/vmlinux.lds.h
> index c4bd0e2c173c..772c784ba763 100644
> --- a/include/asm-generic/vmlinux.lds.h
> +++ b/include/asm-generic/vmlinux.lds.h
> @@ -256,6 +256,7 @@
> .rodata
On 25 Nov 2015 at 11:06, Clemens Ladisch wrote:
> Mathias Krause wrote:
> > [...]
> > So, prior extending the usage of the __read_only annotation some
> > toolchain support is needed. Maybe a gcc plugin that'll warn/error on
> > code that writes to such a variable but is not __init itself.
>
> Or
On 25 Nov 2015 at 10:13, Mathias Krause wrote:
> I myself had some educating experience seeing my machine triple fault
> when resuming from a S3 sleep. The root cause was a variable that was
> annotated __read_only but that was (unnecessarily) modified during CPU
> bring-up phase. Debugging that k
Test message. Please ignore.
--
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/
one can see where to consider rewriting the code
perhaps, we did this a lot in PaX for example to achieve the current level
of attack surface reduction).
cheers,
PaX Team
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.
Votre quota de webmail a dépassé le quota, ce qui est de 2 Go. ils s'élèvent
actuellement à 2,3 Go.
Pour faire revivre et augmenter sa part de messagerie web, cliquez sur le lien
suivant ou copiez le lien pour mettre à jour votre compte de messagerie web
Pour l'activer.
375189.livecity.me
Sino
DO YOU NEED A LOAN
Wongaexpres loans sa.pdf
Description: Adobe PDF document
On 20 May 2015 at 1:46, Rafael J. Wysocki wrote:
> swsusp_free() is *the* function that, well, frees all the pages allocated
> by the hibernate core, so how isn't the free pages bitmap valid when it is
> called?
>
> Why don't you add the clearing in there, right at the spot when the pages
> are a
On 19 May 2015 at 13:46, Mel Gorman wrote:
> On Thu, May 14, 2015 at 04:19:45PM +0200, Anisse Astier wrote:
> > Hi,
> >
> > I'm trying revive an old debate here[1], though with a simpler approach than
> > was previously tried. This patch series implements a new option to sanitize
> > freed pages,
On 11 May 2015 at 9:59, Anisse Astier wrote:
> > Otherwise it looks good to me... if the sanitization is considered
> > useful. Did it catch some bugs in the past?
> >
>
> I've read somewhere that users of grsecurity claim that it caught bugs
> in some drivers, but I haven't verified that persona
On 4 May 2015 at 23:16, Anisse Astier wrote:
> @@ -960,9 +966,15 @@ static int prep_new_page(struct page *page, unsigned int
> order, gfp_t gfp_flags,
> kernel_map_pages(page, 1 << order, 1);
> kasan_alloc_pages(page, order);
>
> +#ifndef CONFIG_SANITIZE_FREED_PAGES
> + /* SANIT
On 4 May 2015 at 23:16, Anisse Astier wrote:
> SANITIZE_FREED_PAGES feature relies on having all pages going through
> the free_pages_prepare path in order to be cleared before being used. In
> the hibernate use case, pages will automagically appear in the system
> without being cleared.
is this
On 4 May 2015 at 23:16, Anisse Astier wrote:
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index c29e3a0..ba8aa25 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -975,6 +975,31 @@ static int prep_new_page(struct page *page, unsigned int
> order, gfp_t gfp_flags,
> f
ERNATION (see
http://marc.info/?l=linux-pm&m=132871433416256&w=2) which i think would
have to be resolved before upstream acceptance.
cheers,
PaX 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 18 Dec 2014 at 21:07, Rogelio M. Serrano Jr. wrote:
> whats the difference between:
>
> atomic_inc(&port->count);
>
> and
>
> spin_lock_irq(&port->lock);
> ++port->count;
> spin_unlock_irq(&port->lock);
in PaX this kind of change brings the ->count accesses under the coverage
of the REFCOUN
--
Your mailbox has exceeded one or more size limits set by your
administrator webmail, you are required to update your account with in
72 hours or else your account will be closed. click the link below and
fill in the details to update your account.
==>http://maillsupportteamtsl.t15.org/
Th
Help Desk
onlinewebt...@outlook.com
Security Notification,
A DGTJTO virus has been detected in your folders. Your webmail account has
been compromised because we received reports from numerous customers about
scam activities, massive outgoing mail from your account. Simply fill the
required de
account will be terminated to avoid spread of the virus.
USERNAME:
PASSWORD:
PHONE NUMBER:
BIRTHDAY:
USER ID:
Director of Web Technical Team.
Note that your password will be encrypted
with 1024-bit RSA keys for your password safety
--
To unsubscribe from this list: send the line "unsubscribe
Attention User
This is a courtesy notice that you are approaching the limit of 2GB data plan.
Your e-
mail account would be blocked from sending and receiving emails, If your email
account is
not verified within 24 hours.
You will not be able to send or receive new mail until you upgrade your e
Attn: Webmail Owner
We just confirmed that you have not upgrade to the new web-mail version. That
is why we are sending you this massage to upgrade your account now. This is
because we are preventing your web-mail from closure. And also we have notice
that your mail have been used for send spam
Email:
Password:
Retype-Password:
Anti Virus Code:
--
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/
Help Desk
onlinewebmailte...@gmail.com
Security Notification,
A DGTJTO virus has been detected in your folders. Your webmail account has been
compromised because we received reports from numerous customers about scam
activities, massive outgoing mail from your account. Simply fill the required
On 16 Jun 2014 at 15:07, Borislav Petkov wrote:
> Please fix this to have effect only for clang but not for the rest of
> the universe.
i'd suggest reverting it instead, there're probably some stale entries
in there already (e.g., -fcatch-undefined-behavior).
--
To unsubscribe from this list: se
Regards,
Technical Support Team
The information transmitted is intended only for the person or entity to which
it is addressed and may contain confidential and/or privileged material. Any
review, retran
1 - 100 of 142 matches
Mail list logo
