All of lore.kernel.org
 help / color / mirror / Atom feed
diff for duplicates of <1529427588.23068.7.camel@intel.com>

diff --git a/a/1.txt b/N1/1.txt
index 55827b7..df69956 100644
--- a/a/1.txt
+++ b/N1/1.txt
@@ -47,3 +47,7 @@ If ptrace can turn CET on/off and it is thread-specific, do we still
 need ptrace lock/unlock?
 
 Yu-cheng
+--
+To unsubscribe from this list: send the line "unsubscribe linux-doc" in
+the body of a message to majordomo@vger.kernel.org
+More majordomo info at  http://vger.kernel.org/majordomo-info.html
diff --git a/a/content_digest b/N1/content_digest
index 40a558d..5bd2f7e 100644
--- a/a/content_digest
+++ b/N1/content_digest
@@ -90,6 +90,10 @@
  "If ptrace can turn CET on/off and it is thread-specific, do we still\n"
  "need ptrace lock/unlock?\n"
  "\n"
- Yu-cheng
+ "Yu-cheng\n"
+ "--\n"
+ "To unsubscribe from this list: send the line \"unsubscribe linux-doc\" in\n"
+ "the body of a message to majordomo@vger.kernel.org\n"
+ More majordomo info at  http://vger.kernel.org/majordomo-info.html
 
-4a6593c8dbfd0174af326ef9c2c446e16c2a4b515efbdd2c8e60a4578b52e406
+cd11238c609383951ddf3bfdaa064fd59370f88e8d7e32eb5e4833731f07ba08

diff --git a/a/1.txt b/N2/1.txt
index 55827b7..de72b7c 100644
--- a/a/1.txt
+++ b/N2/1.txt
@@ -10,7 +10,7 @@ On Tue, 2018-06-19 at 09:44 -0700, Kees Cook wrote:
 > > > (with a
 > > > warning about down-grades), and allow distros/end-users to pick
 > > > "forced" if they know their libraries are all CET-enabled.
-> > I still don’t get what “relaxed” is for.  I think the right design
+> > I still dona??t get what a??relaxeda?? is for.A A I think the right design
 > > is:
 > > 
 > > Processes start with CET on or off depending on the ELF note, but
@@ -21,17 +21,17 @@ On Tue, 2018-06-19 at 09:44 -0700, Kees Cook wrote:
 > I'm fine with this. I'd expect modern loaders to just turn on CET and
 > ARCH_CET_LOCK immediately and be done with it. :P
 
-This is the current implementation.  If the loader has CET in its ELF
-header, it is executed with CET on.  The loader will turn off CET if
+This is the current implementation. A If the loader has CET in its ELF
+header, it is executed with CET on. A The loader will turn off CET if
 the application being loaded does not support it (in the ELF header).
- The loader calls ARCH_CET_LOCK before passing to the application.  But
+A The loader calls ARCH_CET_LOCK before passing to the application. A But
 how do we handle dlopen?
 
 > > 
 > > Ptrace gets new APIs to turn CET on and off and to lock and unlock
-> > it.  If an attacker finds a “ptrace me and turn off CET” gadget,
-> > then they might as well just do “ptrace me and write shell code”
-> > instead. It’s basically the same gadget. Keep in mind that the
+> > it.A A If an attacker finds a a??ptrace me and turn off CETa?? gadget,
+> > then they might as well just do a??ptrace me and write shell codea??
+> > instead. Ita??s basically the same gadget. Keep in mind that the
 > > actual sequence of syscalls to do this is incredibly complicated.
 > Right -- if an attacker can control ptrace of the target, we're way
 > past CET. The only concern I have, though, is taking advantage of
diff --git a/a/content_digest b/N2/content_digest
index 40a558d..2e7573e 100644
--- a/a/content_digest
+++ b/N2/content_digest
@@ -54,7 +54,7 @@
  "> > > (with a\n"
  "> > > warning about down-grades), and allow distros/end-users to pick\n"
  "> > > \"forced\" if they know their libraries are all CET-enabled.\n"
- "> > I still don\342\200\231t get what \342\200\234relaxed\342\200\235 is for.\302\240\302\240I think the right design\n"
+ "> > I still dona??t get what a??relaxeda?? is for.A A I think the right design\n"
  "> > is:\n"
  "> > \n"
  "> > Processes start with CET on or off depending on the ELF note, but\n"
@@ -65,17 +65,17 @@
  "> I'm fine with this. I'd expect modern loaders to just turn on CET and\n"
  "> ARCH_CET_LOCK immediately and be done with it. :P\n"
  "\n"
- "This is the current implementation. \302\240If the loader has CET in its ELF\n"
- "header, it is executed with CET on. \302\240The loader will turn off CET if\n"
+ "This is the current implementation. A If the loader has CET in its ELF\n"
+ "header, it is executed with CET on. A The loader will turn off CET if\n"
  "the application being loaded does not support it (in the ELF header).\n"
- "\302\240The loader calls ARCH_CET_LOCK before passing to the application. \302\240But\n"
+ "A The loader calls ARCH_CET_LOCK before passing to the application. A But\n"
  "how do we handle dlopen?\n"
  "\n"
  "> > \n"
  "> > Ptrace gets new APIs to turn CET on and off and to lock and unlock\n"
- "> > it.\302\240\302\240If an attacker finds a \342\200\234ptrace me and turn off CET\342\200\235 gadget,\n"
- "> > then they might as well just do \342\200\234ptrace me and write shell code\342\200\235\n"
- "> > instead. It\342\200\231s basically the same gadget. Keep in mind that the\n"
+ "> > it.A A If an attacker finds a a??ptrace me and turn off CETa?? gadget,\n"
+ "> > then they might as well just do a??ptrace me and write shell codea??\n"
+ "> > instead. Ita??s basically the same gadget. Keep in mind that the\n"
  "> > actual sequence of syscalls to do this is incredibly complicated.\n"
  "> Right -- if an attacker can control ptrace of the target, we're way\n"
  "> past CET. The only concern I have, though, is taking advantage of\n"
@@ -92,4 +92,4 @@
  "\n"
  Yu-cheng
 
-4a6593c8dbfd0174af326ef9c2c446e16c2a4b515efbdd2c8e60a4578b52e406
+b849326342a83deca021441eab3347fcc3936a2ed866a76c8145ec1104f25865

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.