On 04/04/2013 11:16 AM, Jakub Jelinek wrote:
On Thu, Apr 04, 2013 at 10:59:41AM +0200, Florian Weimer wrote:
On 04/04/2013 10:42 AM, Jakub Jelinek wrote:
I think a similar optimization would be possible for access to
global variables because ld could compute the final layout of all
global
On 05/17/2013 07:17 AM, Ben Boeckel wrote:
While we're dredging up old threads ;) .
On Fri, 10 May, 2013 at 12:29:16 GMT, Florian Weimer wrote:
There is some fairly horrible stuff, like std::copy:
http://en.cppreference.com/w/cpp/algorithm/copy
You can pass a std::vectorT::iterator (say, the
Perhaps is not working because most of the new policy are deployed in
enforcing mode and not in permissive ? But permissive not was born
exactly for this ?
Best
2013/4/23, Kevin Kofler kevin.kof...@chello.at:
Adam Williamson wrote:
SELinux keeps having bugs *because* they progressively build
While we're dredging up old threads ;) .
On Fri, 10 May, 2013 at 12:29:16 GMT, Florian Weimer wrote:
There is some fairly horrible stuff, like std::copy:
http://en.cppreference.com/w/cpp/algorithm/copy
You can pass a std::vectorT::iterator (say, the result of begin()) as
the output
On 04/23/2013 11:36 PM, Kevin Kofler wrote:
Moving from C/C++ to a slower language is neither helpful nor necessary. If
you really want full bound checking, it can be added to C/C++ rather than
moving to a completely different language, and you'd still get the other
benefits of C/C++, in
On 04/14/2013 03:34 AM, Steve Grubb wrote:
-fstack-protector-all really is all. The default in Fedora is 4 bytes which
would cover cases where ints and char[] are interposed as in some networking
code. But more importantly, the defaul stack-protector only kicks in when the
object is a char
Steve Grubb wrote:
On Monday, April 15, 2013 09:12:57 AM Richard W.M. Jones wrote:
which I interpret to mean that after using -fstack-protector-all and
removing prelink, SELinux would become obsolete because no executable
can be exploited.
I would say there is a place for SE Linux even if we
Przemek Klosowski wrote:
I agree that it's tedious, but practical evidence seems to suggest that
it's a converging process and we're almost there---'enforcing' SELinux
is a viable setting for a majority of deployments.
I fail to see any kind of convergence. We still have weekly selinux-policy
Adam Williamson wrote:
SELinux keeps having bugs *because* they progressively build out the
policies. The coverage of the -targeted policy is now greater than it
was a few releases back. If they kept the coverage of the stock policies
the same over time there would be almost no new bugs, but
On Tue, 23 Apr 2013 22:35:41 +0200
Kevin Kofler kevin.kof...@chello.at wrote:
It isn't working because it's adding hundreds of new policy bugs in
every new Fedora release.
citation needed
Seriously, can you please stop extrapolating from your personal
usecase, and think of both the developers
Richard W.M. Jones wrote:
We also suffer this problem in reverse: passing a pointer between two
C libraries is not possible in another non-C language. eg. Passing a
libvirt virDomainPtr from (Perl) Sys::Virt to Sys::Guestfs.
Well, if the language supports sufficiently large integers and runs
Miloslav Trmač wrote:
The logical conclusion from this is to move to a language with automatic
memory management. The top vulnerability reports for programs written
in C/C++ and most other languages so different that starting a new project
that processes untrusted data in C/C++ is becoming
On Tue, 16 Apr 2013 14:05:39 +0200
Florian Weimer fwei...@redhat.com wrote:
On 04/15/2013 08:17 PM, Miloslav Trmač wrote:
Sure, moving away from C/C++ does not make programs
completely secure; however, on average, C/C++ programs
are noticeably less secure (because most vulnerabilities
On Thu, Apr 18, 2013 at 01:14:33AM +0200, Björn Persson wrote:
[...]
Passing pointers to objects from one language to another is likely
*not* possible however.
Ada imports and exports C pointers just fine, including pointers to
functions and records.
I should have been clearer. I meant
Once upon a time, Richard W.M. Jones rjo...@redhat.com said:
I should have been clearer. I meant passing pointers between non-C
languages is likely not possible.
Well, it depends on the language, but it is probably possible with some
glue code (not necessarily practical though). For example,
On Thu, Apr 18, 2013 at 10:39:43AM -0500, Chris Adams wrote:
Once upon a time, Richard W.M. Jones rjo...@redhat.com said:
We also suffer this problem in reverse: passing a pointer between two
C libraries is not possible in another non-C language. eg. Passing a
libvirt virDomainPtr from
Richard W.M. Jones wrote:
On Thu, Apr 18, 2013 at 01:14:33AM +0200, Björn Persson wrote:
[...]
Passing pointers to objects from one language to another is likely
*not* possible however.
Ada imports and exports C pointers just fine, including pointers to
functions and records.
I
Once upon a time, Richard W.M. Jones rjo...@redhat.com said:
I shouldn't say not possible, but not very easy. A virDomainPtr in
Sys::Virt is wrapped in some object which is very specific to the
internals of Sys::Virt, thus cannot be extracted by Sys::Guestfs. It
would require Sys::Virt to
Whatever you think. But it means you can't just write:
$dom = Sys::Virt-get_domain_by_name (foo);
$g = Sys::Guestfs-create ();
$g-add_libvirt_domain ($dom);
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
virt-top is 'top' for virtual machines.
Once upon a time, Richard W.M. Jones rjo...@redhat.com said:
Whatever you think. But it means you can't just write:
$dom = Sys::Virt-get_domain_by_name (foo);
$g = Sys::Guestfs-create ();
$g-add_libvirt_domain ($dom);
And that has nothing to do with what you said, languages being
On Wed, Apr 17, 2013 at 1:16 AM, Adam Williamson awill...@redhat.comwrote:
On 15/04/13 09:48 AM, Miloslav Trmač wrote:
The logical conclusion from this is to move to a language with automatic
memory management. The top vulnerability reports for programs written
in C/C++ and most other
Richard W.M. Jones wrote:
On Tue, Apr 16, 2013 at 03:12:38PM +0200, Miloslav Trmač wrote:
On Mon, Apr 15, 2013 at 11:19 PM, Richard W.M. Jones
rjo...@redhat.comwrote:
On Mon, Apr 15, 2013 at 06:48:32PM +0200, Miloslav Trmač wrote:
Now, what to move to? I currently don't have see
On Mon, Apr 15, 2013 at 11:19 PM, Richard W.M. Jones rjo...@redhat.comwrote:
On Mon, Apr 15, 2013 at 06:48:32PM +0200, Miloslav Trmač wrote:
Now, what to move to? I currently don't have see any language/runtime I
could recommend, which is in itself rather frightening.
Ada, Eiffel, Go, Coq
On 04/15/2013 08:17 PM, Miloslav Trmač wrote:
Sure, moving away from C/C++ does not make programs completely secure;
however, on average, C/C++ programs are noticeably less secure (because
most vulnerabilities that can happen in higher-level languages can also
happen in C, but not the other way
On Tue, Apr 16, 2013 at 03:12:38PM +0200, Miloslav Trmač wrote:
On Mon, Apr 15, 2013 at 11:19 PM, Richard W.M. Jones rjo...@redhat.comwrote:
On Mon, Apr 15, 2013 at 06:48:32PM +0200, Miloslav Trmač wrote:
Now, what to move to? I currently don't have see any language/runtime I
could
On 15/04/13 10:10 -0400, Steve Grubb wrote:
I would say there is a place for SE Linux even if we compiled everything with
all because FORTIFY_SOURCE coverage is not absolute. For example, about a
month ago i ran the following test:
procs=`ls /proc | grep '^[0-9]' | sort -n`
for p in
On 15/04/13 09:48 AM, Miloslav Trmač wrote:
On Sat, Apr 13, 2013 at 7:51 PM, Reindl Harald h.rei...@thelounge.net
mailto:h.rei...@thelounge.net wrote:
which raises the question again:
would it be not the better way to build the whole distribution hardened
by expierience that nearly
On 13/04/13 11:36 AM, Kevin Kofler wrote:
And I would argue that this amounts to second-guessing/duplicating what the
program tries to do in an unmaintainable morass of rules, which even for the
targeted policy (which is not even close to covering all programs in Fedora
other than as
On 04/05/13 at 04:16pm, Jakub Jelinek wrote:
On Fri, Apr 05, 2013 at 07:31:55PM +0530, Dhiru Kholia wrote:
I repeated the benchmarks (mentioned in the above bug report) for
Firefox 20.0 running on Fedora 18 64-bit.
Firefox as benchmark doesn't look like a good idea (and I'm really surprised
On Sun, Apr 14, 2013 at 01:43:05AM +0200, Kevin Kofler wrote:
I repeat: The proper solution is to prevent executing any machine code which
is not part of the program's source code.
You're simply wrong about this. It's trivial to come up with a
counter-example, if you're prepared to give it a
On Sun, Apr 14, 2013 at 01:43:05AM +0200, Kevin Kofler wrote:
Richard W.M. Jones wrote:
I said it doesn't implement full bounds checking for every C object,
and I stand by that. I doesn't cover stack objects smaller than some
cut-off size, nor any objects in static data or on the heap at
On Monday, April 15, 2013 09:12:57 AM Richard W.M. Jones wrote:
which I interpret to mean that after using -fstack-protector-all and
removing prelink, SELinux would become obsolete because no executable
can be exploited.
I would say there is a place for SE Linux even if we compiled everything
On Mon, 2013-04-15 at 09:12 +0100, Richard W.M. Jones wrote:
which I interpret to mean that after using -fstack-protector-all and
removing prelink, SELinux would become obsolete because no executable
can be exploited.
No; there are plenty of exploits which aren't due to buffer overflows.
On Sat, Apr 13, 2013 at 7:51 PM, Reindl Harald h.rei...@thelounge.netwrote:
which raises the question again:
would it be not the better way to build the whole distribution hardened
by expierience that nearly anything is exploitable over the long and
performance comes after security
The
On 04/13/2013 07:43 PM, Kevin Kofler wrote:
Richard W.M. Jones wrote:
This would be excellent, and projects in this area could make a
significant contribution. I suspect that any general code-to-policy
translator will hit the Halting Problem, since it seems trivial to
write a program which
Am 15.04.2013 18:48, schrieb Miloslav Trmač:
On Sat, Apr 13, 2013 at 7:51 PM, Reindl Harald h.rei...@thelounge.net
mailto:h.rei...@thelounge.net wrote:
which raises the question again:
would it be not the better way to build the whole distribution hardened
by expierience
On Mon, Apr 15, 2013 at 7:40 PM, Reindl Harald h.rei...@thelounge.netwrote:
Am 15.04.2013 18:48, schrieb Miloslav Trmač:
On Sat, Apr 13, 2013 at 7:51 PM, Reindl Harald
h.rei...@thelounge.netmailto:
h.rei...@thelounge.net wrote:
which raises the question again:
would it be
Miloslav Trmač wrote:
The logical conclusion from this is to move to a language with automatic
memory management. The top vulnerability reports for programs written in
C/C++ and most other languages so different that starting a new project
that processes untrusted data in C/C++ is becoming
On Mon, 2013-04-15 at 20:17 +0200, Miloslav Trmač wrote:
On Mon, Apr 15, 2013 at 7:40 PM, Reindl Harald
h.rei...@thelounge.net wrote:
Am 15.04.2013 18:48, schrieb Miloslav Trmač:
On Sat, Apr 13, 2013 at 7:51 PM, Reindl Harald
h.rei...@thelounge.net
From: les hlhow...@pacbell.net
Maybe I'm wrong, but given that I won't likely be around by the time
these newer languages have become senior, I won't see my statement
refuted.
You needn't wait long. Ada has been around for three some decades
already. ;-)
--
John Florian
--
devel
On Mon, Apr 15, 2013 at 06:48:32PM +0200, Miloslav Trmač wrote:
Now, what to move to? I currently don't have see any language/runtime I
could recommend, which is in itself rather frightening.
Ada, Eiffel, Go, Coq + OCaml, Erlang, Haskell, CompCert[*], etc. etc.
All these languages are viable.
les wrote:
I do not believe that C or C++ are
inherently less secure than other languages, nor do I believe that there
is some statistical way of proving that fact. One can write good or bad
code in all languages.
I believe you are wrong. Some languages are more secure than other
languages.
Le dimanche 14 avril 2013 à 01:43 +0200, Kevin Kofler a écrit :
Richard W.M. Jones wrote:
This would be excellent, and projects in this area could make a
significant contribution. I suspect that any general code-to-policy
translator will hit the Halting Problem, since it seems trivial to
Steve Grubb wrote:
On Saturday, April 13, 2013 08:36:53 PM Kevin Kofler wrote:
But it prevents (with probability (256^n-1)/256^n, where n is the size of
the canary in bytes, which for n=4 is approximately .976717)
exploiting the overflows to change the return address of any C
On Wednesday, April 10, 2013 03:55:46 PM Miloslav Trmač wrote:
Hello all,
the discussion has somewhat died down... If you have a specific proposal
for a change in policy, please add it to
https://fedorahosted.org/fesco/ticket/1104 ; hard data that demonstrate the
impact, if any, in a
On Friday, April 12, 2013 06:44:33 AM Josh Bressers wrote:
On Thu, Apr 11, 2013 at 12:54 PM, Reindl Harald h.rei...@thelounge.net
wrote:
which is exactly the goal ASLR is desigend for
It's designed to make certain types of attacks more difficult. It
doesn't make them impossible, just much
On Sat, Apr 13, 2013 at 11:33 AM, Steve Grubb wrote:
I don't think there is any need to extend the set of packages that _should_
get hardening. The current guidelines are sufficient. What is not
happening is
the packages that have apps that fit the need to be hardened are not
getting
the
On Saturday, April 13, 2013 12:19:42 PM Rahul Sundaram wrote:
On Sat, Apr 13, 2013 at 11:33 AM, Steve Grubb wrote:
I don't think there is any need to extend the set of packages that
_should_
get hardening. The current guidelines are sufficient. What is not
happening is
the packages that
Am 13.04.2013 19:46, schrieb Steve Grubb:
http://people.redhat.com/sgrubb/files/rpm-chksec
To check a typical install and only get the packages that do not meet policy,
./rpm-chksec --all | sed -r s/\x1B\[([0-9]{1,2}(;[0-9]{1,2})?)?[m|K]//g |
egrep -w 'no|PACKAGE'
A small sample on
On Sat, Apr 13, 2013 at 11:46 AM, Steve Grubb sgr...@redhat.com wrote:
I have not run the script that checks a distribution on F19 yet, so maybe
there are more?
http://people.redhat.com/sgrubb/files/rpm-chksec
That script reports all .o files (yes, those are sometimes packaged)
as exec no no,
Richard W.M. Jones wrote:
(1) -fstack-protector{,-all} doesn't implement full bounds checking
for every C object.
But it prevents (with probability (256^n-1)/256^n, where n is the size of
the canary in bytes, which for n=4 is approximately .976717)
exploiting the overflows to change
On Sat, Apr 13, 2013 at 11:16 PM, Steve Grubb sgr...@redhat.com wrote:
On Saturday, April 13, 2013 12:19:42 PM Rahul Sundaram wrote:
Is there a tracker bug? Proven packagers can help
I have a tracker bug for issues identified on the core set of packages that
would be part of a common
On Sun, Apr 14, 2013 at 12:26 AM, Dhiru Kholia dhiru.kho...@gmail.com wrote:
On Sat, Apr 13, 2013 at 11:16 PM, Steve Grubb sgr...@redhat.com wrote:
On Saturday, April 13, 2013 12:19:42 PM Rahul Sundaram wrote:
Is there a tracker bug? Proven packagers can help
I have a tracker bug for issues
On Sat, Apr 13, 2013 at 08:36:53PM +0200, Kevin Kofler wrote:
Richard W.M. Jones wrote:
(1) -fstack-protector{,-all} doesn't implement full bounds checking
for every C object.
But it prevents (with probability (256^n-1)/256^n, where n is the size of
the canary in bytes, which for n=4 is
Richard W.M. Jones wrote:
I said it doesn't implement full bounds checking for every C object,
and I stand by that. I doesn't cover stack objects smaller than some
cut-off size, nor any objects in static data or on the heap at all.
I never claimed it did. I said it prevents overwriting the
On Saturday, April 13, 2013 08:44:44 PM Richard W.M. Jones wrote:
On Sat, Apr 13, 2013 at 08:36:53PM +0200, Kevin Kofler wrote:
Richard W.M. Jones wrote:
(1) -fstack-protector{,-all} doesn't implement full bounds checking
for every C object.
But it prevents (with probability
On Saturday, April 13, 2013 12:28:04 PM Jerry James wrote:
I have not run the script that checks a distribution on F19 yet, so maybe
there are more?
http://people.redhat.com/sgrubb/files/rpm-chksec
That script reports all .o files (yes, those are sometimes packaged)
as exec no no,
On Saturday, April 13, 2013 08:36:53 PM Kevin Kofler wrote:
(1) -fstack-protector{,-all} doesn't implement full bounds checking
for every C object.
But it prevents (with probability (256^n-1)/256^n, where n is the size of
the canary in bytes, which for n=4 is approximately
On Thu, Apr 11, 2013 at 12:54 PM, Reindl Harald h.rei...@thelounge.net wrote:
which is exactly the goal ASLR is desigend for
It's designed to make certain types of attacks more difficult. It
doesn't make them impossible, just much harder.
Here is an example.
When you write a security
On Thu, Apr 11, 2013 at 7:19 PM, Richard W.M. Jones rjo...@redhat.comwrote:
On Thu, Apr 11, 2013 at 05:19:46PM +0200, Miloslav Trmač wrote:
With the current setup, we get mutating ASLR when compiled as PIE,
Surely ... you get mutating ASLR only when compiled as PIE
*and* the server process
Am 12.04.2013 13:44, schrieb Josh Bressers:
On Thu, Apr 11, 2013 at 12:54 PM, Reindl Harald h.rei...@thelounge.net
wrote:
which is exactly the goal ASLR is desigend for
It's designed to make certain types of attacks more difficult. It
doesn't make them impossible, just much harder.
Some more thoughts on possibly hardening more by default - comments and
corrections very welcome.
(I'll call mutating ASLR a setup where the addresses change frequently,
and static ASLR a setup where the addresses change only sometimes but
differ between systems.)
* Servers that accept outside
On 04/11/2013 08:19 AM, Miloslav Trmač wrote:
(I'll call mutating ASLR a setup where the addresses change frequently,
and static ASLR a setup where the addresses change only sometimes
but differ between systems.)
* Servers that accept outside connections definitely should have mutating
On Thu, Apr 11, 2013 at 6:32 PM, John Reiser jrei...@bitwagon.com wrote:
On 04/11/2013 08:19 AM, Miloslav Trmač wrote:
(I'll call mutating ASLR a setup where the addresses change frequently,
and static ASLR a setup where the addresses change only sometimes
but differ between systems.)
On Thu, Apr 11, 2013 at 05:19:46PM +0200, Miloslav Trmač wrote:
With the current setup, we get mutating ASLR when compiled as PIE,
Surely ... you get mutating ASLR only when compiled as PIE
*and* the server process restarts itself between each connection or at
least on a regular basis (ie. it's
Richard W.M. Jones wrote:
On Thu, Apr 11, 2013 at 05:19:46PM +0200, Miloslav Trmač wrote:
With the current setup, we get mutating ASLR when compiled as PIE,
Surely ... you get mutating ASLR only when compiled as PIE
*and* the server process restarts itself between each connection or at
Am 11.04.2013 19:52, schrieb Björn Persson:
Richard W.M. Jones wrote:
On Thu, Apr 11, 2013 at 05:19:46PM +0200, Miloslav Trmač wrote:
With the current setup, we get mutating ASLR when compiled as PIE,
Surely ... you get mutating ASLR only when compiled as PIE
*and* the server process
Hello all,
the discussion has somewhat died down... If you have a specific proposal
for a change in policy, please add it to
https://fedorahosted.org/fesco/ticket/1104 ; hard data that demonstrate the
impact, if any, in a situation relevant to Fedora (in particular, taking
into account prelink as
On 04/04/13 at 09:26am, Steve Grubb wrote:
On Wednesday, April 03, 2013 09:05:18 PM Josh Bressers wrote:
On Wed, Apr 3, 2013 at 2:05 PM, Steve Grubb sgr...@redhat.com wrote:
How much does it (PIE) slow things down? I'm fairly certain you don't have
any
good data on this point. Dhiru is
On Fri, Apr 05, 2013 at 07:31:55PM +0530, Dhiru Kholia wrote:
On 04/04/13 at 09:26am, Steve Grubb wrote:
On Wednesday, April 03, 2013 09:05:18 PM Josh Bressers wrote:
On Wed, Apr 3, 2013 at 2:05 PM, Steve Grubb sgr...@redhat.com wrote:
How much does it (PIE) slow things down? I'm fairly
Il 29/03/2013 23:10, Richard W.M. Jones ha scritto:
Qemu is surely a good candidate for this. Although it's not network-
accessible, it is accessible from the guests that it runs via its huge
and ill-specified surface of emulated devices.
I'm running my own modified qemu package
Il 04/04/2013 04:05, Josh Bressers ha scritto:
On Wed, Apr 3, 2013 at 2:05 PM, Steve Grubb sgr...@redhat.com
mailto:sgr...@redhat.com wrote:
On Wednesday, April 03, 2013 01:48:17 PM Miloslav Trmač wrote:
On Tue, Apr 2, 2013 at 9:57 PM, Steve Grubb sgr...@redhat.com
On Thu, Apr 04, 2013 at 09:39:18AM +0200, Paolo Bonzini wrote:
I'm willing to agree that PIE on x86 is going to be very slow due to
register pressure.
Yes, but not on x86-64 which has %rip-relative addressing. It is
probably a wash there.
It isn't, while the register pressure doesn't
On 04/04/2013 09:47 AM, Jakub Jelinek wrote:
On Thu, Apr 04, 2013 at 09:39:18AM +0200, Paolo Bonzini wrote:
I'm willing to agree that PIE on x86 is going to be very slow due to
register pressure.
Yes, but not on x86-64 which has %rip-relative addressing. It is
probably a wash there.
On
On Thu, Apr 04, 2013 at 10:27:31AM +0200, Florian Weimer wrote:
On 04/04/2013 09:47 AM, Jakub Jelinek wrote:
On Thu, Apr 04, 2013 at 09:39:18AM +0200, Paolo Bonzini wrote:
I'm willing to agree that PIE on x86 is going to be very slow due to
register pressure.
Yes, but not on x86-64 which
On 04/04/2013 10:42 AM, Jakub Jelinek wrote:
I think a similar optimization would be possible for access to
global variables because ld could compute the final layout of all
global variables in the binary itself, just as in the non-PIE case.
Nope. The thing is, depending on if the variable is
On Thu, Apr 04, 2013 at 10:59:41AM +0200, Florian Weimer wrote:
On 04/04/2013 10:42 AM, Jakub Jelinek wrote:
I think a similar optimization would be possible for access to
global variables because ld could compute the final layout of all
global variables in the binary itself, just as in the
On Wednesday, April 03, 2013 09:05:18 PM Josh Bressers wrote:
On Wed, Apr 3, 2013 at 2:05 PM, Steve Grubb sgr...@redhat.com wrote:
On Wednesday, April 03, 2013 01:48:17 PM Miloslav Trmač wrote:
On Tue, Apr 2, 2013 at 9:57 PM, Steve Grubb sgr...@redhat.com wrote:
On Saturday, March 30,
On Thu, Apr 04, 2013 at 09:26:34AM -0400, Steve Grubb wrote:
Last week I was looking at nspr and wondering why fortify_source was not
getting used and found that it wrapped functions for portability. For
example, it has PL_strcpy which only wraps strcpy. The problem is the size
information
On Tue, Apr 02, 2013 at 05:14:21PM -0600, Stephen Smoogen wrote:
At this point I have the feeling that Prelink is a cargo cult which
we keep around to appease the Airplane Gods.
Well, when I brought this up four years ago, we kept it around to appease
the GCC development gods. (Or, at least,
On Thu, Apr 04, 2013 at 10:05:31AM -0400, Matthew Miller wrote:
Well, when I brought this up four years ago, we kept it around to appease
the GCC development gods. (Or, at least, Jakub Jelinek.)
(In case it wasn't clear, I didn't mean this to be a jab or sarcastic remark
in any way; after
Jakub Jelinek (ja...@redhat.com) said:
On Wed, Apr 03, 2013 at 01:53:27AM +0200, Reindl Harald wrote:
A prelinked module reduces time spent in ld-linux, and increases sharing
of pages (which reduces time spent in kernel duplicating copy-on-write
pages.)
The savings are *visible*
Am 04.04.2013 20:54, schrieb Bill Nottingham:
Jakub Jelinek (ja...@redhat.com) said:
On Wed, Apr 03, 2013 at 01:53:27AM +0200, Reindl Harald wrote:
A prelinked module reduces time spent in ld-linux, and increases sharing
of pages (which reduces time spent in kernel duplicating copy-on-write
On Wed, Apr 03, 2013 at 01:53:27AM +0200, Reindl Harald wrote:
A prelinked module reduces time spent in ld-linux, and increases sharing
of pages (which reduces time spent in kernel duplicating copy-on-write
pages.)
The savings are *visible* when invoking an interactive GUI program that
On Wed, Apr 3, 2013 at 12:18 AM, Adam Williamson awill...@redhat.comwrote:
On 31/03/13 08:11 AM, Richard W.M. Jones wrote:
However prelink does reduce the effectiveness of ASLR (a bit). See
http://lwn.net/Articles/**341440/ http://lwn.net/Articles/341440/ and
follow-up conversation.
On Tue, Apr 2, 2013 at 9:57 PM, Steve Grubb sgr...@redhat.com wrote:
On Saturday, March 30, 2013 08:54:30 AM Dhiru Kholia wrote:
_hardened_build rpm spec macro can be used to harden a package.
For an example, see
http://pkgs.fedoraproject.org/cgit/clamav.git/tree/clamav.spec
This flag
Jakub Jelinek ja...@redhat.com writes:
If you don't care about the speed of execution of any programs, just compile
everything with -fsanitize=address (that will be only ~ 2x slowdown or so).
A different issue that worries me about PIE is the impact on the
available address space in 32-bit
On Wed, 3 Apr 2013, Miloslav Trmač wrote:
On Wed, Apr 3, 2013 at 12:18 AM, Adam Williamson awill...@redhat.com wrote:
On 31/03/13 08:11 AM, Richard W.M. Jones wrote:
However prelink does reduce the effectiveness of ASLR (a bit). See
Am 03.04.2013 01:59, schrieb Kevin Fenzi:
On Tue, 02 Apr 2013 16:50:33 -0700
John Reiser jrei...@bitwagon.com wrote:
It does rather seem like we should consider just killing it
[prelink], at least by default.
Prelinking shortens the time between execve() and first useful output.
A
This proposal was originally at https://fedorahosted.org/fesco/ticket/1104
http://fedoraproject.org/wiki/Hardened_Packages page mentions
that FESCo requires some packages to use PIE and relro hardening by
default.
Position independent executables use a weak form of ASLR on
On Wed, Apr 3, 2013 at 5:19 PM, Paul Wouters pwout...@redhat.com wrote:
To me, prelink is still evil for breaking FIPS. I've requested a few times
that prelink plays nicer with FIPS mode, like running prelink -ua during
bootup when FIPS mode is on.
On 04/03/2013 05:38 AM, Tom Lane wrote:
A different issue that worries me about PIE is the impact on the
available address space in 32-bit builds
A test program says that the unused space is bounded by 1MiB per module
(main program or shared library) and in a 32-bit environment the
placement is
On Wednesday, April 03, 2013 01:48:17 PM Miloslav Trmač wrote:
On Tue, Apr 2, 2013 at 9:57 PM, Steve Grubb sgr...@redhat.com wrote:
On Saturday, March 30, 2013 08:54:30 AM Dhiru Kholia wrote:
_hardened_build rpm spec macro can be used to harden a package.
For an example, see
On Wed, Apr 3, 2013 at 2:05 PM, Steve Grubb sgr...@redhat.com wrote:
On Wednesday, April 03, 2013 01:48:17 PM Miloslav Trmač wrote:
On Tue, Apr 2, 2013 at 9:57 PM, Steve Grubb sgr...@redhat.com wrote:
On Saturday, March 30, 2013 08:54:30 AM Dhiru Kholia wrote:
_hardened_build rpm spec
On 04/02/13 at 03:04pm, Richard W.M. Jones wrote:
On Tue, Apr 02, 2013 at 07:15:29PM +0530, Dhiru Kholia wrote:
http://dl.dropbox.com/u/1522424/probable-violations-F19.csv
FWIW, the following command produces much better output:
snipped
like this:
Package: autodir
John Reiser jrei...@bitwagon.com wrote:
It's also easy to see the mechanism:
$ cat foo.c
extern int a[];
void foo(int j) { a[j]=j; }
$ gcc -m32 -fPIE -O -S foo.c
$ cat foo.s # edited for brevity
foo: # 25 bytes; about 15 cycles (incl. 3*3 cycles data cache fetch latency)
call
On 04/01/13 at 03:05pm, Dhiru Kholia wrote:
On 04/01/13 at 10:23am, Michael Scherer wrote:
Le lundi 01 avril 2013 à 12:29 +0530, Dhiru Kholia a écrit :
It would be great to have some sort of automated method to find if
hardening criteria applies to a particular package. Ideas are welcome!
On Tue, Apr 02, 2013 at 05:51:42PM +0530, Dhiru Kholia wrote:
http://dl.dropbox.com/u/1522424/probable-violations-F19.xls
That shows:
D0CF^QU+0871^ZE1^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^C^@FEFF
On Tue, Apr 2, 2013 at 6:36 PM, Richard W.M. Jones rjo...@redhat.com wrote:
On Tue, Apr 02, 2013 at 05:51:42PM +0530, Dhiru Kholia wrote:
http://dl.dropbox.com/u/1522424/probable-violations-F19.xls
That shows:
garbage
Can you use a non-proprietary format please.
Can you try wget
On Tue, Apr 2, 2013 at 6:36 PM, Richard W.M. Jones rjo...@redhat.com wrote:
On Tue, Apr 02, 2013 at 05:51:42PM +0530, Dhiru Kholia wrote:
http://dl.dropbox.com/u/1522424/probable-violations-F19.xls
That shows:
garbage
Can you use a non-proprietary format please.
1 - 100 of 131 matches
Mail list logo
