On 07/11/2014 09:36 AM, Paul Moore wrote:
>
> Arguably audit is broken anyway by not correctly treating syscall numbers as
> 32 bit integers like everyone else.
>
That is really the root cause of the problem. x86 is not the only
architecture with a sparse syscall numbering scheme (in fact the
On 07/11/2014 09:23 AM, Eric Paris wrote:
>>
>> You're not going to hear me ever say that I like how the x32 ABI was done,
>> it
>> is a real mess from a seccomp filter point of view and we have to do some
>> nasty stuff in libseccomp to make it all work correctly (see my comments on
>> the lib
On 07/11/2014 09:11 AM, Paul Moore wrote:
> On Thursday, July 10, 2014 09:06:02 PM H. Peter Anvin wrote:
>> Incidentally: do seccomp users know that on an x86-64 system you can
>> recevie system calls from any of the x86 architectures, regardless of
>> how the program is invok
On 07/10/2014 08:38 PM, Richard Guy Briggs wrote:
> Commit
> fca460f h...@zytor.com 2012-02-19 07:56:26 -0800
> x32: Handle the x32 system call flag
>
> provided a method to multiplex architecture with the syscall number for X32
> calls.
>
> Commit
> 8b4b9f2 pmo...@redhat.com 20
On 07/03/2014 07:35 AM, Jan Beulich wrote:
> Relying on static functions used just once to get inlined (and
> subsequently have dead code paths eliminated) is wrong: Compilers are
> free to decide whether they do this, regardless of optimization level.
> With this not happening for vdso_addr() (obs
On 07/08/2014 03:34 PM, Stuart Hayes wrote:
>
> I haven't received any responses... is there a problem with the patch? Also
> CCing a couple people.
>
I was on vacation last week and am still catching up.
It would also help if you describe the real-world scenario that made you
trip over this.
On 07/07/2014 03:30 PM, Andi Kleen wrote:
>
> Since the 16K stack change I noticed a number of problems with
> my usual stress tests. They have a tendency to bomb out
> because something cannot fork.
As in ENOMEM or does something worse happen?
> - AIM7 on a dual socket socket system now cannot
Because it is an established part of the UEFI specification which has specific
terms for adoption.
On July 4, 2014 12:12:51 PM PDT, Anca Emanuel wrote:
>Wow MZ ? EXE for MSDOS and Windows ???
>
>After more research, http://en.wikipedia.org/wiki/Portable_Executable
>[quote]PE is a modified versio
On 07/02/2014 01:07 PM, Andy Lutomirski wrote:
> On Wed, Jul 2, 2014 at 1:05 PM, H. Peter Anvin wrote:
>> On 07/02/2014 01:00 PM, Andy Lutomirski wrote:
>>>
>>> I managed to munge the binutils sources enough to build binutils 2.21.
>>> This seems to be a
On 07/02/2014 01:00 PM, Andy Lutomirski wrote:
>
> I managed to munge the binutils sources enough to build binutils 2.21.
> This seems to be a binutils bug: ld generates an empty .rela.dyn.
> Fortunately, it's not generating a DT_RELA dynamic entry.
>
Not sure if that is a bug. Unnecessary, yes
On 06/10/2014 10:04 PM, Yinghai Lu wrote:
> When using kexec with 64bit kernel, bzImage and ramdisk could be
> loaded above 4G. We need this to get correct ramdisk adress.
>
> Make get_ramdisk_image() global and use it for early microcode updating.
> Also make it to take boot_params pointer for di
On 06/26/2014 10:05 PM, Oren Twaig wrote:
> ping
This patch conflicts with the changes on the tip:x86/apic branch. Could
you please rebase the patch on top of that branch?
-hpa
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord
The real question is if we care that sysret and iter don't match. On 32 bits
the situation is even more complex.
On June 26, 2014 1:00:22 PM PDT, Andy Lutomirski wrote:
>On Thu, Jun 26, 2014 at 12:59 PM, Andy Lutomirski
>wrote:
>> On Thu, Jun 26, 2014 at 12:56 PM, Andi Kleen
>wrote:
show
On 06/24/2014 12:50 PM, Andy Lutomirski wrote:
> It should really apply to everything in the vdso, and putting it in
> the C files seems unreliable.
Please write a more detailed patch description. In this case, it was
causing build failures, and that should be noted in the description.
> It was
On 06/24/2014 11:29 AM, H. Peter Anvin wrote:
>
> Hi Ingo,
>
> Could you try this with the attached patch?
>
Nevermind, not useful...
-hpa
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.
On 06/24/2014 11:37 AM, Andy Lutomirski wrote:
>>
>> diff --git a/arch/x86/vdso/vdso2c.h b/arch/x86/vdso/vdso2c.h
>> index f42e2ddc663d..94158e100f26 100644
>> --- a/arch/x86/vdso/vdso2c.h
>> +++ b/arch/x86/vdso/vdso2c.h
>> @@ -99,8 +99,9 @@ static void BITSFUNC(copy_section)(struct
>> BITSFUNC(fak
gt;> AuthorDate: Wed, 18 Jun 2014 15:59:46 -0700
>> Committer: H. Peter Anvin
>> CommitDate: Thu, 19 Jun 2014 15:44:51 -0700
>>
>> x86/vdso: Discard the __bug_table section
>>
>> It serves no purpose in user code.
On 06/24/2014 11:19 AM, Andy Lutomirski wrote:
>>>
>>> One of the recent x86/urgent vdso commits causes this build failure:
>>>
>>> Error: too many copied sections (max = 13)
>>
>> I can't reproduce this with your config, which suggestes a binutils
>> issue, which is annoying. Can you tell me wha
G.
>
> Test with uncompressed initrd, and compressed ones with gz, bz2, lzma,xz,
> lzop.
>
> -v2: according to HPA, change name to xwrite.
>
> Signed-off-by: Yinghai Lu
> Acked-by: H. Peter Anvin
>
> ---
> init/initramfs.c | 33
On 06/20/2014 01:00 PM, Borislav Petkov wrote:
> On Fri, Jun 20, 2014 at 11:54:14AM -0700, H. Peter Anvin wrote:
>> No, it has to be cpu_has() -- the dynamic, CPU-specific version.
>
> Ok, sry, but I have to ask: why cpu_has? Why not boot_cpu_has and thus
> static_cpu_has_saf
On 06/20/2014 11:15 AM, Borislav Petkov wrote:
> On Fri, Jun 20, 2014 at 10:50:25AM -0700, H. Peter Anvin wrote:
>> Looking at the AMD init code, there is a whole bunch of other 32/64-bit
>> differences that are clearly bogus. I also see that amd_k7_smp_check()
>> doesn'
On 06/20/2014 11:05 AM, Borislav Petkov wrote:
> On Fri, Jun 20, 2014 at 10:47:22AM -0700, H. Peter Anvin wrote:
>> This is run before static_cpu_has().
>
> static_cpu_has_safe() then - I didn't do it for no reason :-)
No, it has to be cpu_has() -- the dynamic,
Looking at the AMD init code, there is a whole bunch of other 32/64-bit
differences that are clearly bogus. I also see that amd_k7_smp_check()
doesn't even *exist* on 64 bits, and that init_amd_k7() which calls
amd_k7_smp_check() only is ever called for family == 6, despite having
tests for family
On 06/20/2014 10:43 AM, Borislav Petkov wrote:
> On Fri, Jun 20, 2014 at 09:37:57AM -0700, H. Peter Anvin wrote:
>> We probably should just the cpu_has_mp macro entirely. All it is used
>> for is printing a warning in amd_k7_smp_check().
>>
>> Andi, Borislav -- as
On 06/20/2014 09:30 AM, Dave Hansen wrote:
> On 06/20/2014 09:23 AM, H. Peter Anvin wrote:
>> On 06/20/2014 09:17 AM, Dave Hansen wrote:
>>>> Today, we assume that all 64-bit cpus have X86_FEATURE_MP. It
>>>> should be in the REQUIRED_MASK so that we do not need t
On 06/20/2014 09:17 AM, Dave Hansen wrote:
> Today, we assume that all 64-bit cpus have X86_FEATURE_MP. It
> should be in the REQUIRED_MASK so that we do not need the #undef
> trick for it.
I don't think we enforce that the MP bit is set in CPUID, though.
Non-AMD processors will typically not set
On 06/20/2014 09:17 AM, Dave Hansen wrote:
> diff -puN /dev/null arch/x86/include/asm/disabled-features.h
> --- /dev/null 2014-04-10 11:28:14.066815724 -0700
> +++ b/arch/x86/include/asm/disabled-features.h2014-06-20
> 09:15:38.968987152 -0700
> @@ -0,0 +1,33 @@
> +#ifndef _ASM_X86_DISABLE
On 06/19/2014 10:02 PM, Yinghai Lu wrote:
> On Thu, Jun 19, 2014 at 9:29 PM, H. Peter Anvin wrote:
>> On 06/19/2014 07:12 PM, Yinghai Lu wrote:
>>>
>>> Also need to use that in write_buffer path for cpio that have file is
>>> more than file.
>>
>&g
On 06/19/2014 09:24 PM, Stephen Rothwell wrote:
> Hi all,
>
> On Mon, 16 Jun 2014 11:57:09 +1000 Stephen Rothwell
> wrote:
>>
>> After merging the tip tree, today's linux-next build (x86_64
>> allmodconfig) produced this warning:
>>
>> In file included from
>> arch/x86/crypto/camellia_aesni_
two copies
of the data in memory at the same time.
Otherwise,
Acked-by: H. Peter Anvin
-hpa
--
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 06/19/2014 11:50 AM, Dave Hansen wrote:
> On 06/19/2014 11:02 AM, H. Peter Anvin wrote:
>> On 06/18/2014 09:25 AM, Dave Hansen wrote:
>>> How about something like the attached patch?
>>>
>>> This lets us use static_cpu_has() for the checks, and allows us to
On 06/18/2014 03:59 PM, Andy Lutomirski wrote:
>
> This may break make vdso_install with binutils before 2.17.50.0.17.
> On the other hand, make vdso_install was probably never useful with
> earlier binutils, since the installed files are AFAIK completely
> useless without build-id.
>
How does i
On 06/18/2014 03:59 PM, Andy Lutomirski wrote:
> This series makes me sad. It brings the 64-bit vdso back above 4kB,
> like it was in 3.15. It's also just silly, but it seems to be
> needed to keep binutils happy when debugging the vdso.
Oh well... it is only a single page across the entire kern
On 06/19/2014 01:01 PM, Greg KH wrote:
> On Thu, Jun 19, 2014 at 09:15:36PM +0200, Daniel Vetter wrote:
>> On Thu, Jun 19, 2014 at 7:00 PM, Greg KH wrote:
>> + BUG_ON(f1->context != f2->context);
>
> Nice, you just crashed the kernel, making it impossible to debug or
> recover
On 06/18/2014 09:25 AM, Dave Hansen wrote:
> On 06/18/2014 07:59 AM, H. Peter Anvin wrote:
>> On 06/18/2014 07:35 AM, Dave Hansen wrote:
>>> It looks like static_cpu_has() is the right thing to use instead of
>>> boot_cpu_has(). But, this doesn't just obfuscate th
On 06/19/2014 10:04 AM, Dave Hansen wrote:
>
> Could you please support this position with some data? I'm a bit
> skeptical that instruction decoding is going to be a
> performance-critical path.
>
> I also don't see the extra field that you talked about in the previous
> thread? What's the ext
On 06/18/2014 07:35 AM, Dave Hansen wrote:
>
> It looks like static_cpu_has() is the right thing to use instead of
> boot_cpu_has(). But, this doesn't just obfuscate things.
>
> We actually _want_ the compiler to cull code out when the config option
> is off. Things like do_bounds() will see co
On 06/18/2014 07:44 AM, Borislav Petkov wrote:
>
> Why?
>
> Practically, distros will have it enabled anyway (you have X86_INTEL_MPX
> depend on CPU_SUP_INTEL).
>
> Are you talking about the miniscule percentage of people building their
> own kernels?
>
We have people working hard to shave kil
On 06/17/2014 08:45 PM, Andy Lutomirski wrote:
> On Tue, Jun 17, 2014 at 3:54 PM, Andy Lutomirski wrote:
>> Just a heads up: gdb can't debug the vdso on 3.16-rc1. I filed a bug:
>>
>> https://sourceware.org/bugzilla/show_bug.cgi?id=17064
>>
>> We may need to extend the fake section header hack to
On 06/16/2014 02:43 PM, Vivek Goyal wrote:
>>
>> Borislav and I talked about this briefly over IRC. A key part of that
>> is that if userspace could manipulate this system call to consume an
>> unreasonable amount of memory, we would have a problem, for example if
>> this code used vzalloc() inste
>
> For 64-bit, I want to do this instead:
>
> https://git.kernel.org/cgit/linux/kernel/git/luto/linux.git/commit/?h=x86/seccomp-fastpath&id=a5ec2d7af2c54b55fc7201fa662138b53fbbda39
>
> I see no reason why the 64-bit badsys code needs its own code path at
> all. I haven't sent it yet because AF
On 06/16/2014 02:35 PM, Andy Lutomirski wrote:
>
> To hpa, etc: It appears that entry_32.S is missing any call to the
> audit exit hook on the badsys path. If I'm diagnosing this bug report
> correctly, this causes OOPSes.
>
> The the world at large: it's increasingly apparent that no one (exce
On 06/16/2014 02:09 PM, Borislav Petkov wrote:
>
> Nah, I don't feel strongly about it - I just don't trust userspace and
> think that every value we get from it should be "sanitized".
>
Borislav and I talked about this briefly over IRC. A key part of that
is that if userspace could manipulate
On 06/16/2014 04:54 AM, Juergen Gross wrote:
>
> And shouldn't it be removed from include/linux/efi.h as well?
>
Indeed.
-hpa
--
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:/
Yes, but the option exists.
On June 15, 2014 1:53:17 PM PDT, Andy Lutomirski wrote:
>On Sun, Jun 15, 2014 at 12:56 PM, H. Peter Anvin wrote:
>> You can link against vdso.so if you want to; the kernel build
>provides an option to install that image. Doesn't mean that any
>
You can link against vdso.so if you want to; the kernel build provides an
option to install that image. Doesn't mean that any particular libc uses it.
On June 15, 2014 12:50:36 PM PDT, Ian Lance Taylor wrote:
>On Sun, Jun 15, 2014 at 12:31 PM, H. Peter Anvin wrote:
>> The we
The weak symbols are well-known names. The __vdso symbols are strong.
On June 15, 2014 12:22:17 PM PDT, Ian Lance Taylor wrote:
>On Sun, Jun 15, 2014 at 12:14 PM, H. Peter Anvin wrote:
>>
>> If it doesn't, then you incur an additional indirection penalty. The
>strong _
very much how
glibc manages transitions.
On June 15, 2014 11:54:10 AM PDT, Andy Lutomirski wrote:
>On Sun, Jun 15, 2014 at 11:39 AM, H. Peter Anvin wrote:
>> Symbol versioning so we can rev the ABI and still provide backwards
>compatibility. Weak symbols so the libc can overr
gt;On Sun, Jun 15, 2014 at 10:57 AM, H. Peter Anvin wrote:
>> On 06/15/2014 10:40 AM, Andy Lutomirski wrote:
>>>
>>> To be clear, I have no desire whatsoever to give the vdso an actual
>>> ELF parser or anything else that userspace should be providing
>itself.
>
On June 15, 2014 10:40:03 AM PDT, Andy Lutomirski wrote:
>On Sun, Jun 15, 2014 at 10:05 AM, H. Peter Anvin wrote:
>> On 06/15/2014 07:35 AM, Rich Felker wrote:
>>>
>>> Arguably, it was a mistake for the kernel to expose a virtual ELF to
>>> begin with, and i
On 06/15/2014 10:40 AM, Andy Lutomirski wrote:
>
> To be clear, I have no desire whatsoever to give the vdso an actual
> ELF parser or anything else that userspace should be providing itself.
> I think that a special-purpose vdso parser in the vdso makes some
> sense, though, since userspace might
On 06/15/2014 07:35 AM, Rich Felker wrote:
>
> Arguably, it was a mistake for the kernel to expose a virtual ELF to
> begin with, and it should just have exposed a "lookup function by
> name" operation to begin with. Yes this can be done in userspace, but
> I see it more as a matter of "fixing a b
On 06/15/2014 09:35 AM, Borislav Petkov wrote:
>
>> +if (memcmp((char *)&header->header, "HdrS", 4) != 0) {
>
> Not strncmp? "HdrS" is a string...
>
No, memcmp() is more appropriate. It is really more of a byte sequence
than a string.
It could just as easily be done as:
header->h
On 06/14/2014 04:36 PM, H. Peter Anvin wrote:
>
> Now, if we can do this without adding another page then that becomes
> much more compelling IMO. I suspect we can if you are already down to
> 488 bytes.
>
(If it isn't already the case, was inteded to be part of that...)
On 06/14/2014 03:38 PM, Andy Lutomirski wrote:
>
> Hmm. I hadn't thought of this as a size win, but I guess it could be
> if there are static binaries around.
>
That pretty much *is* the win, because this is in effect treating the
kernel vdso as a shared library.
> This patch currently generat
On 06/13/2014 05:39 PM, Rafael J. Wysocki wrote:
>
> -#define RESTORE_MAGIC0x0123456789ABCDEFUL
> +#define RESTORE_MAGIC0x0123456789ABCDF0UL
>
Please don't pick numbers like this for magic numbers... *everyone else
does, too.* In general, picking a random number is a good st
Makes sense to me.
Feel free to add my
Acked-by: H. Peter Anvin
On June 13, 2014 7:40:50 PM PDT, Theodore Ts'o wrote:
>On Thu, Jun 12, 2014 at 12:09:54PM +0200, Torsten Duwe wrote:
>> >
>> > Did we lose track of this patchset?
>>
>> Yes. I was already c
On 06/13/2014 05:14 PM, Rafael J. Wysocki wrote:
>
> How can I obtain a kernel address of the beginning of a given page
> (as represented by struct page) on x86_64 today?
>
page_to_virt()
-hpa
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a
Andy Lutomirski (5):
x86/vdso/doc: Rename vdso_test.c to vdso_standalone_test_x86.c
x86/vdso/doc: Make vDSO examples more portable
x86/vdso: Add PUT_LE to store little-endian values
x86/vdso: Hack to keep 64-bit Go programs working
x86/vdso: Fix vdso_i
On 06/13/2014 10:32 AM, Kees Cook wrote:
>>
>> x86-64 can resume from different kernel that did the suspend. kASLR
>> should not be too different from that. (You just include kernel text
>> in the hibernation image. It is small enough to do that.)
>
> Oooh, that's very exciting! How does that work
On 06/12/2014 10:01 AM, Josh Boyer wrote:
> On Thu, Jun 12, 2014 at 11:28 AM, Andy Lutomirski wrote:
>> The filenames are different now. Inspired by a patch from
>> Sam Ravnborg.
>>
>> Acked-by: Sam Ravnborg
>> Reported-by: Josh Boyer
>> Signed-off-by: Andy Lutomirski
>
> Things look great wi
On 06/13/2014 08:34 AM, Andy Lutomirski wrote:
>
> I'm only aware of two implementations that work like that: glibc and
> musl. AFAIK neither one even tries to use the vdso when statically
> linked. IIRC, Bionic doesn't support the vdso at all, and Go has the
> present issue.
>
I would expect
On 06/12/2014 10:47 PM, Kui Zhang wrote:
> Thanks for the patches. The workaround works.
>
> Stupid idea, maybe something in dmesg to help spark conversions, when
> this workaround is hit?
>
> Looks like golang people are close.
>
The kernel won't even know.
-hpa
--
To unsubscribe fr
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 *vdso_find_entry(const char *name, const char *version)
>
> Then things
On 06/12/2014 10:23 PM, Andy Lutomirski wrote:
>
> As far as I know, there's no reliable way to just read the dynsym
> table -- the thing doesn't have a specified length, which is what
> broke Go in the first place.
>
Ah yes, you're right.
>
> Parsing the ELF dynamic tables is kind of annoyingl
On 06/12/2014 09:36 PM, Andy Lutomirski wrote:
>
> If we were to implement both, maybe we'd actually want to provide
> something like:
>
> struct vdso_entry {
> unsigned long vdso_entry_struct_size; /* so we can add fields later on */
> void *func;
> unsigned int max_stack; /* zero if not
On 06/12/2014 06:52 PM, Andy Lutomirski wrote:
> On Thu, Jun 12, 2014 at 6:49 PM, H. Peter Anvin wrote:
>> On 06/12/2014 05:53 PM, Andy Lutomirski wrote:
>>>
>>> This is currently broken for big-endian build hosts. The hack
>>> should also be disabled for x32,
On 06/12/2014 05:53 PM, Andy Lutomirski wrote:
>
> This is currently broken for big-endian build hosts. The hack
> should also be disabled for x32, but I'm not sure what the right way
> to do that is.
>
This comment is obsolete, no?
-hpa
--
To unsubscribe from this list: send the lin
On 06/12/2014 01:27 PM, Kees Cook wrote:
>>
>> Any way we can make them work together instead?
>
> I'm sure there is, but I don't know the solution. :)
>
> At the very least this gets us one step closer (we can build them together).
>
But it is really invasive.
I have to admit to being somewha
On 06/12/2014 11:47 AM, Andy Lutomirski wrote:
>
> This is currently broken for big-endian build hosts. The hack
> should also be disabled for x32, but I'm not sure what the right way
> to do that is.
>
Well, if it isn't exported into the x32 vdso it isn't an issue, right?
-hpa
--
To
On 06/12/2014 11:47 AM, Andy Lutomirski wrote:
>
> +#include
> +
This isn't portable in any way. This is probably not the right way to
do this.
The portable way to do this would be something like:
#include
#if ULONG_MAX > 0xUL
# define ELF_BITS 64
#else
# define ELF_BITS 32
#endif
On 06/12/2014 12:46 PM, Kees Cook wrote:
> Distros want to be able to offer CONFIG_RANDOMIZE_BASE as well as
> CONFIG_HIBERNATION in a single kernel. Instead of making kASLR depend on
> !HIBERNATION at compile time, allow kaslr to be selectable at boot time
> (via "kaslr" kernel command line), whic
On 06/12/2014 11:51 AM, Andy Lutomirski wrote:
> On Thu, Jun 12, 2014 at 11:48 AM, H. Peter Anvin wrote:
>> On 06/12/2014 11:42 AM, Andy Lutomirski wrote:
>>>
>>> Note that my hack will build a buggy vdso on big-endian hosts. Is
>>> there a way to conver
On 06/12/2014 11:42 AM, Andy Lutomirski wrote:
>
> Note that my hack will build a buggy vdso on big-endian hosts. Is
> there a way to convert host -> BE yet?
>
Yes, use .
-hpa
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to major
On 06/12/2014 11:38 AM, Andy Lutomirski wrote:
>>
>> 2. Write a dummy section table that contains a single empty section of
>> type SHT_DYNSYM. Hopefully the Go runtime will then get far enough to
>> fail cleanly. And they can go and write a real ELF parser or copy my
>> reference parser correctl
On 05/27/2014 07:11 AM, Torsten Duwe wrote:
> [checkpatch tells me not to 0-init...]
>
> This patch introduces a derating factor to struct hwrng for
> the random bits going into the kernel input pool, and a common
> default derating for drivers which do not specify one.
>
> Signed-off-by: Torsten
On 06/11/2014 06:11 AM, Theodore Ts'o wrote:
> On Tue, Jun 10, 2014 at 11:58:06PM -0400, George Spelvin wrote:
>> You can forbid underflows, but the code doesn't forbid overflows.
>>
>> 1. Assume the entropy count starts at 512 bytes (input pool full)
>> 2. Random writer mixes in 20 bytes of entrop
On 06/11/2014 01:41 PM, H. Peter Anvin wrote:
> On 06/11/2014 12:25 PM, Theodore Ts'o wrote:
>> On Wed, Jun 11, 2014 at 09:48:31AM -0700, H. Peter Anvin wrote:
>>> While talking about performance, I did a quick prototype of random using
>>> Skein instead of SHA-1,
On 06/11/2014 03:22 PM, Andy Lutomirski wrote:
> On Wed, Jun 11, 2014 at 3:18 PM, H. Peter Anvin wrote:
>> On 06/11/2014 02:56 PM, Andy Lutomirski wrote:
>>>
>>> 13ns is with the simplest nonempty filter. I hope that empty filters
>>> don't work
On 06/11/2014 02:56 PM, Andy Lutomirski wrote:
>
> 13ns is with the simplest nonempty filter. I hope that empty filters
> don't work.
>
Why wouldn't they?
-hpa
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel
On 06/11/2014 12:21 PM, Sam Ravnborg wrote:
> On Tue, Jun 10, 2014 at 04:13:04PM -0700, H. Peter Anvin wrote:
>> After a recent problem in the x86 tree, which seems to be the heaviest
>> but not the only user of these functions, I went through and did a
>> patchset to r
On 06/11/2014 12:25 PM, Theodore Ts'o wrote:
> On Wed, Jun 11, 2014 at 09:48:31AM -0700, H. Peter Anvin wrote:
>> While talking about performance, I did a quick prototype of random using
>> Skein instead of SHA-1, and it was measurably faster, in part because
>> Skein pro
On 06/11/2014 10:30 AM, Yinghai Lu wrote:
> On Tue, Jun 10, 2014 at 11:08 PM, H. Peter Anvin wrote:
>> On 06/10/2014 10:04 PM, Yinghai Lu wrote:
>>> When using kexec with 64bit kernel, bzImage and ramdisk could be
>>> loaded above 4G. We need this to get correct r
On 06/11/2014 10:23 AM, Josh Boyer wrote:
>
> So this does fix the invocation of 'make vdso_install' and the
> resulting files look to be accurate to me, with the glaring exception
> that now we get e.g. vdso64.so on x86_64 as the installed file instead
> of vdso.so. How much that actually matter
On 06/11/2014 09:38 AM, Theodore Ts'o wrote:
> On Mon, Jun 09, 2014 at 09:17:38AM -0400, George Spelvin wrote:
>> Here's an example of a smaller, faster, and better fast_mix() function.
>> The mix is invertible (thus preserving entropy), but causes each input
>> bit or pair of bits to avalanche to
On 06/11/2014 08:20 AM, Andy Lutomirski wrote:
>
> Is vdso_install supposed to install a .so file or just a .so.dbg file?
> I'm having trouble parsing this:
>
> quiet_cmd_vdso_install = INSTALL $@
> cmd_vdso_install = cp $(obj)/$@.dbg $(MODLIB)/vdso/$@
> $(vdso-install-y): %.so: $(obj)/%.s
On 06/11/2014 08:20 AM, Josh Boyer wrote:
>>
>> Since when do we support "make" in a subdirectory?
>
> Dunno. Since when do we break existing make targets that worked fine?
>
> Seriously, I'm just asking how this was build tested so I can try and
> duplicate that and then figure out how to fix t
On 06/11/2014 08:16 AM, Josh Boyer wrote:
> On Wed, Jun 11, 2014 at 10:14 AM, Josh Boyer
> wrote:
>> Hi,
>>
>> I'm guessing commit 6f121e548f83674ab4920a4e60afb58d4f61b829 is what
>> broke the vdso_install target:
>>
>> + make -s ARCH=x86_64
>> INSTALL_MOD_PATH=/home/jwboyer/rpmbuild/BUILDROOT/ke
On 06/10/2014 10:04 PM, Yinghai Lu wrote:
> When using kexec with 64bit kernel, bzImage and ramdisk could be
> loaded above 4G. We need this to get correct ramdisk adress.
>
> Make get_ramdisk_image() global and use it for early microcode
> updating. Also make it to take boot_params pointer for dif
On 06/10/2014 04:33 PM, Andy Lutomirski wrote:
>
> Ah, sneaky.
>
> Would it make sense to put a comment in this file (and similar files)
> indicating that they must only be included on architectures of the
> appropriate endianness?
>
That might make sense, yes, although I don't think we do that
On 06/10/2014 04:25 PM, Andy Lutomirski wrote:
> On Tue, Jun 10, 2014 at 4:13 PM, H. Peter Anvin wrote:
>> For architectures which handle unaligned references transparently.
>
> Shouldn't these depend on host endianness?
>
See further down the series for how the
Create and create an unaligned subdirectory for
specific implementations -- currently including the existing
be_byteshift.h and le_byteshift.h.
Signed-off-by: H. Peter Anvin
---
arch/x86/boot/compressed/mkpiggy.c | 2 +-
arch/x86/boot/tools/build.c | 2 +-
arch/x86
After a recent problem in the x86 tree, which seems to be the heaviest
but not the only user of these functions, I went through and did a
patchset to revamp the *user space* unaligned/endian accessor
functions. As much as I think it is downright pathetic that this
functionality still isn't part of
Move common includes and infrastructure into .
Signed-off-by: H. Peter Anvin
---
tools/include/tools/unaligned.h | 34
tools/include/tools/unaligned/be_bswap.h | 2 --
tools/include/tools/unaligned/be_byteshift.h | 2 --
tools/include/tools
compiler to
generate better code on some architectures (stores in sequence.)
Signed-off-by: H. Peter Anvin
---
tools/include/tools/be_byteshift.h | 62 ++
tools/include/tools/le_byteshift.h | 62 ++
2 files changed, 44
Common selection infrastructure for picking the best byte swap method.
Signed-off-by: H. Peter Anvin
---
tools/include/tools/unaligned/be_swap.h | 15 +++
tools/include/tools/unaligned/le_swap.h | 15 +++
2 files changed, 30 insertions(+)
create mode 100644 tools
For architectures which handle unaligned references transparently.
Signed-off-by: H. Peter Anvin
---
tools/include/tools/unaligned/be_direct.h | 48 +++
tools/include/tools/unaligned/le_direct.h | 48 +++
2 files changed, 96 insertions
gcc can generate code for unaligned references using a packed struct
on nearly all architectures.
Signed-off-by: H. Peter Anvin
---
tools/include/tools/unaligned/be_struct.h | 60 +++
tools/include/tools/unaligned/le_struct.h | 60 +++
2
Add support for gcc __builtin_bswap*() for byteswapping unaligned
references.
Signed-off-by: H. Peter Anvin
---
tools/include/tools/unaligned/be_bswap.h | 36
tools/include/tools/unaligned/le_bswap.h | 36
2 files changed, 72
Underscore-capital symbols belong to the implementation, i.e. the
libc, and we are not it.
Signed-off-by: H. Peter Anvin
---
tools/include/tools/unaligned/be_bswap.h | 6 +++---
tools/include/tools/unaligned/be_byteshift.h | 6 +++---
tools/include/tools/unaligned/be_direct.h| 6
1001 - 1100 of 6113 matches
Mail list logo
