On 11/26/2012 05:15 AM, Tang Chen wrote:
>
> Hi Wu,
>
> That is really a problem. And, before numa memory got initialized,
> memblock subsystem would be used to allocate memory. I didn't find any
> approach that could fully address it when I making the patches. There
> always be risk that membloc
On 11/26/2012 08:57 AM, Herton Ronaldo Krzesinski wrote:
> 3.5.7u1 -stable review patch. If anyone has any objections, please let me
> know.
What kind of version number is that?
-hpa
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
On 11/26/2012 12:08 PM, Herton Ronaldo Krzesinski wrote:
> On Mon, Nov 26, 2012 at 10:02:09AM -0800, H. Peter Anvin wrote:
>> On 11/26/2012 08:57 AM, Herton Ronaldo Krzesinski wrote:
>>> 3.5.7u1 -stable review patch. If anyone has any objections, please let me
>>&g
On 11/26/2012 06:54 AM, Kinney, Steven wrote:
> Hi Andreas,
>
> This is your quirk, from AMD, and if you need to
> sign the patch please let me know how to facilitate this. I will add Joerg
> using his Email.
>
Please maintain the proper patch authorship. This is
On 11/25/2012 11:22 PM, Paolo Bonzini wrote:
> Il 21/11/2012 23:41, H. Peter Anvin ha scritto:
>> From: "H. Peter Anvin"
>>
>> In __emulate_1op_rax_rdx, we use "+a" and "+d" which are input/output
>> constraints, and *then* use "a&quo
On 11/26/2012 03:48 PM, Marcelo Tosatti wrote:
>>
>> Gleb, Marcelo: are you going to apply this or would you prefer I took it
>> in x86/urgent?
>>
>> -hpa
>
> Feel free to merge it through x86/urgent.
>
I presume that's an Acked-by?
-hpa
--
To unsubscribe from this list: send the
arser (these are just static tables, after all), but
I'm not sure if that fits into your overall view of how the subsystem
should work?
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
--
To unsubscribe from this
).
The movable memory should be classified as a non-RAM type in memblock. What
do you want to say? We don't save type in memblock because we only
add E820_RAM and E820_RESERVED_KERN to memblock.
We either need to keep the type or not add it to the memblocks.
-hpa
--
H. Peter Anvi
Not really, and it depends on so many variables.
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to major
On 11/27/2012 12:29 AM, Tang Chen wrote:
> Another approach is like the following:
> movable_node = 1,3-5,8
> This could set all the memory on the nodes to be movable. And the rest
> of memory works as usual. But movablecore_map is more flexible.
... but *much* harder for users, so movable_node is
On 11/27/2012 01:47 AM, Wen Congyang wrote:
At 11/27/2012 04:49 PM, H. Peter Anvin Wrote:
On 11/27/2012 12:29 AM, Tang Chen wrote:
Another approach is like the following:
movable_node = 1,3-5,8
This could set all the memory on the nodes to be movable. And the rest
of memory works as usual. But
From: "H. Peter Anvin"
According to kernel bugzilla 44931:
https://bugzilla.kernel.org/show_bug.cgi?id=44931
... the Linux kernel hasn't actually been compiling for 386 for three
releases now. I have verified that it doesn't, because the 386
fallback code for not ha
From: "H. Peter Anvin"
All 486+ CPUs support BSWAP, so remove the fallback 386 support
code.
Signed-off-by: H. Peter Anvin
---
arch/x86/Kconfig.cpu | 4
arch/x86/include/asm/futex.h | 12
arch/x86/include/asm/swab.h | 29 ++---
From: "H. Peter Anvin"
All 486+ CPUs support CMPXCHG, so remove the fallback 386 support
code.
Signed-off-by: H. Peter Anvin
---
arch/x86/Kconfig.cpu | 3 ---
arch/x86/include/asm/cmpxchg_32.h | 55 ---
arch/x86/include/asm/percpu.
From: "H. Peter Anvin"
The check_popad() routine tested for a 386-specific bug, and never
actually did anything useful with it anyway other than print a
message.
Signed-off-by: H. Peter Anvin
---
arch/x86/Kconfig.cpu | 4
arch/x86/kernel/cpu/b
From: "H. Peter Anvin"
All 486+ CPUs support CMPXCHG, so remove the fallback 386 support
code.
Signed-off-by: H. Peter Anvin
---
arch/x86/Kconfig | 5 -
arch/x86/Kconfig.cpu | 3 ---
arch/x86/include/asm/atomic.h | 16
arch/x86/include/a
From: "H. Peter Anvin"
Simplify the implementation of sync_core() for the case where we may
not have the CPUID instruction available.
Signed-off-by: H. Peter Anvin
---
arch/x86/include/asm/processor.h | 27 +--
1 file changed, 17 insertions(+), 10 deletion
From: "H. Peter Anvin"
All 486+ CPUs support WP in supervisor mode, so remove the fallback
386 support code.
Signed-off-by: H. Peter Anvin
---
arch/x86/Kconfig.cpu | 3 ---
arch/x86/include/asm/uaccess.h | 42 ---
arch/x86/lib/usercopy_32.
From: "H. Peter Anvin"
Remove the CONFIG_M386 symbol from Kconfig so that it cannot be
selected.
Signed-off-by: H. Peter Anvin
---
arch/x86/Kconfig | 6 ++---
arch/x86/Kconfig.cpu | 58
arch/x86/Makefile_32.cpu
From: "H. Peter Anvin"
All 486+ CPUs support INVLPG, so remove the fallback 386 support
code.
Signed-off-by: H. Peter Anvin
---
arch/x86/Kconfig.cpu | 4
arch/x86/include/asm/cpufeature.h | 6 --
arch/x86/include/asm/tlbflush.h | 3 ---
arch/x86/kernel
On 11/28/2012 01:34 PM, Luck, Tony wrote:
>>
>> 2. use boot option
>> This is our proposal. New boot option can specify memory range to use
>> as movable memory.
>
> Isn't this just moving the work to the user? To pick good values for the
> movable areas, they need to know how the memory lines
On 11/28/2012 01:47 PM, Yinghai Lu wrote:
> rebase patchset on top of linus v3.7-rc4. this one replace patches in
> tip/x86/mm2
What are the changes? Given how close we are to the merge window, if we
replace the entire patchset we are *definitely* slipping this to 3.9.
Depending on what the chan
Yes, the Nx586 was supported as a 386. Again, doubt anyone cares at this point.
Alan Cox wrote:
>On Wed, 28 Nov 2012 11:50:28 -0800
>"H. Peter Anvin" wrote:
>
>> From: "H. Peter Anvin"
>>
>> All 486+ CPUs support WP in supervisor mode, so r
: "ebx", "ecx", "edx", "memory");
... and then write this in its shorter form:
tmp = cpuid_eax(1);
to have it a bit easier on the eyes.
Wrong barrier semantics.
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I w
On 11/29/2012 03:00 AM, Mel Gorman wrote:
>
> I've not been paying a whole pile of attention to this because it's not an
> area I'm active in but I agree that configuring ZONE_MOVABLE like
> this at boot-time is going to be problematic. As awkward as it is, it
> would probably work out better to o
On 11/29/2012 01:13 AM, Borislav Petkov wrote:
>
> RCX gets correctly cleaned to 0 and *then* we call CPUID.
>
> And the asm output is the same except that RCX gets correctly cleaned up
> before calling CPUID.
>
> So what am I missing?
>
It doesn't matter in that context, as the surrounding MS
On 11/29/2012 12:09 PM, Andi Kleen wrote:
> Jim Kukunas writes:
>> +
>> +/* ymm0 = x0f[16] */
>> +asm volatile("vpbroadcastb %0, %%ymm7" : : "m" (x0f));
>> +
>> +while (bytes) {
>> +#ifdef CONFIG_X86_64
>> +asm volatile("vmovdqa %0, %%ymm1" : : "m" (q[0]));
>> +
On 11/29/2012 01:18 PM, Borislav Petkov wrote:
> On Thu, Nov 29, 2012 at 01:06:20PM -0800, H. Peter Anvin wrote:
>> It doesn't matter in that context, as the surrounding MSR references
>> have barriers, but what I'm refering to is the "memory" barrier.
>
>
On 11/28/2012 12:41 PM, Borislav Petkov wrote:
>
> While at it, you could correct this comment to adhere to kernel coding
> style:
>
> /*
>* cpuid is a barrier...
>* ...
>*/
>
>> +asm volatile("cpuid" : "=a" (tmp) : "0" (1)
>> + : "ebx", "ecx", "
On 11/29/2012 01:18 PM, Andi Kleen wrote:
>
> Can you quote it from the manual? As I understand volatile as usual
> is not clearly defined.
>
> gcc has a lot of optimization passes and volatile bugs are common.
>
I talked it over with H.J. and we walked through the code. The
documentation is
On 11/29/2012 01:18 PM, Andi Kleen wrote:
>
>> Either way, this implementatin technique was used for the MMX/SSE
>> implementations without any problems for 9 years now.
>
> It's still wrong.
>
> Lying to the compiler usually bites you at some point.
>
It's not lying to the compiler. It is te
On 11/29/2012 02:41 PM, Luck, Tony wrote:
>> The other bit is that if you really really want high reliability, memory
>> mirroring is the way to go; it is the only way you will be able to
>> hotremove memory without having to have a pre-event to migrate the
>> memory away from the affected node bef
Disk I/O is still a big consumer of lowmem.
"Luck, Tony" wrote:
>> If any significant percentage of memory is in ZONE_MOVABLE then the
>memory
>> hotplug people will have to deal with all the lowmem/highmem problems
>> that used to be faced by 32-bit x86 with PAE enabled.
>
>While these problem
SEC_DEN;
270 # endif
271 #endif
272 }
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to maj
On 03/18/2013 11:53 AM, Yinghai Lu wrote:
> On Mon, Mar 18, 2013 at 3:21 AM, Lin Feng wrote:
>> For x86 PUD_SHIFT is 30 and PMD_SHIFT is 21, so the consequence of
>> (PUD_SHIFT-PMD_SHIFT)/2 is 4. Update the comments to the code.
>>
>> Cc: Yinghai Lu
>> Signed-off-by: Lin Feng
>> ---
>> arch/x86
On 03/18/2013 08:33 AM, Vivek Goyal wrote:
>
> Thinking more about it, if ongoing DMA is an issue, then setting up
> software iotlb in those areas is also prone to being overwritten by
> those DMAs. Hence, reserving memory low where no DMA is setup by first
> kernel, seems somewhat safer.
>
Agre
On 03/18/2013 12:13 PM, Yinghai Lu wrote:
>>
>> No, it doesn't. This is C, not elementary school Now I'm really bothered.
>>
>> The comment doesn't say *why* (PUD_SHIFT-PMD_SHIFT)/2 or any other
>> variant is correct, furthermore I suspect that the +1 is misplaced.
>> However, what is really need
On 03/18/2013 01:00 PM, Vivek Goyal wrote:
> On Mon, Mar 18, 2013 at 12:10:47PM -0700, H. Peter Anvin wrote:
>> On 03/18/2013 08:33 AM, Vivek Goyal wrote:
>>>
>>> Thinking more about it, if ongoing DMA is an issue, then setting up
>>> software iotlb i
On 03/18/2013 02:19 PM, Yinghai Lu wrote:
> On Mon, Mar 18, 2013 at 12:14 PM, H. Peter Anvin wrote:
>
>> Instead, try to explain why 5 is the correct value in the current code
>> and how it is (or should be!) derived.
>
> initial mapped size is PMD_SIZE, aka 2M.
>
On 03/18/2013 02:25 PM, Yinghai Lu wrote:
> Current code does not set low range for crashkernel if the user
> does not specify that.
>
> That cause regressions on system that does not support intel_iommu
> properly.
>
> Chao said that his system does work well on 3.8 without extra parameter.
> ev
ive years from now), and make that part of the
commit.
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger
On 03/19/2013 08:36 AM, Steven Rostedt wrote:
> On Tue, 2013-03-19 at 15:10 +, David Howells wrote:
>> Steven Rostedt wrote:
>>
>>> Why? If we remove the tracepoint from the slowpath and use a table swap,
>>> then we wouldn't need to use the slowpath at all.
>>
>> How are you engineering a tab
ith software that depends on the existence
> of /dev/root [2] for example.
>
> Do you need any more information on this patch, or is there some
> reason it can't go in?
>
Seems okay to me, although even better would be to use the udev name
of the device in question.
-
On 03/19/2013 04:15 PM, Yinghai Lu wrote:
> On Tue, Mar 19, 2013 at 8:04 AM, Fenghua Yu wrote:
>> From: Fenghua Yu
>>
>> In 32-bit, __pa_symbol() in CONFIG_DEBUG_VIRTUAL accesses kernel data (e.g.
>> max_low_pfn) that haven't been setup yet in such early boot phase. To fix the
>> issue, __pa_node
On 03/19/2013 04:48 PM, Yinghai Lu wrote:
>
> So do you mean we have to change all __pa_symbol before
> setup.c::setup_arch/find_low_pfn_range ?
> because only at that time max_low_pfn get setup.
>
No, I suspect the problem is that the debugging code fails to notice
that max_low_pfn isn't set up
the root= command line option.
The other option is to take the name from the mounted device number,
and look up the udev name (which is known by the kernel). That way it
works even if the user specifies a numeric device, or the default
device is used.
-hpa
--
H. Peter Anvin, Intel
On 03/18/2013 02:32 PM, Matthew Garrett wrote:
> IO port access would permit users to gain access to PCI configuration
> registers, which in turn (on a lot of hardware) give access to MMIO register
> space. This would potentially permit root to trigger arbitrary DMA, so lock
> it down by default.
>
chine.
So just reject CAP_SYS_RAWIO.
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel
elopers will be scratching
> their head over where to sprinkle this.
>
> Apart from that, I like the idea, especially when it's wired up to MAC
> security.
The wiring up to MAC security is a nice touch.
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I wor
On 03/19/2013 06:02 PM, H. Peter Anvin wrote:
>
> Looking at it in detail, EVERYTHING in CAP_SYS_RAWIO has the possibility
> of compromising the kernel, because they let device drivers be bypassed,
> which means arbitrary DMA, which means you have everything.
>
Well, *unless* yo
On 03/19/2013 06:07 PM, Matthew Garrett wrote:
> Yeah, I'd like the option of relaxing restrictions when drivers explicitly
> opt in based on iommu support.
When drivers opt in they can provide an interface. The interesting case
becomes non-drivers.
-hpa
--
H. Peter Anvin,
It's pretty important for PCI passthrough, so we do need to care.
It is actually very simple: the device should be able to DMA into/out of:
1. pinned pages
2. owned by the process controlling the device
... and nothing else.
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
On 03/19/2013 07:14 PM, Ren, Qiaowei wrote:
> Any comments on this patch?
>
> Thanks,
> Qiaowei
The biggest question is probably if we can use an existing hook of some
sort.
Overriding the apic method is probably not the right way to go, though.
tglx, do you have any opinions here?
Furthermore
On 03/19/2013 07:48 PM, H. Peter Anvin wrote:
> On 03/19/2013 06:28 PM, Matthew Garrett wrote:
>> Mm. The question is whether we can reliably determine the ranges a device
>> should be able to access without having to trust userspace (and, ideally,
>> without having to worr
On 03/19/2013 08:18 PM, Alex Williamson wrote:
>>
>> The "pinning" process needs to involve a call to the kernel to process
>> the page for DMA (pinning the page and opening it in the iommu) and
>> return a transaction address, of course.
>>
>> I think we have the interface for that in vfio, but I
Yes, but the current udev maintainer refuses to.
Rob Landley wrote:
>On 03/19/2013 07:20:17 PM, William Hubbs wrote:
>> On Tue, Mar 19, 2013 at 04:17:11PM -0700, H. Peter Anvin wrote:
>> > On 03/19/2013 03:28 PM, William Hubbs wrote:
>> > > The issue is that /dev/r
CAP_SYS_RAWIO is definitely inappropriate there.
Matthew Garrett wrote:
>On Tue, 2013-03-19 at 18:02 -0700, H. Peter Anvin wrote:
>
>> Looking at it in detail, EVERYTHING in CAP_SYS_RAWIO has the
>possibility
>> of compromising the kernel, because they let device drivers b
On 03/20/2013 08:14 AM, Matthew Garrett wrote:
> On Wed, 2013-03-20 at 08:03 -0700, H. Peter Anvin wrote:
>> CAP_SYS_RAWIO is definitely inappropriate there.
>
> Ok. How do we fix that without breaking userspace that expects
> CAP_SYS_RAWIO to be sufficient?
>
I don'
ch could support a FWH flash part.
Jan, in c24c95a085c6b52c11c2f5afecc38b0ca143cdae you comment out a
number of PCI IDs. Was that intentional?
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
--
To unsubscribe from thi
On 03/21/2013 03:40 AM, Ingo Molnar wrote:
>
> * Fenghua Yu wrote:
>
>> +initrd_start_p = (unsigned long *)__pa_nodebug(&initrd_start);
>> +initrd_start_addr = (unsigned long)__pa_nodebug(*initrd_start_p);
>
> We should probably use __pa_early() for that - aliased to __pa_nodebug().
>
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
--
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.kerne
:R8, stack, stack); AFAICS, we don't have anything that ugly...
Automating *that* is going to be interesting... I've not given up, but it's
not going to be fun ;-/
Feel free to steal machinery from klibc... it has scripts to
autogenerate stubs for arbitrary ABIs.
-hpa
a fundamntal semantic change to something that isn't just
affecting kexec.
This ultimately is the result of the very bad design decision to use the
command line to muck with the target kernel memory map.
The work is underway to fix this, but this is not the right fix.
-hpa
--
H.
boot_cpu_data is ok for things that are indeed universally valid across. That
does not include CPUID level, for one.
Borislav Petkov wrote:
>On Sun, Feb 03, 2013 at 03:44:29PM -0800, H. Peter Anvin wrote:
>> On 02/03/2013 08:14 AM, Borislav Petkov wrote:
>> >From: Borislav P
On 02/04/2013 01:02 AM, Borislav Petkov wrote:
> On Sun, Feb 03, 2013 at 09:44:02PM -0800, H. Peter Anvin wrote:
>> boot_cpu_data is ok for things that are indeed universally valid
>> across. That does not include CPUID level, for one.
>
> Wait a minute, hold the phone! :-
On 02/04/2013 11:39 AM, Helge Deller wrote:
>
> This suggestion is probably the best way to go, since Arm64 (and maybe
> others?)
> seems to have a non-working automounter. So in the long run even for other new
> upcoming architectures this inverted check seem to be the best solution, since
> it
The difference is that it used to be customary to have a /dev/root symlink;
iirc udev created one. Devtmpfs does not (for largely valid reasons, but it
does break some userspaces.)
Rob Landley wrote:
>On 01/31/2013 05:22:09 PM, H. Peter Anvin wrote:
>> On 01/31/2013 02:51 PM, Will
/IEC 7811 standard or any
similar standards.
You have to write a driver for whatever reader/writer you are using. A
lot of them simply show up as a USB HID (i.e. a keyboard) and thus don't
need any driver at all.
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I wor
There is no reason for that to be in the kernel.
Priyaranjan Das wrote:
>Hi Peter,
>
>On Tue, Feb 5, 2013 at 11:26 AM, H. Peter Anvin wrote:
>> On 02/04/2013 09:08 PM, Priyaranjan Das wrote:
>>>
>>> Hi All,
>>>
>>> I am working on a Magnet
nning directly out of
initramfs.
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
Mo
The cleanup is not a umount, it is actually a tree walk unlinking the contents.
"Kasatkin, Dmitry" wrote:
>On Wed, Feb 6, 2013 at 7:04 AM, H. Peter Anvin wrote:
>> On 02/05/2013 02:09 PM, Kasatkin, Dmitry wrote:
>>>
>>>
>>> It should not be li
tofs_wqt_t;
#endif
/* Packet types */
Acked-by: Ian Kent
Acked-by: H. Peter Anvin
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
--
To unsubscribe from this list: send the line "unsubscribe linux-kern
On 02/06/2013 01:46 PM, Ingo Molnar wrote:
>>
>> Linus has said that he will not take the kvmtool tree in its
>> current form, but would prefer that it be a separate project,
>> so I should really drop it from linux-next (and ask the tip
>> guys to remove it from their auto-latest branch).
>>
>>
On 02/05/2013 02:26 PM, Mike Travis wrote:
> Kernel updates for SGI Ultraviolet system 3 (UV3)
>
> The new MMR definitions are added, and then the updates
> to each module are applied. Afterwards, a "trim" patch
> reduces the size of the MMR definitions file by about
> a third. This keeps "bi-se
On 02/07/2013 08:53 AM, Ville Syrjälä wrote:
>
> Based on the initial response there seems to be some interest towards
> it at least. So I'm wondering what's the next step. Is it OK as is,
> or does it need more work, or would people want to extend it to include
> more of the original work?
>
> I
On 02/07/2013 09:44 AM, Kees Cook wrote:
> Without this patch, it is trivial to determine kernel page mappings by
> examining the error code reported to dmesg[1]. Instead, declare the entire
> kernel memory space as a violation of a present page.
>
> Additionally, since show_unhandled_signals is e
On 02/07/2013 10:44 AM, Kees Cook wrote:
>>
>> This patch probably also breaks TCP STUNT that is used by some applications
>> for NAT
>> traversal.
>
> The patch would not break it -- it defaults the sysctl to staying enabled.
>
> If you mean the documentation should be updated, sure, that's eas
On 02/07/2013 03:45 PM, kbuild test robot wrote:
> tree: git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86/mm
> head: 6fcddf474ae1c8e2fb5f14c850c8aa018e7a5034
> commit: 6fcddf474ae1c8e2fb5f14c850c8aa018e7a5034 x86-32: Add support for
> 64bit get_user()
> date: 2 hours ago
> confi
Yes, but you can't umount rootfs.
"Kasatkin, Dmitry" wrote:
>On Wed, Feb 6, 2013 at 6:41 PM, H. Peter Anvin wrote:
>> The cleanup is not a umount, it is actually a tree walk unlinking the
>contents.
>>
>
>Please see that umounting ramfs releases the mem
Yes, but I am talking about initramfs.
"Kasatkin, Dmitry" wrote:
>On Fri, Feb 8, 2013 at 5:49 PM, H. Peter Anvin wrote:
>> Yes, but you can't umount rootfs.
>
>But that was not a rootfs, but tmpfs/ramfs mounted to /root folder.
>
>>
>> "Kasatk
On 02/08/2013 07:28 AM, Russell King - ARM Linux wrote:
>
> Whether that's safe for x86 or not, I don't know, but my suspicions are
> that it's unsafe on x86 as it's possible to refer to the various bytes/
> half-words of eax separately.
>
> So, I came to the conclusion that if x86 remains a prob
On 02/08/2013 08:24 AM, Ville Syrjälä wrote:
>>
>> How have you tested it?
>
> I've tried it with my drm/kms atomic pageflip/modeset code. I also had
> a small test module that did a couple of different sized get_user()
> calls, but I'll be damned if I can find it again.
>
Did you see the warnin
Yes, or anything else getting a pointer in memory from user space.
"Ville Syrjälä" wrote:
>On Fri, Feb 08, 2013 at 09:30:05AM -0800, H. Peter Anvin wrote:
>> On 02/08/2013 08:24 AM, Ville Syrjälä wrote:
>> >>
>> >> How have you tested it?
>> >
We already have CAP_RAWIO for this in mainline; I am not sure if this should be
harder than that...
Kees Cook wrote:
>Writing to MSRs should not be allowed unless CAP_COMPROMISE_KERNEL is
>set since it could lead to execution of arbitrary code in kernel mode.
>
>Signed-off-by: Kees Cook
>---
>
On 02/08/2013 11:18 AM, Kees Cook wrote:
No. CAP_RAWIO is for reading. Writing needs a much stronger check.
-Kees
If so, I suspect we need to do this for *all* raw I/O... but I keep
wondering how much more sensitive writing really is than reading.
-hpa
--
H. Peter Anvin, Intel
, H. Peter Anvin wrote:
>> On 02/08/2013 11:18 AM, Kees Cook wrote:
>>>
>>> No. CAP_RAWIO is for reading. Writing needs a much stronger check.
>>
>> If so, I suspect we need to do this for *all* raw I/O... but I keep
>> wondering how much more sensitive wri
have been
broken with the NUMA remapping code had we not ripped it
out:
It would be great if you could take a stab at fixing /dev/mem and
/dev/kmem... there are a bunch of problems with both which seem to
really translate to "HIGHMEM was never properly implemented"...
-hpa
-
lways a valid reference? Consider
especially the case where there is MMIO beyond end of memory on a system
which has less RAM than the HIGHMEM boundary...
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
--
To unsubscribe fr
On 02/08/2013 01:02 PM, Kees Cook wrote:
> On Fri, Feb 8, 2013 at 12:34 PM, Matthew Garrett
> wrote:
>> On Fri, 2013-02-08 at 12:28 -0800, Kees Cook wrote:
>>
>>> Maybe a capability isn't the right way to go, I'm not sure. I'll leave
>>> that to Matthew. Whatever the flag, it should be an immutabl
On 02/08/2013 03:26 PM, Matthew Garrett wrote:
> On Sat, 2013-02-09 at 00:06 +0100, Borislav Petkov wrote:
>> On Fri, Feb 08, 2013 at 02:30:52PM -0800, H. Peter Anvin wrote:
>>> Also, keep in mind that there is a very simple way to deny MSR access
>>> completely, which i
ALL versions of gcc want DF=0 at all times...
Borislav Petkov wrote:
>From: Borislav Petkov
>
>gcc2 wants direction flag cleared but we don't support gcc2 anymore. So
>drop it. Original patch adding this was:
>
>commit 57d40092c375d2b6d34f814f5fb306967e22c4f5
>Author: linus1
>Date: Mon Nov 9
However... DF should have been cleared long before this...
Borislav Petkov wrote:
>From: Borislav Petkov
>
>gcc2 wants direction flag cleared but we don't support gcc2 anymore. So
>drop it. Original patch adding this was:
>
>commit 57d40092c375d2b6d34f814f5fb306967e22c4f5
>Author: linus1
>Date
On 02/09/2013 01:23 PM, Borislav Petkov wrote:
On Sat, Feb 09, 2013 at 12:52:01PM -0800, H. Peter Anvin wrote:
However... DF should have been cleared long before this...
How about we do this at the beginning of default_entry where we clear
EFLAGS too:
diff --git a/arch/x86/kernel/head_32.S b
gs
unambiguously clear".
(Note also we have had to CLD earlier because we have already copied the
command line.)
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
--
To unsubscribe from this list: send the line "unsu
Sure it does... it takes time.
Borislav Petkov wrote:
>On Sat, Feb 09, 2013 at 08:34:53PM -0800, H. Peter Anvin wrote:
>> I wouldn't really call it a "side effect". Perhaps the right thing
>> here is to say something like "we want to start out with %eflags
&
Yes... safer that way.
Borislav Petkov wrote:
>On Sun, Feb 10, 2013 at 04:37:27PM -0500, Len Brown wrote:
>> From: Len Brown
>>
>> Remove 32-bit x86 a cmdline param "no-hlt",
>> and the cpuinfo_x86.hlt_works_ok that it sets.
>>
>> If a user wants to avoid HLT, then "idle=poll"
>> is much more
What about CPUs with inconsistent cpuid levels? Yes, they can and do happen,
as we discussed on IRC.
Borislav Petkov wrote:
>From: Borislav Petkov
>
>We do that once earlier now and cache it into new_cpu_data.cpuid_level
>so no need for the EFLAGS.ID toggling dance anymore.
>
>Signed-off-by:
keep the
current "best effort" support for hetero systems (they do happen, I see
them every now and then in the field), but other than that this is a
nice cleanup.
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their
On 02/11/2013 09:15 AM, Borislav Petkov wrote:
On Mon, Feb 11, 2013 at 07:49:14AM -0800, H. Peter Anvin wrote:
What about CPUs with inconsistent cpuid levels? Yes, they can and do
happen, as we discussed on IRC.
Yes, this should still work. We're doing the EFLAGS.ID dance right a
headers_install" already has cleaned things up
immensely.
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a messag
1 - 100 of 6113 matches
Mail list logo
