On Fri, Oct 4, 2013 at 5:53 PM, Richard Weinberger wrote:
> Am 04.10.2013 12:53, schrieb Dmitry Vyukov:
>> On Fri, Oct 4, 2013 at 2:38 PM, Richard Weinberger
>> wrote:
>>> ...
>>> [1] yes, yes, I know - the mere mention of security should've prevented
>>> such
>>> arrogant reques
On Fri, Oct 11, 2013 at 3:26 PM, Dmitry Vyukov wrote:
> On Fri, Oct 4, 2013 at 5:53 PM, Richard Weinberger wrote:
>> Am 04.10.2013 12:53, schrieb Dmitry Vyukov:
>>> On Fri, Oct 4, 2013 at 2:38 PM, Richard Weinberger
>>> wrote:
...
[1] yes, yes, I know - the mere mention of secu
Am 04.10.2013 12:53, schrieb Dmitry Vyukov:
> On Fri, Oct 4, 2013 at 2:38 PM, Richard Weinberger
> wrote:
>> ...
>> [1] yes, yes, I know - the mere mention of security should've prevented
>> such
>> arrogant requests. It's an imperfect universe.
>
> I want to attempt to d
On Fri, Oct 4, 2013 at 2:38 PM, Richard Weinberger
wrote:
> ...
> [1] yes, yes, I know - the mere mention of security should've prevented
> such
> arrogant requests. It's an imperfect universe.
I want to attempt to disassemble what you've communicating here:
>>
On Fri, Oct 4, 2013 at 8:05 AM, Dmitry Vyukov wrote:
> On Fri, Oct 4, 2013 at 12:57 AM, Al Viro wrote:
>> On Thu, Oct 03, 2013 at 12:36:08PM -0700, Kees Cook wrote:
>>> > Kees, try to think for a minute[1]. Really. We have general-purpose
>>> > ...
>>> > [1] yes, yes, I know - the mere mention
On Fri, Oct 4, 2013 at 12:57 AM, Al Viro wrote:
> On Thu, Oct 03, 2013 at 12:36:08PM -0700, Kees Cook wrote:
>> > Kees, try to think for a minute[1]. Really. We have general-purpose
>> > ...
>> > [1] yes, yes, I know - the mere mention of security should've prevented
>> > such
>> > arrogant req
On Thu, Oct 3, 2013 at 1:57 PM, Al Viro wrote:
> Let n be some integer between 32 and 4096 and N be equal to n rounded up
> to word size. If kmalloc(n) returns a pointer such that fetch from
> (char *)p[N - 1] triggers an exception, we have a badly broken kernel.
Sure, this is certainly true giv
On Thu, Oct 03, 2013 at 12:36:08PM -0700, Kees Cook wrote:
> > Kees, try to think for a minute[1]. Really. We have general-purpose
> > ...
> > [1] yes, yes, I know - the mere mention of security should've prevented such
> > arrogant requests. It's an imperfect universe.
>
> I want to attempt to
On Thu, Oct 3, 2013 at 11:23 AM, Al Viro wrote:
> On Thu, Oct 03, 2013 at 11:03:07AM -0700, Kees Cook wrote:
>
>> > When you start a port to a 512-bit architecture, you'll have much nastier
>> > problems than this one...
>>
>> Well, this is simply taking advantage of this particular allocator's
>>
On Thu, Oct 03, 2013 at 11:03:07AM -0700, Kees Cook wrote:
> > When you start a port to a 512-bit architecture, you'll have much nastier
> > problems than this one...
>
> Well, this is simply taking advantage of this particular allocator's
> behavior. Instead of depending on this side-effect, why
On Thu, Oct 3, 2013 at 10:58 AM, Al Viro wrote:
> On Thu, Oct 03, 2013 at 09:34:11AM -0700, Kees Cook wrote:
>> In dentry_string_cmp (via__d_lookup_rcu), when CONFIG_DCACHE_WORD_ACCESS
>> is set, word-width memory reads are performed. However, the string
>> allocation size may not be a multiple of
On Thu, Oct 03, 2013 at 09:34:11AM -0700, Kees Cook wrote:
> In dentry_string_cmp (via__d_lookup_rcu), when CONFIG_DCACHE_WORD_ACCESS
> is set, word-width memory reads are performed. However, the string
> allocation size may not be a multiple of the word size. To avoid reading
> past the end of suc
In dentry_string_cmp (via__d_lookup_rcu), when CONFIG_DCACHE_WORD_ACCESS
is set, word-width memory reads are performed. However, the string
allocation size may not be a multiple of the word size. To avoid reading
past the end of such an allocation, we must allocate in multiples of
the word size.
F
13 matches
Mail list logo
