Hello,
apologies for the delayed answer.
Please find my reply to both last mails in the thread, below.
On 22/11/2018 22:53, Andy Lutomirski wrote:
On Thu, Nov 22, 2018 at 12:04 PM Matthew Wilcox wrote:
On Thu, Nov 22, 2018 at 09:27:02PM +0200, Igor Stoppa wrote:
I have studied the code
On 21/11/2018 20:15, Andy Lutomirski wrote:
On Nov 21, 2018, at 9:34 AM, Igor Stoppa wrote:
[...]
There might be other reasons for replicating the mm_struct.
If I understand correctly how the text patching works, it happens sequentially,
because of the text_mutex used by
On 21/11/2018 19:36, Nadav Amit wrote:
On Nov 21, 2018, at 8:34 AM, Igor Stoppa wrote:
[...]
There might be other reasons for replicating the mm_struct.
If I understand correctly how the text patching works, it happens sequentially,
because of the text_mutex used by
Hi,
On 13/11/2018 20:36, Andy Lutomirski wrote:
On Tue, Nov 13, 2018 at 10:33 AM Igor Stoppa wrote:
I forgot one sentence :-(
On 13/11/2018 20:31, Igor Stoppa wrote:
On 13/11/2018 19:47, Andy Lutomirski wrote:
For general rare-writish stuff, I don't think we want IRQs running
with
On 13/11/2018 20:48, Andy Lutomirski wrote:
> On Tue, Nov 13, 2018 at 10:31 AM Igor Stoppa wrote:
>>
>> On 13/11/2018 19:47, Andy Lutomirski wrote:
>>
>>> For general rare-writish stuff, I don't think we want IRQs running
>>> with them mapped anywher
On 13/11/2018 20:36, Andy Lutomirski wrote:
> On Tue, Nov 13, 2018 at 10:33 AM Igor Stoppa wrote:
[...]
>> Unless the secondary mapping is also available to other cores, through
>> the shared mm_struct ?
>>
>
> I don't think this matters much. The other cores
On 13/11/2018 20:35, Andy Lutomirski wrote:
> On Tue, Nov 13, 2018 at 10:26 AM Igor Stoppa wrote:
[...]
>> The high level API could be something like:
>>
>> wr_memcpy(void *src, void *dst, uint_t size)
[...]
> If you call a wr_memcpy() function with the signature y
I forgot one sentence :-(
On 13/11/2018 20:31, Igor Stoppa wrote:
> On 13/11/2018 19:47, Andy Lutomirski wrote:
>
>> For general rare-writish stuff, I don't think we want IRQs running
>> with them mapped anywhere for write. For AVC and IMA, I'm less sure.
>
>
On 13/11/2018 19:47, Andy Lutomirski wrote:
> For general rare-writish stuff, I don't think we want IRQs running
> with them mapped anywhere for write. For AVC and IMA, I'm less sure.
Why would these be less sensitive?
But I see a big difference between my initial implementation and this one.
On 13/11/2018 19:16, Andy Lutomirski wrote:
> On Tue, Nov 13, 2018 at 6:25 AM Igor Stoppa wrote:
[...]
>> How about having one mm_struct for each writer (core or thread)?
>>
>
> I don't think that helps anything. I think the mm_struct used for
> prmem (or rare_
Hello,
I've been studying v4 of the patch-set [1] that Nadav has been working on.
Incidentally, I think it would be useful to cc also the
security/hardening ml.
The patch-set seems to be close to final, so I am resuming this discussion.
On 30/10/2018 19:06, Andy Lutomirski wrote:
I support th
On 01/11/2018 10:21, Thomas Gleixner wrote:
On Thu, 1 Nov 2018, Igor Stoppa wrote:
The rework could be done afterward.
Please don't go there. The usual approach is to
1) Rework existing code in a way that the new functionality can be added
with minimal effort afterward
Hello Ahmed,
On 01/11/2018 01:21, Ahmed Soliman wrote:
Hello Igor,
This is very interesting, because it seems a very good match to the work
I'm doing, for supporting the creation of more targets for protection:
https://www.openwall.com/lists/kernel-hardening/2018/10/23/3
In my case the protec
On 01/11/2018 01:19, Andy Lutomirski wrote:
ISTM you don't need that atomic operation -- you could take a spinlock
and then just add one directly to the variable.
It was my intention to provide a 1:1 conversion of existing code, as it
should be easier to verify the correctness of the conve
On 01/11/2018 00:57, Andy Lutomirski wrote:
On Oct 31, 2018, at 2:00 PM, Peter Zijlstra wrote:
I _think_ the use-case for atomics is updating the reference counts of
objects that are in this write-rare domain. But I'm not entirely clear
on that myself either. I just really want to avo
On 31/10/2018 11:08, Igor Stoppa wrote:
Adding SELinux folks and the SELinux ml
I think it's better if they participate in this discussion.
On 31/10/2018 06:41, Andy Lutomirski wrote:
On Tue, Oct 30, 2018 at 2:36 PM Matthew Wilcox
wrote:
On Tue, Oct 30, 2018 at 10:43:14PM +0200,
On 30/10/2018 18:37, Kees Cook wrote:
On Tue, Oct 30, 2018 at 8:26 AM, Peter Zijlstra wrote:
I suppose the 'normal' attack goes like:
1) find buffer-overrun / bound check failure
2) use that to write to 'interesting' location
3) that write results arbitrary code execution
4) win
Of
Adding SELinux folks and the SELinux ml
I think it's better if they participate in this discussion.
On 31/10/2018 06:41, Andy Lutomirski wrote:
On Tue, Oct 30, 2018 at 2:36 PM Matthew Wilcox wrote:
On Tue, Oct 30, 2018 at 10:43:14PM +0200, Igor Stoppa wrote:
On 30/10/2018 21:20, Ma
On 30/10/2018 23:02, Andy Lutomirski wrote:
On Oct 30, 2018, at 1:43 PM, Igor Stoppa wrote:
There is no need to process each of these tens of thousands allocations and
initialization as write-rare.
Would it be possible to do the same here?
I don’t see why not, although getting the
On 30/10/2018 23:25, Matthew Wilcox wrote:
On Tue, Oct 30, 2018 at 11:51:17AM -0700, Andy Lutomirski wrote:
Finally, one issue: rare_alloc() is going to utterly suck
performance-wise due to the global IPI when the region gets zapped out
of the direct map or otherwise made RO. This is the sam
On 30/10/2018 23:35, Matthew Wilcox wrote:
On Tue, Oct 30, 2018 at 10:43:14PM +0200, Igor Stoppa wrote:
Would it be possible to do the same here?
What Andy is proposing effectively puts all rare allocations into
one pool. Although I suppose it could be generalised to multiple pools
On 30/10/2018 23:07, Kees Cook wrote:
We still have to deal with certain structures under the write-rare
window. For example, see:
https://git.kernel.org/pub/scm/linux/kernel/git/kees/linux.git/commit/?h=kspp/write-rarely&id=60430b4d3b113aae4adab66f8339074986276474
They are wrappers to non-in
On 30/10/2018 21:20, Matthew Wilcox wrote:
On Tue, Oct 30, 2018 at 12:28:41PM -0600, Tycho Andersen wrote:
On Tue, Oct 30, 2018 at 10:58:14AM -0700, Matthew Wilcox wrote:
On Tue, Oct 30, 2018 at 10:06:51AM -0700, Andy Lutomirski wrote:
On Oct 30, 2018, at 9:37 AM, Kees Cook wrote:
I support
On 28/10/2018 18:31, Peter Zijlstra wrote:
On Fri, Oct 26, 2018 at 11:46:28AM +0100, Kees Cook wrote:
On Fri, Oct 26, 2018 at 10:26 AM, Peter Zijlstra wrote:
I still don't really understand the whole write-rare thing; how does it
really help? If we can write in kernel memory, we can write to
On 26/10/2018 10:26, Peter Zijlstra wrote:
+- Kernel code is protected at system level and, unlike data, it doesn't
+ require special attention.
What does this even mean?
I was trying to convey the notion that the pages containing kernel code
do not require any special handling by the auth
On 26/10/2018 16:05, Jonathan Corbet wrote:
But
could I ask you, please, to make a pass over it and reduce the markup to
a minimum? Using lists as suggested by Markus would help here.
sure, it's even easier for me to maintain the doc :-)
as i just wrote in a related reply, it might be worth
On 26/10/2018 12:09, Markus Heiser wrote:
I guess Igor was looking for a definition list ...
It was meant to be bold.
Even after reading the guideline "keep it simple", what exactly is
simple can be subjective.
If certain rst constructs are not acceptable and can be detected
unequivocally,
On 26/10/2018 11:20, Matthew Wilcox wrote:
On Fri, Oct 26, 2018 at 11:26:09AM +0200, Peter Zijlstra wrote:
Jon,
So the below document is a prime example for why I think RST sucks. As a
text document readability is greatly diminished by all the markup
nonsense.
This stuff should not become w
Hello,
On 25/10/2018 00:04, Mike Rapoport wrote:
I feel that foreword should include a sentence or two saying why we need
the memory protection and when it can/should be used.
I was somewhat lost about the actual content of this sort of document.
In past reviews of older version of the docs,
Hi,
On 26/10/2018 16:12, Ahmed Abd El Mawgood wrote:
This is the 5th version which is 4th version with minor fixes. ROE is a
hypercall that enables host operating system to restrict guest's access to its
own memory. This will provide a hardening mechanism that can be used to stop
rootkits from
Hi,
On 24/10/18 06:48, Randy Dunlap wrote:
Hi,
On 10/23/18 2:34 PM, Igor Stoppa wrote:
[...]
+- The present document doesn't address such transient.
transience.
ok
[...]
+ are attempted after the write protection is in place,
Documentation for protected memory.
Topics covered:
* static memory allocation
* dynamic memory allocation
* write-rare
Signed-off-by: Igor Stoppa
CC: Jonathan Corbet
CC: Randy Dunlap
CC: Mike Rapoport
CC: linux-doc@vger.kernel.org
CC: linux-ker...@vger.kernel.org
---
Documentation/core-api
32 matches
Mail list logo
