[EMAIL PROTECTED] wrote:
> HI! IF I TEACH YOU HO TO DO RESUME FROM INITRD, WILL YOU TEST IT AND PROPERLY
> DOCUMENT? :-) --P
My Pleasure!
I can test on x86_64 and I am willing to document.
--
Andreas Steinmetz SPAMmers use [EMAIL PROTECTED]
-
To unsubscribe from this
Pavel Machek wrote:
> Hi!
>
>
2) An attacker breaks into your machine remotely while you're using
it. He has access to all your RAM, which if you're actually using it,
very likely including the same IPSEC, dm_crypt, and ssh-agent keys as
are saved on suspend. Further, he can
Hi!
> > > 2) An attacker breaks into your machine remotely while you're using
> > > it. He has access to all your RAM, which if you're actually using it,
> > > very likely including the same IPSEC, dm_crypt, and ssh-agent keys as
> > > are saved on suspend. Further, he can trivially capture your
Hi!
2) An attacker breaks into your machine remotely while you're using
it. He has access to all your RAM, which if you're actually using it,
very likely including the same IPSEC, dm_crypt, and ssh-agent keys as
are saved on suspend. Further, he can trivially capture your
Pavel Machek wrote:
Hi!
2) An attacker breaks into your machine remotely while you're using
it. He has access to all your RAM, which if you're actually using it,
very likely including the same IPSEC, dm_crypt, and ssh-agent keys as
are saved on suspend. Further, he can trivially capture your
[EMAIL PROTECTED] wrote:
HI! IF I TEACH YOU HO TO DO RESUME FROM INITRD, WILL YOU TEST IT AND PROPERLY
DOCUMENT? :-) --P
My Pleasure!
I can test on x86_64 and I am willing to document.
--
Andreas Steinmetz SPAMmers use [EMAIL PROTECTED]
-
To unsubscribe from this list:
On Wed, Jul 27, 2005 at 01:12:49AM +0200, Pavel Machek wrote:
> Hi!
>
> > > Well, "how long are my keys going to stay in swap after
> > > swsusp"... that's pretty scary.
> >
> > Either they're likely in RAM _anyway_ and are thus already trivially
> > accessible to the attacker (for things like
Hi!
> > Well, "how long are my keys going to stay in swap after
> > swsusp"... that's pretty scary.
>
> Either they're likely in RAM _anyway_ and are thus already trivially
> accessible to the attacker (for things like dm_crypt or IPSEC or
> ssh-agent), or the application took care to zero them
On Wed, Jul 27, 2005 at 12:14:46AM +0200, Pavel Machek wrote:
> Hi!
>
> > > > the attached patches are acked by Pavel and signed off by me
> > >
> > > OK, well I queued this up, without a changelog. Because you didn't send
> > > one. Please do so. As it adds a new feature, quite a bit of info
Hi!
> > > the attached patches are acked by Pavel and signed off by me
> >
> > OK, well I queued this up, without a changelog. Because you didn't send
> > one. Please do so. As it adds a new feature, quite a bit of info is
> > relevant.
>
> I don't like this patch. It reinvents a fair amount
Hi!
> > > the attached patches are acked by Pavel and signed off by me
> >
> > OK, well I queued this up, without a changelog. Because you didn't send
> > one. Please do so. As it adds a new feature, quite a bit of info is
> > relevant.
>
> I don't like this patch. It reinvents a fair amount
On Mon, Jul 25, 2005 at 08:10:36PM -0700, Andrew Morton wrote:
> Andreas Steinmetz <[EMAIL PROTECTED]> wrote:
> >
> > the attached patches are acked by Pavel and signed off by me
>
> OK, well I queued this up, without a changelog. Because you didn't send
> one. Please do so. As it adds a new
On Mon, Jul 25, 2005 at 08:10:36PM -0700, Andrew Morton wrote:
Andreas Steinmetz [EMAIL PROTECTED] wrote:
the attached patches are acked by Pavel and signed off by me
OK, well I queued this up, without a changelog. Because you didn't send
one. Please do so. As it adds a new feature,
Hi!
the attached patches are acked by Pavel and signed off by me
OK, well I queued this up, without a changelog. Because you didn't send
one. Please do so. As it adds a new feature, quite a bit of info is
relevant.
I don't like this patch. It reinvents a fair amount of dm_crypt
Hi!
the attached patches are acked by Pavel and signed off by me
OK, well I queued this up, without a changelog. Because you didn't send
one. Please do so. As it adds a new feature, quite a bit of info is
relevant.
I don't like this patch. It reinvents a fair amount of dm_crypt
On Wed, Jul 27, 2005 at 12:14:46AM +0200, Pavel Machek wrote:
Hi!
the attached patches are acked by Pavel and signed off by me
OK, well I queued this up, without a changelog. Because you didn't send
one. Please do so. As it adds a new feature, quite a bit of info is
Hi!
Well, how long are my keys going to stay in swap after
swsusp... that's pretty scary.
Either they're likely in RAM _anyway_ and are thus already trivially
accessible to the attacker (for things like dm_crypt or IPSEC or
ssh-agent), or the application took care to zero them out, or
On Wed, Jul 27, 2005 at 01:12:49AM +0200, Pavel Machek wrote:
Hi!
Well, how long are my keys going to stay in swap after
swsusp... that's pretty scary.
Either they're likely in RAM _anyway_ and are thus already trivially
accessible to the attacker (for things like dm_crypt or IPSEC
Andreas Steinmetz <[EMAIL PROTECTED]> wrote:
>
> the attached patches are acked by Pavel and signed off by me
OK, well I queued this up, without a changelog. Because you didn't send
one. Please do so. As it adds a new feature, quite a bit of info is
relevant.
It should include a description
Andreas Steinmetz [EMAIL PROTECTED] wrote:
the attached patches are acked by Pavel and signed off by me
OK, well I queued this up, without a changelog. Because you didn't send
one. Please do so. As it adds a new feature, quite a bit of info is
relevant.
It should include a description of
Andrew Morton wrote:
> Pavel Machek <[EMAIL PROTECTED]> wrote:
>
>>To prevent data gathering from swap after resume you can encrypt the
>>suspend image with a temporary key that is deleted on resume. Note
>>that the temporary key is stored unencrypted on disk while the system
>>is suspended...
Andrew Morton wrote:
Pavel Machek [EMAIL PROTECTED] wrote:
To prevent data gathering from swap after resume you can encrypt the
suspend image with a temporary key that is deleted on resume. Note
that the temporary key is stored unencrypted on disk while the system
is suspended... still it means
On Wed, 6 Jul 2005, Pavel Machek wrote:
Hi!
To prevent data gathering from swap after resume you can encrypt the
suspend image with a temporary key that is deleted on resume. Note
that the temporary key is stored unencrypted on disk while the system
is suspended... still it means that saved
Hi!
> > To prevent data gathering from swap after resume you can encrypt the
> > suspend image with a temporary key that is deleted on resume. Note
> > that the temporary key is stored unencrypted on disk while the system
> > is suspended... still it means that saved data are wiped from disk
> >
Pavel Machek <[EMAIL PROTECTED]> wrote:
>
> To prevent data gathering from swap after resume you can encrypt the
> suspend image with a temporary key that is deleted on resume. Note
> that the temporary key is stored unencrypted on disk while the system
> is suspended... still it means that saved
Pavel Machek [EMAIL PROTECTED] wrote:
To prevent data gathering from swap after resume you can encrypt the
suspend image with a temporary key that is deleted on resume. Note
that the temporary key is stored unencrypted on disk while the system
is suspended... still it means that saved data
Hi!
To prevent data gathering from swap after resume you can encrypt the
suspend image with a temporary key that is deleted on resume. Note
that the temporary key is stored unencrypted on disk while the system
is suspended... still it means that saved data are wiped from disk
during
On Wed, 6 Jul 2005, Pavel Machek wrote:
Hi!
To prevent data gathering from swap after resume you can encrypt the
suspend image with a temporary key that is deleted on resume. Note
that the temporary key is stored unencrypted on disk while the system
is suspended... still it means that saved
28 matches
Mail list logo
