* Re: [PATCH 3/5] v2 seccomp_filters: Enable ftrace-based system call filtering
From: Peter Zijlstra @ 2011-05-13 12:19 UTC (permalink / raw)
To: Ingo Molnar
Cc: linux-mips, linux-sh, Frederic Weisbecker, Heiko Carstens,
Oleg Nesterov, David Howells, Paul Mackerras, Eric Paris,
H. Peter Anvin, sparclinux, Jiri Slaby, linux-s390, Russell King,
x86, James Morris, Linus Torvalds, Ingo Molnar, linux-arm-kernel,
kees.cook, Serge E. Hallyn, microblaze-uclinux, Steven Rostedt,
Martin Schwidefsky, Thomas Gleixner, Roland McGrath, Michal Marek,
Michal Simek, Will Drewry, linuxppc-dev, linux-kernel,
Ralf Baechle, Paul Mundt, Tejun Heo, linux390, Andrew Morton, agl,
David S. Miller
In-Reply-To: <20110513121034.GG21022@elte.hu>
On Fri, 2011-05-13 at 14:10 +0200, Ingo Molnar wrote:
> err =3D event_vfs_getname(result);
I really think we should not do this. Events like we have them should be
inactive, totally passive entities, only observe but not affect
execution (other than the bare minimal time delay introduced by
observance).
If you want another entity that is more active, please invent a new name
for it and create a new subsystem for them, now you could have these
active entities also have an (automatic) passive event side, but that's
some detail.
^ permalink raw reply
* Re: [PATCH 3/5] v2 seccomp_filters: Enable ftrace-based system call filtering
From: Ingo Molnar @ 2011-05-13 12:10 UTC (permalink / raw)
To: James Morris
Cc: linux-mips, linux-sh, Peter Zijlstra, Frederic Weisbecker,
Heiko Carstens, Oleg Nesterov, David Howells, Paul Mackerras,
Eric Paris, H. Peter Anvin, sparclinux, Jiri Slaby, linux-s390,
Russell King, x86, Linus Torvalds, Ingo Molnar, linux-arm-kernel,
kees.cook, Serge E. Hallyn, Peter Zijlstra, microblaze-uclinux,
Steven Rostedt, Martin Schwidefsky, Thomas Gleixner,
Roland McGrath, Michal Marek, Michal Simek, Will Drewry,
linuxppc-dev, linux-kernel, Ralf Baechle, Paul Mundt, Tejun Heo,
linux390, Andrew Morton, agl, David S. Miller
In-Reply-To: <alpine.LRH.2.00.1105131018040.3047@tundra.namei.org>
* James Morris <jmorris@namei.org> wrote:
> On Thu, 12 May 2011, Ingo Molnar wrote:
> > Funnily enough, back then you wrote this:
> >
> > " I'm concerned that we're seeing yet another security scheme being designed on
> > the fly, without a well-formed threat model, and without taking into account
> > lessons learned from the seemingly endless parade of similar, failed schemes. "
> >
> > so when and how did your opinion of this scheme turn from it being an
> > "endless parade of failed schemes" to it being a "well-defined and readily
> > understandable feature"? :-)
>
> When it was defined in a way which limited its purpose to reducing the attack
> surface of the sycall interface.
Let me outline a simple example of a new filter expression based security
feature that could be implemented outside the narrow system call boundary you
find acceptable, and please tell what is bad about it.
Say i'm a user-space sandbox developer who wants to enforce that sandboxed code
should only be allowed to open files in /home/sandbox/, /lib/ and /usr/lib/.
It is a simple and sensible security feature, agreed? It allows most code to
run well and link to countless libraries - but no access to other files is
allowed.
I would also like my sandbox app to be able to install this policy without
having to be root. I do not want the sandbox app to have permission to create
labels on /lib and /usr/lib and what not.
Firstly, using the filter code i deny the various link creation syscalls so
that sandboxed code cannot escape for example by creating a symlink to outside
the permitted VFS namespace. (Note: we opt-in to syscalls, that way new
syscalls added by new kernels are denied by defalt. The current symlink
creation syscalls are not opted in to.)
But the next step, actually checking filenames, poses a big hurdle: i cannot
implement the filename checking at the sys_open() syscall level in a secure
way: because the pathname is passed to sys_open() by pointer, and if i check it
at the generic sys_open() syscall level, another thread in the sandbox might
modify the underlying filename *after* i've checked it.
But if i had a VFS event at the fs/namei.c::getname() level, i would have
access to a central point where the VFS string becomes stable to the kernel and
can be checked (and denied if necessary).
A sidenote, and not surprisingly, the audit subsystem already has an event
callback there:
audit_getname(result);
Unfortunately this audit callback cannot be used for my purposes, because the
event is single-purpose for auditd and because it allows no feedback (no
deny/accept discretion for the security policy).
But if had this simple event there:
err = event_vfs_getname(result);
I could implement this new filename based sandboxing policy, using a filter
like this installed on the vfs::getname event and inherited by all sandboxed
tasks (which cannot uninstall the filter, obviously):
"
if (strstr(name, ".."))
return -EACCESS;
if (!strncmp(name, "/home/sandbox/", 14) &&
!strncmp(name, "/lib/", 5) &&
!strncmp(name, "/usr/lib/", 9))
return -EACCESS;
"
#
# Note1: Obviously the filter engine would be extended to allow such simple string
# match functions. )
#
# Note2: ".." is disallowed so that sandboxed code cannot escape the restrictions
# using "/..".
#
This kind of flexible and dynamic sandboxing would allow a wide range of file
ops within the sandbox, while still isolating it from files not included in the
specified VFS namespace.
( Note that there are tons of other examples as well, for useful security features
that are best done using events outside the syscall boundary. )
The security event filters code tied to seccomp and syscalls at the moment is
useful, but limited in its future potential.
So i argue that it should go slightly further and should become:
- unprivileged: application-definable, allowing the embedding of security
policy in *apps* as well, not just the system
- flexible: can be added/removed runtime unprivileged, and cheaply so
- transparent: does not impact executing code that meets the policy
- nestable: it is inherited by child tasks and is fundamentally stackable,
multiple policies will have the combined effect and they
are transparent to each other. So if a child task within a
sandbox adds *more* checks then those add to the already
existing set of checks. We only narrow permissions, never
extend them.
- generic: allowing observation and (safe) control of security relevant
parameters not just at the system call boundary but at other
relevant places of kernel execution as well: which
points/callbacks could also be used for other types of event
extraction such as perf. It could even be shared with audit ...
I argue that this is the LSM and audit subsystems designed right: in the long
run it could allow everything that LSM does at the moment - and so much more
...
And you argue that allowing this would be bad, if it was extended like that
then you'd consider it a failed scheme? Why?
Thanks,
Ingo
^ permalink raw reply
* [PATHC] Fix for Pegasos keyboard and mouse
From: Gabriel Paubert @ 2011-05-13 11:03 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: pacman, linuxppc-dev
[See http://lists.ozlabs.org/pipermail/linuxppc-dev/2010-October/086424.html
and followups. Part of the commit message is directly copied from that.]
Commit 540c6c392f01887dcc96bef0a41e63e6c1334f01 tries to find i8042 IRQs in
the device-tree but doesn't fall back to the old hardcoded 1 and 12 in all
failure cases.
Specifically, the case where the device-tree contains nothing matching
pnpPNP,303 or pnpPNP,f03 doesn't seem to be handled well. It sort of falls
through to the old code, but leaves the IRQs set to 0.
Signed-off-by: Gabriel Paubert <paubert@iram.es>
---
This fix has only been tested on Pegasos, but to my knowledge it only
affects a Pegasos specific path (all other fimwares should be able
to find the keyboard through the pnp identifiers.
diff --git a/arch/powerpc/kernel/setup-common.c b/arch/powerpc/kernel/setup-common.c
index 21f30cb..6c7abbf 100644
--- a/arch/powerpc/kernel/setup-common.c
+++ b/arch/powerpc/kernel/setup-common.c
@@ -602,6 +602,10 @@ int check_legacy_ioport(unsigned long base_port)
* name instead */
if (!np)
np = of_find_node_by_name(NULL, "8042");
+ if (np) {
+ of_i8042_kbd_irq = 1;
+ of_i8042_aux_irq = 12;
+ }
break;
case FDC_BASE: /* FDC1 */
np = of_find_node_by_type(NULL, "fdc");
^ permalink raw reply related
* RE: [linuxppc-release] [PATCH 1/2] powerpc, e5500: add networking to defconfig
From: Li Yang-R58472 @ 2011-05-13 10:36 UTC (permalink / raw)
To: Wood Scott-B07421; +Cc: linuxppc-dev@lists.ozlabs.org
In-Reply-To: <20110512103135.2c2a037a@schlenkerla.am.freescale.net>
>Subject: Re: [linuxppc-release] [PATCH 1/2] powerpc, e5500: add networking
>to defconfig
>
>On Thu, 12 May 2011 10:31:08 -0500
>Scott Wood <scottwood@freescale.com> wrote:
>
>> On Thu, 12 May 2011 01:11:03 -0500
>> Li Yang-R58472 <R58472@freescale.com> wrote:
>>
>> > >diff --git a/arch/powerpc/configs/e55xx_smp_defconfig
>> > >b/arch/powerpc/configs/e55xx_smp_defconfig
>> > >index 9fa1613..f4c5780 100644
>> > >--- a/arch/powerpc/configs/e55xx_smp_defconfig
>> > >+++ b/arch/powerpc/configs/e55xx_smp_defconfig
>> > >@@ -6,10 +6,10 @@ CONFIG_NR_CPUS=3D2
>> > > CONFIG_EXPERIMENTAL=3Dy
>> > > CONFIG_SYSVIPC=3Dy
>> > > CONFIG_BSD_PROCESS_ACCT=3Dy
>> > >+CONFIG_SPARSE_IRQ=3Dy
>> >
>> > Hi Scott,
>> >
>> > I remember in previous testing that this option has a negative effect
>on performance. Do we really need it to be enabled?
>>
>> I didn't change this setting, it just moved due to running it through
>> savedefconfig.
>
>What was the performance impact?
It adds CPU cycles to the interrupt handling path. Will cause performance =
drop for benchmarks with large amount of interrupts such as IP forwarding.
- Leo
^ permalink raw reply
* Re: fsl_udc_core: BUG: scheduling while atomic
From: Sergej.Stepanov @ 2011-05-13 8:34 UTC (permalink / raw)
To: mlcreech; +Cc: linuxppc-dev
In-Reply-To: <BANLkTim8ntQHkcm_yOgD+UQQb+b+tSoFqA@mail.gmail.com>
SSB3b3VsZCBzYXkgaXQgaXMgYSBnZW5lcmFsIHByb2JsZW0gYnkgdXNpbmcgQ09ORklHX1BSRUVN
UFRfVk9MVU5UQVJZLApub3Qgb25seSBGcmVlc2NhbGUuLi4KCkFtIERvbm5lcnN0YWcsIGRlbiAx
Mi4wNS4yMDExLCAxMTozMCAtMDQwMCBzY2hyaWViIE1hdHRoZXcgTC4gQ3JlZWNoOgo+IE9uIFRo
dSwgTWF5IDEyLCAyMDExIGF0IDQ6MzcgQU0sICA8U2VyZ2VqLlN0ZXBhbm92QGlkcy5kZT4gd3Jv
dGU6Cj4gPiBIaSBNYXR0aGVldywKPiA+Cj4gPiBzdWNoIG9vcHMgeW91IGNhbiBnZXQgYWxzbyB3
aXRoIHNwaS4KPiA+IEZvciBzdWNoIHByb2JsZW0gaGVscHMgdG8gY29tcGlsZSB5b3VyIGtlcm5l
bCB3aXRoIG90aGVyIHByZWVtcHRpb24KPiA+IG1vZGVsOgo+ID4gIC0gcHJlZW1wdAo+ID4gIC0g
c3RhbmRhcmQKPiA+ICAtICEhISBidXQgbm90IHZvbHVudGFyeSBwcmVlbXB0aW9uICEhIQo+IAo+
IFRoYW5rcyBTZXJnZWosIGluZGVlZCBJJ20gY3VycmVudGx5IHVzaW5nIENPTkZJR19QUkVFTVBU
X1ZPTFVOVEFSWSBvbgo+IHRoaXMgYm9hcmQuICBJJ2xsIGNoYW5nZSBpdCB0byBmaXggdGhpcyBw
cm9ibGVtIGZvciBub3cuCj4gCj4gRG8geW91IGhhcHBlbiB0byBrbm93IHdoZXRoZXIgdGhlIEZy
ZWVzY2FsZSBmb2xrcyBpbnRlbmQgdG8gZml4IHRoaXM/Cj4gSWYgbm90LCBpdCBzZWVtcyBsaWtl
IGF0IGxlYXN0IHNvbWUgc29ydCBvZiB3YXJuaW5nIGlzIGluIG9yZGVyLgo+IAo+IC0tIAo+IE1h
dHRoZXcgTC4gQ3JlZWNoCg==
^ permalink raw reply
* Re: [PATCH 3/5] v2 seccomp_filters: Enable ftrace-based system call filtering
From: James Morris @ 2011-05-13 0:18 UTC (permalink / raw)
To: Ingo Molnar
Cc: linux-mips, linux-sh, Peter Zijlstra, Frederic Weisbecker,
Heiko Carstens, Oleg Nesterov, David Howells, Paul Mackerras,
Eric Paris, H. Peter Anvin, sparclinux, Jiri Slaby, linux-s390,
Russell King, x86, Linus Torvalds, Ingo Molnar, linux-arm-kernel,
kees.cook, Serge E. Hallyn, Peter Zijlstra, microblaze-uclinux,
Steven Rostedt, Martin Schwidefsky, Thomas Gleixner,
Roland McGrath, Michal Marek, Michal Simek, Will Drewry,
linuxppc-dev, linux-kernel, Ralf Baechle, Paul Mundt, Tejun Heo,
linux390, Andrew Morton, agl, David S. Miller
In-Reply-To: <20110512130104.GA2912@elte.hu>
On Thu, 12 May 2011, Ingo Molnar wrote:
> Funnily enough, back then you wrote this:
>
> " I'm concerned that we're seeing yet another security scheme being designed on
> the fly, without a well-formed threat model, and without taking into account
> lessons learned from the seemingly endless parade of similar, failed schemes. "
>
> so when and how did your opinion of this scheme turn from it being an "endless
> parade of failed schemes" to it being a "well-defined and readily
> understandable feature"? :-)
When it was defined in a way which limited its purpose to reducing the
attack surface of the sycall interface.
- James
--
James Morris
<jmorris@namei.org>
^ permalink raw reply
* [PATCH] powerpc/pseries: Enable iSCSI support for a number of cards
From: Anton Blanchard @ 2011-05-12 22:23 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev
In-Reply-To: <20110509091930.2e784e54@kryten>
Enable iSCSI support for a number of cards. We had the base
networking devices enabled but forgot to enable iSCSI.
Signed-off-by: Anton Blanchard <anton@samba.org>
---
v2: I added the bnx2 iscsi twice.
Index: junk/arch/powerpc/configs/pseries_defconfig
===================================================================
--- junk.orig/arch/powerpc/configs/pseries_defconfig 2011-05-13 08:03:17.122419568 +1000
+++ junk/arch/powerpc/configs/pseries_defconfig 2011-05-13 08:03:43.962869252 +1000
@@ -146,12 +146,17 @@ CONFIG_SCSI_MULTI_LUN=y
CONFIG_SCSI_CONSTANTS=y
CONFIG_SCSI_FC_ATTRS=y
CONFIG_SCSI_SAS_ATTRS=m
+CONFIG_SCSI_CXGB3_ISCSI=m
+CONFIG_SCSI_CXGB4_ISCSI=m
+CONFIG_SCSI_BNX2_ISCSI=m
+CONFIG_BE2ISCSI=m
CONFIG_SCSI_IBMVSCSI=y
CONFIG_SCSI_IBMVFC=m
CONFIG_SCSI_SYM53C8XX_2=y
CONFIG_SCSI_SYM53C8XX_DMA_ADDRESSING_MODE=0
CONFIG_SCSI_IPR=y
CONFIG_SCSI_QLA_FC=m
+CONFIG_SCSI_QLA_ISCSI=m
CONFIG_SCSI_LPFC=m
CONFIG_ATA=y
# CONFIG_ATA_SFF is not set
^ permalink raw reply
* Re: [PATCH] fix build warnings on defconfigs
From: Ralf Baechle @ 2011-05-12 21:57 UTC (permalink / raw)
To: wanlong.gao
Cc: linux-mips, david.woodhouse, tony, nicolas.ferre, paulus, eric,
sam, sfr, linux, khilman, manuel.lauss, u.kleine-koenig, mingo,
rientjes, anton, ben-linux, linux-arm-kernel, linux-kernel,
santosh.shilimkar, akpm, linuxppc-dev, hans-christian.egtvedt
In-Reply-To: <1302375858-11253-1-git-send-email-wanlong.gao@gmail.com>
On Sun, Apr 10, 2011 at 03:04:18AM +0800, wanlong.gao@gmail.com wrote:
> Subject: [PATCH] fix build warnings on defconfigs
>
> From: Wanlong Gao <wanlong.gao@gmail.com>
>
> Change the BT_L2CAP and BT_SCO defconfigs from 'm' to 'y',
> since BT_L2CAP and BT_SCO had changed to bool configs.
>
> Signed-off-by: Wanlong Gao <wanlong.gao@gmail.com>
I've queued the MIPS bits only for 2.6.40. Thanks.
Ralf
^ permalink raw reply
* mpc8xx IDE hard drive enumeration
From: Burton Samograd @ 2011-05-12 21:27 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 2863 bytes --]
Hello list,
I'm currently attempting to get Linux running on a custom board and have
gotten to the point of trying to get our IDE FlashCard working. I have
ported u-boot and have the flash card working as expected (as in being
able to read and write sectors) so it looks like it is possible to get
it working in Linux with the parameters I have setup (this is using
CONFIG_IDE_8XX_DIRECT and the various CFG_PCMCIA_* parameters).
I have built the kernel with IDE Block Device support and have selected
the MPC8xx IDE support as well, using 8xx_DIRECT as the interface. I
have ensured that my parameters for PCMCIA match those of u-boot. I get
the following on bootup with regards to the IDE subsystem (having
defined DEBUG and added some additional debugging into in
drivers/ide/ppc/mpc8xx.c):
...
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 50MHz system bus speed for PIO modes; override with
idebus=xx
win->br: 0xfe100000, PCMCIA_MEM_SIZE: 0x80, pcmcia_phy_end: 0xfe100080
win->br: 0xfe100080, PCMCIA_MEM_SIZE: 0x80, pcmcia_phy_end: 0xfe100100
win->br: 0xfe100100, PCMCIA_MEM_SIZE: 0x80, pcmcia_phy_end: 0xfe100180
win->br: 0xfe100c00, PCMCIA_MEM_SIZE: 0x80, pcmcia_phy_end: 0xfe100c80
win->br: 0xfe100c80, PCMCIA_MEM_SIZE: 0x80, pcmcia_phy_end: 0xfe100d00
win->br: 0xfe100d00, PCMCIA_MEM_SIZE: 0x80, pcmcia_phy_end: 0xfe100d80
PCMCIA slot A: phys mem fe100000...fe100d80 (size 00000d80)
PCMCIA virt base: c1000000
base: c1000000 + 00000000 = c1000000
port[0]: c1000000 + 00000000 = c1000000
port[1]: c1000000 + 00000081 = c1000081
port[2]: c1000000 + 00000082 = c1000082
port[3]: c1000000 + 00000083 = c1000083
port[4]: c1000000 + 00000084 = c1000084
port[5]: c1000000 + 00000085 = c1000085
port[6]: c1000000 + 00000086 = c1000086
port[7]: c1000000 + 00000087 = c1000087
port[8]: c1000000 + 00000106 = c1000106
port[9]: c1000000 + 0000000a = c100000a
...
The IDE driver is calling m8xx_ide_init_hwif_ports successfully (not so
if I define 8xx_PCCARD) and from the source it just seems to be getting
the PCMCIA parameters that are setup by u-boot. Everything seems fine
up to this point.
Now, I'm wondering, why is it not enumerating the drives on the found
hwif ports? Would I need to specify the drives on the command line, or
some other step that I might be missing? Can anyone see anything
drastically wrong with the PCMCIA parameters (even though they seem to
work fine with u-boot).
We are using a rather old kernel (2.6.12 I think, with customizations
for our hardware), but this is a rather old custom board with very
limited ram so we are attempting to get the older kernel working first
before looking into upgrading.
Any help appreciated.
--
Burton Samograd
[-- Attachment #2: Type: text/html, Size: 8867 bytes --]
^ permalink raw reply
* RE: [PATCH 0/1] ppc4xx: Fix PCIe scanning for the 460SX
From: Tirumala Marri @ 2011-05-12 18:16 UTC (permalink / raw)
To: Ayman El-Khashab; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <20110509160935.GA14965@crust.elkhashab.com>
So what is the best way to handle this? It appears (based
on the comments of others and my own experience) that there
is no DCR that exists and behaves the way that previous SOCs
behaved to give us the link status? The register above
PECFGn_DLLSTA is actually in the PCIe configuration space so
we would have to map that in to be able to read that
register during the link check. Is that correct or ok?
[marri] yes, you need to program DCR register access these local PCIE_CFG
registers.
I've communicated with some people over email and they had
tried the (PESDRn_HSSLySTS) register. Recognizing that
there exists one of these for each port/lane, is there a way
to use this one? It is in the indirect DCR space. I'd
tried this myself and never did get it to do anything but I
could have been looking at the wrong lane or something.
[marri]This is at SERDES level. If this link up doesn't necessarily
Overall stack is up. This is mostly used for BIST and diagnostics.
Lastly, what was the reason for forcing the original code to
be GEN-1 speeds?
[marri] Gen-2 need some extra checks compared to Gen-1.
There were not many Gen-2 devices at the time of submission
To test them.
^ permalink raw reply
* Re: [PATCH 3/5] v2 seccomp_filters: Enable ftrace-based system call filtering
From: Will Drewry @ 2011-05-12 16:26 UTC (permalink / raw)
To: Ingo Molnar
Cc: linux-mips, linux-sh, Peter Zijlstra, Frederic Weisbecker,
Heiko Carstens, Oleg Nesterov, David Howells, Paul Mackerras,
Eric Paris, H. Peter Anvin, sparclinux, Jiri Slaby, linux-s390,
Russell King, x86, James Morris, Linus Torvalds, Ingo Molnar,
linux-arm-kernel, kees.cook, Serge E. Hallyn, Peter Zijlstra,
microblaze-uclinux, Steven Rostedt, Martin Schwidefsky,
Thomas Gleixner, Roland McGrath, Michal Marek, Michal Simek,
linuxppc-dev, linux-kernel, Ralf Baechle, Paul Mundt, Tejun Heo,
linux390, Andrew Morton, agl, David S. Miller
In-Reply-To: <20110512130104.GA2912@elte.hu>
[Thanks to everyone for the continued feedback and insights - I appreciate =
it!]
On Thu, May 12, 2011 at 8:01 AM, Ingo Molnar <mingo@elte.hu> wrote:
>
> * James Morris <jmorris@namei.org> wrote:
>
>> On Thu, 12 May 2011, Ingo Molnar wrote:
>>
>> > 2) Why should this concept not be made available wider, to allow the
>> > =A0 =A0restriction of not just system calls but other security relevan=
t components
>> > =A0 =A0of the kernel as well?
>>
>> Because the aim of this is to reduce the attack surface of the syscall
>> interface.
>
> What i suggest achieves the same, my argument is that we could aim it to =
be
> even more flexible and even more useful.
>
>> LSM is the correct level of abstraction for general security mediation,
>> because it allows you to take into account all relevant security informa=
tion
>> in a race-free context.
>
> I don't care about LSM though, i find it poorly designed.
>
> The approach implemented here, the ability for *unprivileged code* to def=
ine
> (the seeds of ...) flexible security policies, in a proper Linuxish way, =
which
> is inherited along the task parent/child hieararchy and which allows nest=
ing
> etc. is a *lot* more flexible.
>
> What Will implemented here is pretty huge in my opinion: it turns securit=
y from
> a root-only kind of weird hack into an essential component of its APIs,
> available to *any* app not just the select security policy/mechanism chos=
en by
> the distributor ...
>
> If implemented properly this could replace LSM in the long run.
>
> As a prctl() hack bound to seccomp (which, by all means, is a natural ext=
ension
> to the current seccomp ABI, so perfectly fine if we only want that scope)=
, that
> is much less likely to happen.
>
> And if we merge the seccomp interface prematurely then interest towards a=
more
> flexible approach will disappear, so either we do it properly now or it w=
ill
> take some time for someone to come around and do it ...
>
> Also note that i do not consider the perf events ABI itself cast into sto=
ne -
> and we could very well add a new system call for this, independent of per=
f
> events. I just think that the seccomp scope itself is exciting but looks
> limited to what the real potential of this could be.
I agree with you on many of these points! However, I don't think that
the views around LSMs, perf/ftrace infrastructure, or the current
seccomp filtering implementation are necessarily in conflict. Here is
my understanding of how the different worlds fit together and where I
see this patchset living, along with where I could see future work
going. Perhaps I'm being a trifle naive, but here goes anyway:
1. LSMs provide a global mechanism for hooking "security relevant"
events at a point where all the incoming user-sourced data has been
preprocessed and moved into userspace. The hooks are called every
time one of those boundaries are crossed.
2. Perf and the ftrace infrastructure provide global function tracing
and system call hooks with direct access to the caller's registers
(and memory).
3. seccomp (as it exists today) provides a global system call entry
hook point with a binary per-process decision about whether to provide
"secure computing" behavior.
When I boil that down to abstractions, I see:
A. Globally scoped: LSMs, ftrace/perf
B. Locally/process scoped: seccomp
The result of that logical equivalence is that I see room for:
I. A per-process, locally scoped security event hooking interface (the
proposed changes in this patchset)
II. A globally scoped security event hooking interface _prior_ to
argument processing
III. A globally scoped security event hooking interface _post_
argument processing
II and III could be reduced further if I assume that ftrace/perf
provides (II) and a simple intermediary layer (hook entry/exit)
provides the argument processing steps that then call out a global
security policy system.
The driving motivation for this patchset is kernel attack surface
reduction, but that need arises because we lack a process-scoped
mechanism for making security decisions -- everything is global:
creds/DAC, containers, LSM, etc. Adding ftrace filtering to agl's
original bitmask-seccomp proposal opens up the process-local security
world. At present, it can limit the attack surface with simple binary
filters or apply limited security policy through the use of filter
strings.
Based on your mails, I see two main deficiencies in my proposed patchset:
a. Deep argument analysis: Any arguments that live in user memory
needs to be copied into the kernel, then checked, and substituted for
the actual system call, then have the original pointers restored (when
applicable) on system call exit. There is a large overhead here and
the LSM hooks provide much of this support on a global level.
b. Lack of support for non-system call events.
For (a), if the long term view of ftrace/perf & LSMs is that LSM-like
functionality will live on top of the ftrace/perf infrastructure, then
adding support for the intermediary layer to analyze arguments will
come with time. It's also likely that for process-local stuff (e.g.,)
a new predicate could be added to callback to a userspace supervisor,
or even a more generic ability for modules to register new
predicates/functions in the filtering engine itself -- like "fd =3D=3D 1
&& check_path(path) =3D=3D '/etc/safe.conf'" or "check_xattr(path,
expected)". Of course, I'm just making stuff up right now :)
For (b), we could just add a field we don't use right now in the prctl
interface:
prctl(PR_SET_SECCOMP_FILTER, int event_type, int
event_or_syscall_nr, char *filter)
[or something similar]
Then we can add process-local/scoped supported event types somewhere
down the road without an ABI change.
Tying it all together, it'd look like:
* Now -- add process-scoped security support: secocmp filter with
support for "future" event types
* Soon -- expand ftrace syscall hooks to hook more system calls
* Later -- expand ftrace filter language to support either deep
argument analysis and/or custom registered predicates
* Later, later -- implement a LSM-like hooking layer for "interesting"
event types on top of the ftrace hooks
That would yield process-scoped security controls and global security
controls and the ability to continue to create new and interesting
security modules.
All that said, I'm in over my head. I've focused primarily on the
process-scoped security. I think James, some of the LSM authors, and
out-of-tree security system maintainers would be good to help guide
direction toward the security view you have in mind to ensure the
flexibility desired exists. And that's even assuming this sketch is
even vaguely interesting...
[snip]
> What i do here is to suggest *further* steps down the same road, now that=
we
> see that this scheme can indeed be used to implement sandboxing ... I thi=
nk
> it's a valid line of inquiry.
I certainly agree that it's a valid line of inquiry, but I worry about
the massive scope expansion. I know it hurts my head, but I'm hoping
the brain-dump above frames up how I think about this patch and your
line of inquiry. ftrace hooking and the perf code certainly look a
lot like LSMs if I squint hard :) But there is a substantial amount
of work to merge the worlds, and (thankfully) I don't think that
future directly impacts process-scoped security mechanisms even if
they can interact nicely.
thanks!
will
^ permalink raw reply
* Re: [linuxppc-release] [PATCH 1/2] powerpc, e5500: add networking to defconfig
From: Scott Wood @ 2011-05-12 15:31 UTC (permalink / raw)
To: Scott Wood
Cc: Wood Scott-B07421, linuxppc-dev@lists.ozlabs.org, Li Yang-R58472
In-Reply-To: <20110512103108.6dd3ca2a@schlenkerla.am.freescale.net>
On Thu, 12 May 2011 10:31:08 -0500
Scott Wood <scottwood@freescale.com> wrote:
> On Thu, 12 May 2011 01:11:03 -0500
> Li Yang-R58472 <R58472@freescale.com> wrote:
>
> > >diff --git a/arch/powerpc/configs/e55xx_smp_defconfig
> > >b/arch/powerpc/configs/e55xx_smp_defconfig
> > >index 9fa1613..f4c5780 100644
> > >--- a/arch/powerpc/configs/e55xx_smp_defconfig
> > >+++ b/arch/powerpc/configs/e55xx_smp_defconfig
> > >@@ -6,10 +6,10 @@ CONFIG_NR_CPUS=2
> > > CONFIG_EXPERIMENTAL=y
> > > CONFIG_SYSVIPC=y
> > > CONFIG_BSD_PROCESS_ACCT=y
> > >+CONFIG_SPARSE_IRQ=y
> >
> > Hi Scott,
> >
> > I remember in previous testing that this option has a negative effect on performance. Do we really need it to be enabled?
>
> I didn't change this setting, it just moved due to running it through
> savedefconfig.
What was the performance impact?
-Scott
^ permalink raw reply
* Re: [linuxppc-release] [PATCH 1/2] powerpc, e5500: add networking to defconfig
From: Scott Wood @ 2011-05-12 15:31 UTC (permalink / raw)
To: Li Yang-R58472; +Cc: Wood Scott-B07421, linuxppc-dev@lists.ozlabs.org
In-Reply-To: <3F607A5180246847A760FD34122A1E0514EC65@039-SN1MPN1-002.039d.mgd.msft.net>
On Thu, 12 May 2011 01:11:03 -0500
Li Yang-R58472 <R58472@freescale.com> wrote:
> >Subject: [linuxppc-release] [PATCH 1/2] powerpc, e5500: add networking to
> >defconfig
> >
> >Even though support for the p5020's on-chip ethernet is not yet upstream,
> >it is not appropriate to disable all networking support (including
> >loopback, unix domain sockets, external ethernet devices, etc) in the
> >defconfig. The networking settings are taken from mpc85xx_smp_defconfig,
> >minus the drivers for ethernet devices not found on any current e5500 chip.
> >
> >The other changes are the result of running "make savedefconfig".
> >
> >Signed-off-by: Scott Wood <scottwood@freescale.com>
> >---
> > arch/powerpc/configs/e55xx_smp_defconfig | 38 ++++++++++++++++++++++---
> >----
> > 1 files changed, 29 insertions(+), 9 deletions(-)
> >
> >diff --git a/arch/powerpc/configs/e55xx_smp_defconfig
> >b/arch/powerpc/configs/e55xx_smp_defconfig
> >index 9fa1613..f4c5780 100644
> >--- a/arch/powerpc/configs/e55xx_smp_defconfig
> >+++ b/arch/powerpc/configs/e55xx_smp_defconfig
> >@@ -6,10 +6,10 @@ CONFIG_NR_CPUS=2
> > CONFIG_EXPERIMENTAL=y
> > CONFIG_SYSVIPC=y
> > CONFIG_BSD_PROCESS_ACCT=y
> >+CONFIG_SPARSE_IRQ=y
>
> Hi Scott,
>
> I remember in previous testing that this option has a negative effect on performance. Do we really need it to be enabled?
I didn't change this setting, it just moved due to running it through
savedefconfig.
-Scott
^ permalink raw reply
* Re: fsl_udc_core: BUG: scheduling while atomic
From: Matthew L. Creech @ 2011-05-12 15:30 UTC (permalink / raw)
To: Sergej.Stepanov; +Cc: linuxppc-dev
In-Reply-To: <4206182445660643B9AEB8D4E55BBD0A1533BC2780@HERMES2>
On Thu, May 12, 2011 at 4:37 AM, <Sergej.Stepanov@ids.de> wrote:
> Hi Mattheew,
>
> such oops you can get also with spi.
> For such problem helps to compile your kernel with other preemption
> model:
> =A0- preempt
> =A0- standard
> =A0- !!! but not voluntary preemption !!!
Thanks Sergej, indeed I'm currently using CONFIG_PREEMPT_VOLUNTARY on
this board. I'll change it to fix this problem for now.
Do you happen to know whether the Freescale folks intend to fix this?
If not, it seems like at least some sort of warning is in order.
--=20
Matthew L. Creech
^ permalink raw reply
* Re: [PATCH] seqlock: don't smp_rmb in seqlock reader spin loop
From: Andi Kleen @ 2011-05-12 14:08 UTC (permalink / raw)
To: Milton Miller
Cc: Nick Piggin, Eric Dumazet, Ingo Molnar, linux-kernel,
Linus Torvalds, Andi Kleen, Anton Blanchard, Andrew Morton,
linuxppc-dev, Thomas Gleixner
In-Reply-To: <seqlock-rmb@mdm.bga.com>
On Thu, May 12, 2011 at 04:13:54AM -0500, Milton Miller wrote:
>
> Move the smp_rmb after cpu_relax loop in read_seqlock and add
> ACCESS_ONCE to make sure the test and return are consistent.
>
> A multi-threaded core in the lab didn't like the update
Which core was that?
-Andi
^ permalink raw reply
* Re: [PATCH 3/5] v2 seccomp_filters: Enable ftrace-based system call filtering
From: Ingo Molnar @ 2011-05-12 13:01 UTC (permalink / raw)
To: James Morris
Cc: linux-mips, linux-sh, Peter Zijlstra, Frederic Weisbecker,
Heiko Carstens, Oleg Nesterov, David Howells, Paul Mackerras,
Eric Paris, H. Peter Anvin, sparclinux, Jiri Slaby, linux-s390,
Russell King, x86, Linus Torvalds, Ingo Molnar, linux-arm-kernel,
kees.cook, Serge E. Hallyn, Peter Zijlstra, microblaze-uclinux,
Steven Rostedt, Martin Schwidefsky, Thomas Gleixner,
Roland McGrath, Michal Marek, Michal Simek, Will Drewry,
linuxppc-dev, linux-kernel, Ralf Baechle, Paul Mundt, Tejun Heo,
linux390, Andrew Morton, agl, David S. Miller
In-Reply-To: <alpine.LRH.2.00.1105122133500.31507@tundra.namei.org>
* James Morris <jmorris@namei.org> wrote:
> On Thu, 12 May 2011, Ingo Molnar wrote:
>
> > 2) Why should this concept not be made available wider, to allow the
> > restriction of not just system calls but other security relevant components
> > of the kernel as well?
>
> Because the aim of this is to reduce the attack surface of the syscall
> interface.
What i suggest achieves the same, my argument is that we could aim it to be
even more flexible and even more useful.
> LSM is the correct level of abstraction for general security mediation,
> because it allows you to take into account all relevant security information
> in a race-free context.
I don't care about LSM though, i find it poorly designed.
The approach implemented here, the ability for *unprivileged code* to define
(the seeds of ...) flexible security policies, in a proper Linuxish way, which
is inherited along the task parent/child hieararchy and which allows nesting
etc. is a *lot* more flexible.
What Will implemented here is pretty huge in my opinion: it turns security from
a root-only kind of weird hack into an essential component of its APIs,
available to *any* app not just the select security policy/mechanism chosen by
the distributor ...
If implemented properly this could replace LSM in the long run.
As a prctl() hack bound to seccomp (which, by all means, is a natural extension
to the current seccomp ABI, so perfectly fine if we only want that scope), that
is much less likely to happen.
And if we merge the seccomp interface prematurely then interest towards a more
flexible approach will disappear, so either we do it properly now or it will
take some time for someone to come around and do it ...
Also note that i do not consider the perf events ABI itself cast into stone -
and we could very well add a new system call for this, independent of perf
events. I just think that the seccomp scope itself is exciting but looks
limited to what the real potential of this could be.
> > This too, if you approach the problem via the events code, will be a natural
> > end result, while if you approach it from the seccomp prctl angle it will be
> > a limited hack only.
>
> I'd say it's a well-defined and readily understandable feature.
Note, it was me who suggested this very event-filter-engine design a year ago,
when the first submission still used a crude bitmap of allowed seccomp
syscalls:
http://lwn.net/Articles/332974/
Funnily enough, back then you wrote this:
" I'm concerned that we're seeing yet another security scheme being designed on
the fly, without a well-formed threat model, and without taking into account
lessons learned from the seemingly endless parade of similar, failed schemes. "
so when and how did your opinion of this scheme turn from it being an "endless
parade of failed schemes" to it being a "well-defined and readily
understandable feature"? :-)
The idea itself has not changed since last year, what happened is that the
filter engine got a couple of new features and Will has separated it out and
has implemented a working prototype for sandboxing.
What i do here is to suggest *further* steps down the same road, now that we
see that this scheme can indeed be used to implement sandboxing ... I think
it's a valid line of inquiry.
Thanks,
Ingo
^ permalink raw reply
* RE: [PATCH] RapidIO: Fix default routing initialization
From: Bounine, Alexandre @ 2011-05-12 12:37 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, Thomas Moll, linuxppc-dev
In-Reply-To: <20110511130024.955f1981.akpm@linux-foundation.org>
Andrew Morton <akpm@linux-foundation.org> wrote:
=20
> The changelog doesn't permit me to determine the importance of this
> fix,
> so I don't know whether to schedule it for 2.6.39 or for -stable.
Sorry, my fault. This patch is applicable to kernel versions starting
from 2.6.37.
^ permalink raw reply
* Re: [PATCH 3/5] v2 seccomp_filters: Enable ftrace-based system call filtering
From: James Morris @ 2011-05-12 11:33 UTC (permalink / raw)
To: Will Drewry
Cc: linux-mips, linux-sh, Peter Zijlstra, Frederic Weisbecker,
Heiko Carstens, Oleg Nesterov, David Howells, Paul Mackerras,
Eric Paris, H. Peter Anvin, sparclinux, Jiri Slaby, linux-s390,
Russell King, x86, Ingo Molnar, linux-arm-kernel, kees.cook,
Serge E. Hallyn, Peter Zijlstra, microblaze-uclinux,
Steven Rostedt, Martin Schwidefsky, Thomas Gleixner, Ingo Molnar,
Roland McGrath, Michal Marek, Michal Simek, linuxppc-dev,
linux-kernel, Ralf Baechle, Paul Mundt, Tejun Heo, linux390,
Andrew Morton, agl, David S. Miller
In-Reply-To: <1305169376-2363-1-git-send-email-wad@chromium.org>
On Wed, 11 May 2011, Will Drewry wrote:
> +void seccomp_filter_log_failure(int syscall)
> +{
> + printk(KERN_INFO
> + "%s[%d]: system call %d (%s) blocked at ip:%lx\n",
> + current->comm, task_pid_nr(current), syscall,
> + syscall_nr_to_name(syscall), KSTK_EIP(current));
> +}
I think it'd be a good idea to utilize the audit facility here.
- James
--
James Morris
<jmorris@namei.org>
^ permalink raw reply
* Re: [PATCH 3/5] v2 seccomp_filters: Enable ftrace-based system call filtering
From: Frederic Weisbecker @ 2011-05-12 12:15 UTC (permalink / raw)
To: Ingo Molnar
Cc: linux-mips, linux-sh, Peter Zijlstra, Heiko Carstens,
Oleg Nesterov, David Howells, Paul Mackerras, Eric Paris,
H. Peter Anvin, sparclinux, Jiri Slaby, linux-s390, Russell King,
x86, jmorris, Linus Torvalds, Ingo Molnar, linux-arm-kernel,
kees.cook, Serge E. Hallyn, Peter Zijlstra, microblaze-uclinux,
Steven Rostedt, Martin Schwidefsky, Thomas Gleixner,
Roland McGrath, Michal Marek, Michal Simek, Will Drewry,
linuxppc-dev, linux-kernel, Ralf Baechle, Paul Mundt, Tejun Heo,
linux390, Andrew Morton, agl, David S. Miller
In-Reply-To: <20110512074850.GA9937@elte.hu>
On Thu, May 12, 2011 at 09:48:50AM +0200, Ingo Molnar wrote:
> To restrict execution to system calls.
>
> Two observations:
>
> 1) We already have a specific ABI for this: you can set filters for events via
> an event fd.
>
> Why not extend that mechanism instead and improve *both* your sandboxing
> bits and the events code? This new seccomp code has a lot more
> to do with trace event filters than the minimal old seccomp code ...
>
> kernel/trace/trace_event_filter.c is 2000 lines of tricky code that
> interprets the ASCII filter expressions. kernel/seccomp.c is 86 lines of
> mostly trivial code.
>
> 2) Why should this concept not be made available wider, to allow the
> restriction of not just system calls but other security relevant components
> of the kernel as well?
>
> This too, if you approach the problem via the events code, will be a natural
> end result, while if you approach it from the seccomp prctl angle it will be
> a limited hack only.
>
> Note, the end result will be the same - just using a different ABI.
>
> So i really think the ABI itself should be closer related to the event code.
> What this "seccomp" code does is that it uses specific syscall events to
> restrict execution of certain event generating codepaths, such as system calls.
>
> Thanks,
>
> Ingo
What's positive with that approach is that the code is all there already.
Create a perf event for a given trace event, attach a filter to it.
What needs to be added is an override of the effect of the filter. By default
it's dropping the event, but there may be different flavours, including sending
a signal. All in one, extending the current code to allow that looks trivial.
The negative points are that
* trace events are supposed to stay passive and not act on the system, except
doing some endpoint things like writing to a buffer. We can't call do_exit()
from a tracepoint for example, preemption is disabled there.
* Also, is it actually relevant to extend that seccomp filtering to other events
than syscalls? Exposing kernel events to filtering sounds actually to me bringing
a new potential security issue. But with fine restrictions this can probably
be dealt with. Especially if by default only syscalls can be filtered
* I think Peter did not want to give such "active" role to perf in the system.
^ permalink raw reply
* Re: [PATCH 03/13] kvm/powerpc: Fix the build for 32-bit Book 3S (classic) processors
From: Alexander Graf @ 2011-05-12 11:57 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: linuxppc-dev@ozlabs.org, Paul Mackerras, kvm@vger.kernel.org
In-Reply-To: <1305198979.29820.102.camel@pasglop>
Am 12.05.2011 um 13:16 schrieb Benjamin Herrenschmidt <benh@kernel.crashing.=
org>:
> On Thu, 2011-05-12 at 11:33 +0200, Alexander Graf wrote:
>> Am 11.05.2011 um 12:39 schrieb Paul Mackerras <paulus@samba.org>:
>>=20
>>> Commits a5d4f3ad3a ("powerpc: Base support for exceptions using
>>> HSRR0/1") and 673b189a2e ("powerpc: Always use SPRN_SPRG_HSCRATCH0
>>> when running in HV mode") cause compile and link errors for 32-bit
>>> classic Book 3S processors when KVM is enabled. This fixes these
>>> errors.
>>>=20
>>> Signed-off-by: Paul Mackerras <paulus@samba.org>
>>> ---
>>> arch/powerpc/include/asm/reg.h | 5 +++++
>>> arch/powerpc/kvm/book3s_rmhandlers.S | 2 ++
>>> 2 files changed, 7 insertions(+), 0 deletions(-)
>>>=20
>>> diff --git a/arch/powerpc/include/asm/reg.h b/arch/powerpc/include/asm/r=
eg.h
>>> index 47e3416..05658b7 100644
>>> --- a/arch/powerpc/include/asm/reg.h
>>> +++ b/arch/powerpc/include/asm/reg.h
>>> @@ -823,6 +823,11 @@
>>> FTR_SECTION_ELSE_NESTED(66); \
>>> mtspr SPRN_SPRG_HSCRATCH0,rX; \
>>> ALT_FTR_SECTION_END_NESTED_IFCLR(CPU_FTR_HVMODE_206, 66)
>>> +
>>> +#else /* CONFIG_PPC_BOOK3S_64 */
>>> +#define GET_SCRATCH0(rX) mfspr rX,SPRN_SPRG_SCRATCH0
>>> +#define SET_SCRATCH0(rX) mtspr SPRN_SPRG_SCRATCH0,rX
>>> +
>>> #endif
>>>=20
>>> #ifdef CONFIG_PPC_BOOK3E_64
>>> diff --git a/arch/powerpc/kvm/book3s_rmhandlers.S b/arch/powerpc/kvm/boo=
k3s_rmhandlers.S
>>> index ae99af6..1a1b344 100644
>>> --- a/arch/powerpc/kvm/book3s_rmhandlers.S
>>> +++ b/arch/powerpc/kvm/book3s_rmhandlers.S
>>> @@ -112,7 +112,9 @@ INTERRUPT_TRAMPOLINE BOOK3S_INTERRUPT_MACHINE_CHE=
CK
>>> INTERRUPT_TRAMPOLINE BOOK3S_INTERRUPT_DATA_STORAGE
>>> INTERRUPT_TRAMPOLINE BOOK3S_INTERRUPT_INST_STORAGE
>>> INTERRUPT_TRAMPOLINE BOOK3S_INTERRUPT_EXTERNAL
>>> +#ifdef CONFIG_PPC_BOOK3S_64
>>> INTERRUPT_TRAMPOLINE BOOK3S_INTERRUPT_EXTERNAL_HV
>>=20
>> Hrm - I don't remember putting this one here. When did it get into the tr=
ee and why wasn't I CC'ed?
>=20
> Because I did and I forgot :-)
>=20
> The patch in question only marginally touched kvm, it's one in a series
> that rework of the ppc64 exception vectors to better operate on modern
> CPUs running in HV mode (deal with HSRR's vs SRR's etc...) and it needed
> a small fixup to the KVM code due to 0x500 becoming "H" interrupts
> (using HSRR's) on these.
>=20
> Unfortunately, it looks like I didn't have KVM enabled in any of my
> 32-bit test configs and missed that little breakage.
>=20
> I should have CCed you I suppose, I simply forgot as it wasn't primarily
> a KVM related patch.
Alright :). Don't worry too much about it - just wanted to make sure you'll r=
emember next time ;)
Alex
>=20
^ permalink raw reply
* Re: [PATCH 3/5] v2 seccomp_filters: Enable ftrace-based system call filtering
From: James Morris @ 2011-05-12 11:44 UTC (permalink / raw)
To: Ingo Molnar
Cc: linux-mips, linux-sh, Peter Zijlstra, Frederic Weisbecker,
Heiko Carstens, Oleg Nesterov, David Howells, Paul Mackerras,
Eric Paris, H. Peter Anvin, sparclinux, Jiri Slaby, linux-s390,
Russell King, x86, Linus Torvalds, Ingo Molnar, linux-arm-kernel,
kees.cook, Serge E. Hallyn, Peter Zijlstra, microblaze-uclinux,
Steven Rostedt, Martin Schwidefsky, Thomas Gleixner,
Roland McGrath, Michal Marek, Michal Simek, Will Drewry,
linuxppc-dev, linux-kernel, Ralf Baechle, Paul Mundt, Tejun Heo,
linux390, Andrew Morton, agl, David S. Miller
In-Reply-To: <20110512074850.GA9937@elte.hu>
On Thu, 12 May 2011, Ingo Molnar wrote:
>
> 2) Why should this concept not be made available wider, to allow the
> restriction of not just system calls but other security relevant components
> of the kernel as well?
Because the aim of this is to reduce the attack surface of the syscall
interface.
LSM is the correct level of abstraction for general security mediation,
because it allows you to take into account all relevant security
information in a race-free context.
> This too, if you approach the problem via the events code, will be a natural
> end result, while if you approach it from the seccomp prctl angle it will be
> a limited hack only.
I'd say it's a well-defined and readily understandable feature.
- James
--
James Morris
<jmorris@namei.org>
^ permalink raw reply
* Re: [PATCH 03/13] kvm/powerpc: Fix the build for 32-bit Book 3S (classic) processors
From: Benjamin Herrenschmidt @ 2011-05-12 11:16 UTC (permalink / raw)
To: Alexander Graf
Cc: linuxppc-dev@ozlabs.org, Paul Mackerras, kvm@vger.kernel.org
In-Reply-To: <C5B8A119-56B6-467C-B3BD-01D5D7FA0773@suse.de>
On Thu, 2011-05-12 at 11:33 +0200, Alexander Graf wrote:
> Am 11.05.2011 um 12:39 schrieb Paul Mackerras <paulus@samba.org>:
>
> > Commits a5d4f3ad3a ("powerpc: Base support for exceptions using
> > HSRR0/1") and 673b189a2e ("powerpc: Always use SPRN_SPRG_HSCRATCH0
> > when running in HV mode") cause compile and link errors for 32-bit
> > classic Book 3S processors when KVM is enabled. This fixes these
> > errors.
> >
> > Signed-off-by: Paul Mackerras <paulus@samba.org>
> > ---
> > arch/powerpc/include/asm/reg.h | 5 +++++
> > arch/powerpc/kvm/book3s_rmhandlers.S | 2 ++
> > 2 files changed, 7 insertions(+), 0 deletions(-)
> >
> > diff --git a/arch/powerpc/include/asm/reg.h b/arch/powerpc/include/asm/reg.h
> > index 47e3416..05658b7 100644
> > --- a/arch/powerpc/include/asm/reg.h
> > +++ b/arch/powerpc/include/asm/reg.h
> > @@ -823,6 +823,11 @@
> > FTR_SECTION_ELSE_NESTED(66); \
> > mtspr SPRN_SPRG_HSCRATCH0,rX; \
> > ALT_FTR_SECTION_END_NESTED_IFCLR(CPU_FTR_HVMODE_206, 66)
> > +
> > +#else /* CONFIG_PPC_BOOK3S_64 */
> > +#define GET_SCRATCH0(rX) mfspr rX,SPRN_SPRG_SCRATCH0
> > +#define SET_SCRATCH0(rX) mtspr SPRN_SPRG_SCRATCH0,rX
> > +
> > #endif
> >
> > #ifdef CONFIG_PPC_BOOK3E_64
> > diff --git a/arch/powerpc/kvm/book3s_rmhandlers.S b/arch/powerpc/kvm/book3s_rmhandlers.S
> > index ae99af6..1a1b344 100644
> > --- a/arch/powerpc/kvm/book3s_rmhandlers.S
> > +++ b/arch/powerpc/kvm/book3s_rmhandlers.S
> > @@ -112,7 +112,9 @@ INTERRUPT_TRAMPOLINE BOOK3S_INTERRUPT_MACHINE_CHECK
> > INTERRUPT_TRAMPOLINE BOOK3S_INTERRUPT_DATA_STORAGE
> > INTERRUPT_TRAMPOLINE BOOK3S_INTERRUPT_INST_STORAGE
> > INTERRUPT_TRAMPOLINE BOOK3S_INTERRUPT_EXTERNAL
> > +#ifdef CONFIG_PPC_BOOK3S_64
> > INTERRUPT_TRAMPOLINE BOOK3S_INTERRUPT_EXTERNAL_HV
>
> Hrm - I don't remember putting this one here. When did it get into the tree and why wasn't I CC'ed?
Because I did and I forgot :-)
The patch in question only marginally touched kvm, it's one in a series
that rework of the ppc64 exception vectors to better operate on modern
CPUs running in HV mode (deal with HSRR's vs SRR's etc...) and it needed
a small fixup to the KVM code due to 0x500 becoming "H" interrupts
(using HSRR's) on these.
Unfortunately, it looks like I didn't have KVM enabled in any of my
32-bit test configs and missed that little breakage.
I should have CCed you I suppose, I simply forgot as it wasn't primarily
a KVM related patch.
Cheers,
Ben.
^ permalink raw reply
* Re: [PATCH 03/13] kvm/powerpc: Fix the build for 32-bit Book 3S (classic) processors
From: Paul Mackerras @ 2011-05-12 11:15 UTC (permalink / raw)
To: Alexander Graf; +Cc: linuxppc-dev@ozlabs.org, kvm@vger.kernel.org
In-Reply-To: <C5B8A119-56B6-467C-B3BD-01D5D7FA0773@suse.de>
On Thu, May 12, 2011 at 11:33:00AM +0200, Alexander Graf wrote:
>
> Am 11.05.2011 um 12:39 schrieb Paul Mackerras <paulus@samba.org>:
>
> > diff --git a/arch/powerpc/kvm/book3s_rmhandlers.S b/arch/powerpc/kvm/book3s_rmhandlers.S
> > index ae99af6..1a1b344 100644
> > --- a/arch/powerpc/kvm/book3s_rmhandlers.S
> > +++ b/arch/powerpc/kvm/book3s_rmhandlers.S
> > @@ -112,7 +112,9 @@ INTERRUPT_TRAMPOLINE BOOK3S_INTERRUPT_MACHINE_CHECK
> > INTERRUPT_TRAMPOLINE BOOK3S_INTERRUPT_DATA_STORAGE
> > INTERRUPT_TRAMPOLINE BOOK3S_INTERRUPT_INST_STORAGE
> > INTERRUPT_TRAMPOLINE BOOK3S_INTERRUPT_EXTERNAL
> > +#ifdef CONFIG_PPC_BOOK3S_64
> > INTERRUPT_TRAMPOLINE BOOK3S_INTERRUPT_EXTERNAL_HV
>
> Hrm - I don't remember putting this one here. When did it get into
> the tree and why wasn't I CC'ed?
It comes from commit a5d4f3ad3a ("powerpc: Base support for exceptions
using HSRR0/1", author Ben H.) in Ben's next branch. He committed it
on April 20.
Paul.
^ permalink raw reply
* Re: powerpc: Make early memory scan more resilient to out of order nodes
From: Benjamin Herrenschmidt @ 2011-05-12 11:08 UTC (permalink / raw)
To: Milton Miller; +Cc: linuxppc-dev
In-Reply-To: <benh-inital-memory@mdm.bga.com>
On Thu, 2011-05-12 at 03:09 -0500, Milton Miller wrote:
> On Wed, 11 May 2011 about 20:58:18 -0000, Benjamin Herrenschmidt wrote:
> > We keep track of the size of the lowest block of memory and call
> > setup_initial_memory_limit() only after we've parsed them all
> >
>
> Good, we lose our sensitivity to device node ordering.
Yup, A platform we'll release soon has all of them backward :-)
> > diff --git a/arch/powerpc/kernel/prom.c b/arch/powerpc/kernel/prom.c
>
> > index 584b398..27475c6 100644
> > --- a/arch/powerpc/kernel/prom.c
> > +++ b/arch/powerpc/kernel/prom.c
> > @@ -70,6 +70,7 @@ int __initdata iommu_force_on;
> > unsigned long tce_alloc_start, tce_alloc_end;
> > u64 ppc64_rma_size;
> > #endif
> > +static phys_addr_t first_memblock_size;
>
> __initdata
>
> (its only referenced by 2 __init functions)
>
> Acked-by: Milton Miller <miltonm@bga.com>
Ag good, I'll fold that in, thanks.
Cheers,
Ben.
>
> > static int __init early_parse_mem(char *p)
> > {
> ..
> > @@ -507,11 +508,14 @@ void __init early_init_dt_add_memory_arch(u64 base, u64 size)
> ..
> > @@ -708,6 +712,7 @@ void __init early_init_devtree(void *params)
^ permalink raw reply
* Re: [PATCH 3/5] v2 seccomp_filters: Enable ftrace-based system call filtering
From: Ingo Molnar @ 2011-05-12 10:49 UTC (permalink / raw)
To: Kees Cook
Cc: linux-mips, linux-sh, Peter Zijlstra, Frederic Weisbecker,
Heiko Carstens, Oleg Nesterov, David Howells, Paul Mackerras,
Eric Paris, H. Peter Anvin, sparclinux, Jiri Slaby, linux-s390,
Russell King, x86, jmorris, Linus Torvalds, Ingo Molnar,
linux-arm-kernel, Serge E. Hallyn, Peter Zijlstra,
microblaze-uclinux, Steven Rostedt, Martin Schwidefsky,
Thomas Gleixner, Roland McGrath, Michal Marek, Michal Simek,
Will Drewry, linuxppc-dev, linux-kernel, Ralf Baechle, Paul Mundt,
Tejun Heo, linux390, Andrew Morton, agl, David S. Miller
In-Reply-To: <20110512092424.GO28888@outflux.net>
* Kees Cook <kees.cook@canonical.com> wrote:
> Hi,
>
> On Thu, May 12, 2011 at 09:48:50AM +0200, Ingo Molnar wrote:
> > 1) We already have a specific ABI for this: you can set filters for events via
> > an event fd.
> >
> > Why not extend that mechanism instead and improve *both* your sandboxing
> > bits and the events code? This new seccomp code has a lot more
> > to do with trace event filters than the minimal old seccomp code ...
>
> Would this require privileges to get the event fd to start with? [...]
No special privileges with the default perf_events_paranoid value.
> [...] If so, I would prefer to avoid that, since using prctl() as shown in
> the patch set won't require any privs.
and we could also explicitly allow syscall events without any privileges,
regardless of the setting of 'perf_events_paranoid' config value.
Obviously a sandboxing host process wants to run with as low privileges as it
can.
Thanks,
Ingo
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox