On Wed, 24 Jul 2024 14:32:51 +, Raymond Hackley wrote:
> Touch keys feature on fortuna phones are provided by Zinitix touchscreen.
> Add property linux,keycodes to enable touch keys.
>
>
Applied, thanks!
[1/1] arm64: dts: qcom: msm8916-samsung-fortuna: Add touch keys
On 24.07.2024 4:32 PM, Raymond Hackley wrote:
> Touch keys feature on fortuna phones are provided by Zinitix touchscreen.
> Add property linux,keycodes to enable touch keys.
>
> Signed-off-by: Raymond Hackley
> ---
please bump the revision (v1 -> v2) when changing the commi
Touch keys feature on fortuna phones are provided by Zinitix touchscreen.
Add property linux,keycodes to enable touch keys.
Signed-off-by: Raymond Hackley
---
arch/arm64/boot/dts/qcom/msm8916-samsung-fortuna-common.dtsi | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm64/boot/dts
> See the "In case your patch fixes a bug.." paragraph in:
>
> https://docs.kernel.org/process/submitting-patches.html
Hi Konrad,
the point is not to fix a bug, but to add touchkeys support instead.
I will reword the patch when it's confusing.
Regards,
Raymond
On 23.07.2024 3:39 PM, Raymond Hackley wrote:
>> Fixes?
>>
>> Konrad
>
> Hi Konrad,
>
> the issue is not reported or discussed on lkml, so there is no thread to fix?
See the "In case your patch fixes a bug.." paragraph in:
https://docs.kernel.org/process/submitting-patches.html
>
> Regards,
>
> Fixes?
>
> Konrad
Hi Konrad,
the issue is not reported or discussed on lkml, so there is no thread to fix?
Regards,
Raymond
On 23.07.2024 3:12 PM, Raymond Hackley wrote:
> The phone needs the touchkeys to be enabled so the sense lines of the
> touch controller are mapped properly. Otherwise the touchscreen is not
> mapped to the display properly.
>
> Signed-off-by: Raymond Hackley
> ---
Fixes?
Konrad
The phone needs the touchkeys to be enabled so the sense lines of the
touch controller are mapped properly. Otherwise the touchscreen is not
mapped to the display properly.
Signed-off-by: Raymond Hackley
---
arch/arm64/boot/dts/qcom/msm8916-samsung-fortuna-common.dtsi | 2 ++
1 file changed, 2
On Tue, Apr 19, 2005 at 04:31:47AM +, David Wagner wrote:
> Theodore Ts'o wrote:
> >For one, /dev/urandom and /dev/random don't use the same pool
> >(anymore). They used to, a long time ago, but certainly as of the
> >writing of the paper this was no longer true. This invalidates the
>
On Tue, Apr 19, 2005 at 04:31:47AM +, David Wagner wrote:
Theodore Ts'o wrote:
For one, /dev/urandom and /dev/random don't use the same pool
(anymore). They used to, a long time ago, but certainly as of the
writing of the paper this was no longer true. This invalidates the
entire last
Theodore Ts'o <[EMAIL PROTECTED]> writes:
> With a properly set up set of init scripts, /dev/random is
> initialized with seed material for all but the initial boot
What about CD-ROM based distros (e.g., Knoppix), where every boot is
the initial boot?
> (and even that problem can be solved by
Theodore Ts'o [EMAIL PROTECTED] writes:
With a properly set up set of init scripts, /dev/random is
initialized with seed material for all but the initial boot
What about CD-ROM based distros (e.g., Knoppix), where every boot is
the initial boot?
(and even that problem can be solved by having
Theodore Ts'o wrote:
>For one, /dev/urandom and /dev/random don't use the same pool
>(anymore). They used to, a long time ago, but certainly as of the
>writing of the paper this was no longer true. This invalidates the
>entire last paragraph of Section 5.3.
Ok, you're right, this is a serious
On Mon, Apr 18, 2005 at 09:40:37PM +, David Wagner wrote:
> Yes, that is a minor glitch, but I believe all their points remain
> valid nonetheless. My advice is to apply the appropriate s/MD5/SHA1/g
> substitution, and re-read the paper to see what you can get out of it.
>
> The problem is
Matt Mackall wrote:
>On Sat, Apr 16, 2005 at 01:08:47AM +, David Wagner wrote:
>> http://eprint.iacr.org/2005/029
>
>Unfortunately, this paper's analysis of /dev/random is so shallow that
>they don't even know what hash it's using. Almost all of section 5.3
>is wrong (and was when I read it
[please reply to all when posting to lkml]
On Sat, Apr 16, 2005 at 01:08:47AM +, David Wagner wrote:
> >First, a reminder that the design goal of /dev/random proper is
> >information-theoretic security. That is, it should be secure against
> >an attacker with infinite computational power.
>
[please reply to all when posting to lkml]
On Sat, Apr 16, 2005 at 01:08:47AM +, David Wagner wrote:
First, a reminder that the design goal of /dev/random proper is
information-theoretic security. That is, it should be secure against
an attacker with infinite computational power.
I am
Matt Mackall wrote:
On Sat, Apr 16, 2005 at 01:08:47AM +, David Wagner wrote:
http://eprint.iacr.org/2005/029
Unfortunately, this paper's analysis of /dev/random is so shallow that
they don't even know what hash it's using. Almost all of section 5.3
is wrong (and was when I read it
On Mon, Apr 18, 2005 at 09:40:37PM +, David Wagner wrote:
Yes, that is a minor glitch, but I believe all their points remain
valid nonetheless. My advice is to apply the appropriate s/MD5/SHA1/g
substitution, and re-read the paper to see what you can get out of it.
The problem is not
Theodore Ts'o wrote:
For one, /dev/urandom and /dev/random don't use the same pool
(anymore). They used to, a long time ago, but certainly as of the
writing of the paper this was no longer true. This invalidates the
entire last paragraph of Section 5.3.
Ok, you're right, this is a serious
ion.
> You are right to ask questions about whether this is a reasonable assumption.
>
> I don't know whether /dev/random makes the same assumption. I suspect that
> its entropy estimator is making a similar assumption (not exactly the same
> one), but I don't know for sure.
Well, the entr
for sure.
Well, the entropy *accumulator* doesn't use any such assumption.
Fortuna uses the independence assumption when it divides up the seed
material round-robin among the various subpools. The current /dev/random
doesn't do anything like that. (Of course, non-independence affects
us by limiting
Jean-Luc Cooke wrote:
>The part which suggests choosing an irreducible poly and a value "a" in the
>preprocessing stage ... last I checked the value for a and the poly need to
>be secret. How do you generate poly and a, Catch-22? Perhaps I'm missing
>something and someone can point it out.
I
linux wrote:
>Thank you for pointing out the paper; Appendix A is particularly
>interesting. And the [BST03] reference looks *really* nice! I haven't
>finished it yet, but based on what I've read so far, I'd like to
>*strongly* recommnd that any would-be /dev/random hackers read it
>carefully.
usible example.
>
> Consider a Fortuna-like thing with two pools. The first pool is seeded
> with n, then the second with n+b0, then the first again with n+b0+b1.
> n is the arbitrary starting count, while b0 and b1 are independent
> random bits.
>
> Assuming that
linux wrote:
>David Wagner wrote:
>>linux wrote:
>>> First, a reminder that the design goal of /dev/random proper is
>>> information-theoretic security. That is, it should be secure against
>>> an attacker with infinite computational power.
>
>> I am skeptical.
>> I have never seen any convincing
On Sat, Apr 16, 2005 at 05:16:22PM -, [EMAIL PROTECTED] wrote:
> > "How does the entropy estimator measure entropy of the event?" becomes a
> > crucial concern here. What if, by your leading example, there is 1/2 bit
> > of entropy in each event? Will the estimator even account for 1/2 bits?
On Sat, Apr 16, 2005 at 10:05:55AM -, [EMAIL PROTECTED] wrote:
> MErging e-mails, first from [EMAIL PROTECTED]:
> > You really ought to look at the _current_ implementation. There is no
> > SHA1 code in random.c.
>
> So I'm imagining the call to sha_transform() in 2.6.12-rc2's
>
il to leak information, then we're OK"
Er.. "if the crypto primitives don't fail TO leak information"?
I'm not quite sure I follow...
>> 2) Fortuna tries to support such a wide range of entropy source rates,
>>down to very low rates, that it sequesters some entropy for lite
> Correct me if I'm wrong here, but uniformity of the linear function isn't
> sufficent even if we implemented like this (right now it's more a+X than
> a X).
>
> The part which suggests choosing an irreducible poly and a value "a" in the
> preprocessing stage ... last I checked the value for a
easier to improve. You're 100% correct - security
wise it doesn't matter.
> 1) Fortuna is trying to sidestep the hard problem of entropy measurement,
>to make it unnecessary. This is a laudable goal, but /dev/random's
>information-theoretic design goal precludes this simplific
On Sat, Apr 16, 2005 at 11:10:33AM -, [EMAIL PROTECTED] wrote:
> Thank you for pointing out the paper; Appendix A is particularly
> interesting. And the [BST03] reference looks *really* nice! I haven't
> finished it yet, but based on what I've read so far, I'd like to
> *strongly* recommnd
>> /dev/urandom depends on the strength of the crypto primitives.
>> /dev/random does not. All it needs is a good uniform hash.
>
> That's not at all clear. I'll go farther: I think it is unlikely
> to be true.
>
> If you want to think about cryptographic primitives being arbitrarily
> broken,
>> First, a reminder that the design goal of /dev/random proper is
>> information-theoretic security. That is, it should be secure against
>> an attacker with infinite computational power.
> I am skeptical.
> I have never seen any convincing evidence for this claim,
> and I suspect that there
almost.) My point about "the neat name" was a
facetious straw-man. That's a metaphor for "some stupid non-technical
reason". Newer is not neceaarily better. But your reason for liking
Fortuna is not quite that shallow. Good.
Ted doesn't like Fortuna's pool de
. It's the design
of the RNG itself that has my attention for the time being.
Great, we agree! (Okay, almost.) My point about the neat name was a
facetious straw-man. That's a metaphor for some stupid non-technical
reason. Newer is not neceaarily better. But your reason for liking
Fortuna
First, a reminder that the design goal of /dev/random proper is
information-theoretic security. That is, it should be secure against
an attacker with infinite computational power.
I am skeptical.
I have never seen any convincing evidence for this claim,
and I suspect that there are cases
/dev/urandom depends on the strength of the crypto primitives.
/dev/random does not. All it needs is a good uniform hash.
That's not at all clear. I'll go farther: I think it is unlikely
to be true.
If you want to think about cryptographic primitives being arbitrarily
broken, I think
On Sat, Apr 16, 2005 at 11:10:33AM -, [EMAIL PROTECTED] wrote:
Thank you for pointing out the paper; Appendix A is particularly
interesting. And the [BST03] reference looks *really* nice! I haven't
finished it yet, but based on what I've read so far, I'd like to
*strongly* recommnd that
.
1) Fortuna is trying to sidestep the hard problem of entropy measurement,
to make it unnecessary. This is a laudable goal, but /dev/random's
information-theoretic design goal precludes this simplification.
It *has* to measure entropy. Are Fortuna's benefits sufficient
Correct me if I'm wrong here, but uniformity of the linear function isn't
sufficent even if we implemented like this (right now it's more a+X than
a dot X).
The part which suggests choosing an irreducible poly and a value a in the
preprocessing stage ... last I checked the value for a and
primitives don't fail TO leak information?
I'm not quite sure I follow...
2) Fortuna tries to support such a wide range of entropy source rates,
down to very low rates, that it sequesters some entropy for literally
years. Ted thinks that's inexcusable, and I can't really disagree.
This can
On Sat, Apr 16, 2005 at 10:05:55AM -, [EMAIL PROTECTED] wrote:
MErging e-mails, first from [EMAIL PROTECTED]:
You really ought to look at the _current_ implementation. There is no
SHA1 code in random.c.
So I'm imagining the call to sha_transform() in 2.6.12-rc2's
extract_buf()? The
On Sat, Apr 16, 2005 at 05:16:22PM -, [EMAIL PROTECTED] wrote:
How does the entropy estimator measure entropy of the event? becomes a
crucial concern here. What if, by your leading example, there is 1/2 bit
of entropy in each event? Will the estimator even account for 1/2 bits?
Or
linux wrote:
David Wagner wrote:
linux wrote:
First, a reminder that the design goal of /dev/random proper is
information-theoretic security. That is, it should be secure against
an attacker with infinite computational power.
I am skeptical.
I have never seen any convincing evidence for
that delivers one fresh
random bit each time it is sampled.
But suppose that rather than delivering a bare bit, it delivers the
running sum of the bits. So adjacent samples are either the same or
differ by +1. This seems to me an extremely plausible example.
Consider a Fortuna-like
Jean-Luc Cooke wrote:
The part which suggests choosing an irreducible poly and a value a in the
preprocessing stage ... last I checked the value for a and the poly need to
be secret. How do you generate poly and a, Catch-22? Perhaps I'm missing
something and someone can point it out.
I don't
linux wrote:
>/dev/urandom depends on the strength of the crypto primitives.
>/dev/random does not. All it needs is a good uniform hash.
That's not at all clear. I'll go farther: I think it is unlikely
to be true.
If you want to think about cryptographic primitives being arbitrarily
broken, I
ay that affects /dev/random than that
SHA1 will be broken in a way that affects /dev/random.
>In addition, Fortuna is profligate with entropy, [...]
Yup.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Jean-Luc Cooke wrote:
>Info-theoretic randomness is a strong desire of some/many users, [..]
I don't know. Most of the time that I've seen users say they want
information-theoretic randomness, I've gotten the impression that those
users didn't really understand what information-theoretic
>First, a reminder that the design goal of /dev/random proper is
>information-theoretic security. That is, it should be secure against
>an attacker with infinite computational power.
I am skeptical.
I have never seen any convincing evidence for this claim,
and I suspect that there are cases in
Matt Mackall wrote:
>While it may have some good properties, it lacks
>some that random.c has, particularly robustness in the face of failure
>of crypto primitives.
It's probably not a big deal, because I'm not worried about the
failure of standard crypto primitives, but--
Do you know of any
On Fri, Apr 15, 2005 at 12:22:25PM -0400, Jean-Luc Cooke wrote:
> And the argument that "random.c doesn't rely on the strength of crypto
> primitives" is kinda lame, though I see where you're coming from. random.c's
> entropy mixing and output depends on the (endian incorrect) SHA-1
>
On Fri, Apr 15, 2005 at 03:38:01PM -, [EMAIL PROTECTED] wrote:
>
> First of all, people *on* the netowrk path can just *see* the packets.
> Or modify them. Or whatever.
> The point is to prevent hijacking by people *not* on the path.
Yes, you're correct of course. Of course, I'll note that
me when I was reading random.c for the first time. First
impressions and all.
> As for hacking Fortuna in, could you give a clear statement of what
> you're trying to achieve?
>
> Do you like:
> - The neat name,
> - The strong ciphers used in the pools, or
> - The multi-pool reseed
the SHA-1, are you trying to imply
something? Because it makes zero difference, and reduces the code
size and execution time. Which is obviously a Good Thing.)
As for hacking Fortuna in, could you give a clear statement of what
you're trying to achieve?
Do you like:
- The neat name,
- T
for some
> > time.
>
> It depends on how often you reseed, but my recollection was that it
> was far more than years; it was *centuries*. And as far as I'm
> concerned, that's equivalent to throwing it away, especially given the
> pathetically small size of the Fortuna pools.
reby making it effectively unavailable.
>> Any catastrophic reseeding solution has to hold back entropy for some
>> time.
> It depends on how often you reseed, but my recollection was that it
> was far more than years; it was *centuries*. And as far as I'm
> concerned, that's equ
has to hold back entropy for some
> time.
It depends on how often you reseed, but my recollection was that it
was far more than years; it was *centuries*. And as far as I'm
concerned, that's equivalent to throwing it away, especially given the
pathetically sma
time.
It depends on how often you reseed, but my recollection was that it
was far more than years; it was *centuries*. And as far as I'm
concerned, that's equivalent to throwing it away, especially given the
pathetically small size of the Fortuna pools
time.
It depends on how often you reseed, but my recollection was that it
was far more than years; it was *centuries*. And as far as I'm
concerned, that's equivalent to throwing it away, especially given the
pathetically small size of the Fortuna pools.
Well, subpool n is added to the main
.
It depends on how often you reseed, but my recollection was that it
was far more than years; it was *centuries*. And as far as I'm
concerned, that's equivalent to throwing it away, especially given the
pathetically small size of the Fortuna pools.
pathetically is an interesting term to call it. 256
? Because it makes zero difference, and reduces the code
size and execution time. Which is obviously a Good Thing.)
As for hacking Fortuna in, could you give a clear statement of what
you're trying to achieve?
Do you like:
- The neat name,
- The strong ciphers used in the pools, or
- The multi
was reading random.c for the first time. First
impressions and all.
As for hacking Fortuna in, could you give a clear statement of what
you're trying to achieve?
Do you like:
- The neat name,
- The strong ciphers used in the pools, or
- The multi-pool reseeding strategy, or
- Something else
On Fri, Apr 15, 2005 at 03:38:01PM -, [EMAIL PROTECTED] wrote:
First of all, people *on* the netowrk path can just *see* the packets.
Or modify them. Or whatever.
The point is to prevent hijacking by people *not* on the path.
Yes, you're correct of course. Of course, I'll note that
On Fri, Apr 15, 2005 at 12:22:25PM -0400, Jean-Luc Cooke wrote:
And the argument that random.c doesn't rely on the strength of crypto
primitives is kinda lame, though I see where you're coming from. random.c's
entropy mixing and output depends on the (endian incorrect) SHA-1
implementation
Matt Mackall wrote:
While it may have some good properties, it lacks
some that random.c has, particularly robustness in the face of failure
of crypto primitives.
It's probably not a big deal, because I'm not worried about the
failure of standard crypto primitives, but--
Do you know of any
First, a reminder that the design goal of /dev/random proper is
information-theoretic security. That is, it should be secure against
an attacker with infinite computational power.
I am skeptical.
I have never seen any convincing evidence for this claim,
and I suspect that there are cases in
/random than that
SHA1 will be broken in a way that affects /dev/random.
In addition, Fortuna is profligate with entropy, [...]
Yup.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org
linux wrote:
/dev/urandom depends on the strength of the crypto primitives.
/dev/random does not. All it needs is a good uniform hash.
That's not at all clear. I'll go farther: I think it is unlikely
to be true.
If you want to think about cryptographic primitives being arbitrarily
broken, I
ies to achieve that
without explicitly measuring entropy.
> My big concern with Fortuna is that it really is the result of
> cryptographic masturbation. It fundamentally assumes that crypto
> primitives are secure (when the recent break of MD4, MD5, and now SHA1
> should have bee
not make any claim that random-fortuna.c should be mv'd to random.c, the
> patch given allows people to kernel config it in under the Cryptographic
> Options menu. Perhaps a disclaimer in the help menu would be in order to
> inform users that Fortuna has profound consequences for those expec
, if you check the current random.c code, you'll see that it
has catastrophic reseeding in its design already.
> So Fortuna would be helped by some better understanding of what exactly
> makes it fail, so the discussion could move to whether real-world
> seed sources have those properties.
>
a disclaimer in the help menu would be in order to
inform users that Fortuna has profound consequences for those expecting
Info-theoretic /dev/random?
The case where an attacker has some small amount of unknown in the pool is a
problem that effects BOTH random-fortuna.c and random.c (and any other
Just to refersh everyone's memory as to the strengths and weaknesses
of Fortuna...
First, a reminder that the design goal of /dev/random proper is
information-theoretic security. That is, it should be secure against
an attacker with infinite computational power. If you want a weaker
guarantee
Just to refersh everyone's memory as to the strengths and weaknesses
of Fortuna...
First, a reminder that the design goal of /dev/random proper is
information-theoretic security. That is, it should be secure against
an attacker with infinite computational power. If you want a weaker
guarantee
a disclaimer in the help menu would be in order to
inform users that Fortuna has profound consequences for those expecting
Info-theoretic /dev/random?
The case where an attacker has some small amount of unknown in the pool is a
problem that effects BOTH random-fortuna.c and random.c (and any other
, you'll see that it
has catastrophic reseeding in its design already.
So Fortuna would be helped by some better understanding of what exactly
makes it fail, so the discussion could move to whether real-world
seed sources have those properties.
But until that understanding is gained, Fortuna
that random-fortuna.c should be mv'd to random.c, the
patch given allows people to kernel config it in under the Cryptographic
Options menu. Perhaps a disclaimer in the help menu would be in order to
inform users that Fortuna has profound consequences for those expecting
Info-theoretic /dev
that
without explicitly measuring entropy.
My big concern with Fortuna is that it really is the result of
cryptographic masturbation. It fundamentally assumes that crypto
primitives are secure (when the recent break of MD4, MD5, and now SHA1
should have been a warning that this is a Bad Idea (tm
> > > Any insight on how to test syn cookies and the other network stuff in
> > > random.c? My patch is attached, but I havn't tested that part yet.
> >
> > For starters, this is not against anything like a current random.c. A
> > great number of cleanups hav
.c? My patch is attached, but I havn't tested that part yet.
>
> For starters, this is not against anything like a current random.c. A
> great number of cleanups have been done.
You caught me. :)
Last I proposed Fortuna for /dev/random it nearly got me drawn and quarterd.
So I've left i
On Wed, Apr 13, 2005 at 07:43:37PM -0400, Jean-Luc Cooke wrote:
> Ahh. Thanks Herbert.
>
> Matt,
>
> Any insight on how to test syn cookies and the other network stuff in
> random.c? My patch is attached, but I havn't tested that part yet.
For starters, this is not against anything like a
On Wed, Apr 13, 2005 at 07:43:37PM -0400, Jean-Luc Cooke wrote:
Ahh. Thanks Herbert.
Matt,
Any insight on how to test syn cookies and the other network stuff in
random.c? My patch is attached, but I havn't tested that part yet.
For starters, this is not against anything like a current
that part yet.
For starters, this is not against anything like a current random.c. A
great number of cleanups have been done.
You caught me. :)
Last I proposed Fortuna for /dev/random it nearly got me drawn and quarterd.
So I've left it as a kenrel config option, leaving the current random.c
alone
stuff in
random.c? My patch is attached, but I havn't tested that part yet.
For starters, this is not against anything like a current random.c. A
great number of cleanups have been done.
You caught me. :)
Last I proposed Fortuna for /dev/random it nearly got me drawn and quarterd
d a FIPS140
> post processor before handing you a random number it would be nice to
> take advantage of that IMO.
For those who are interested, my Fortuna patch to the Linux RNG (/dev/random,
/dev/urandom) is available here (2.6.12-rc1, works on kernels as low as
2.6.11.4):
http://jlcooke.ca/
are interested, my Fortuna patch to the Linux RNG (/dev/random,
/dev/urandom) is available here (2.6.12-rc1, works on kernels as low as
2.6.11.4):
http://jlcooke.ca/random/
Fortuna is a Cryptographically Secure Random Number Generator (CSRNG)
developed by Neils Ferguson and Bruce Schnier and published
88 matches
Mail list logo
